Vendor offerings under Windows have a foreign function interface that
allows access to the Win32API (among other things).
In future will you be offering a similar interface to the .Net
framework? Nothing complicated; something like this:
http://www.rivendell.ws/dot-scheme/
I ask because, to me, in seems that the Win32 API will soon be dead
and am not sure what this means for the future of my desktop
application.
And (by the way) what's the deal with this:
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool
Developers Guide\Samples\clisp
> Vendor offerings under Windows have a foreign function interface that
> allows access to the Win32API (among other things).
>
> In future will you be offering a similar interface to the .Net
> framework? Nothing complicated; something like this:
>
> http://www.rivendell.ws/dot-scheme/
>
> I ask because, to me, in seems that the Win32 API will soon be dead
> and am not sure what this means for the future of my desktop
> application.
>
> And (by the way) what's the deal with this:
> C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool
> Developers Guide\Samples\clisp
Okay, never mind. I just checked with my astrologer. Good news!! She
told me that the world will end July 27th 2004. There you go -
problem solved!
gary wrote:
> Vendor offerings under Windows have a foreign function interface that
> allows access to the Win32API (among other things).
>
> In future will you be offering a similar interface to the .Net
> framework? Nothing complicated; something like this:
>
> http://www.rivendell.ws/dot-scheme/
>
> I ask because, to me, in seems that the Win32 API will soon be dead
> and am not sure what this means for the future of my desktop
> application.
It is not possible to implement Common Lisp in a straightforward way on
top of the .NET runtime, despite Microsoft's claims that .NET is
language-neutral.
If .NET turns out to be an important technology, there will probably be
some libraries that allow you to talk to .NET applications, as has been
done in the past for Java and CORBA. Some of them will be XML-based,
some will use the remote method call mechanism of .NET (don't know the
buzzword for that at the moment), and so on.
> And (by the way) what's the deal with this:
> C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool
> Developers Guide\Samples\clisp
I have no idea.
Pascal
> If .NET turns out to be an important technology, there will probably be
> some libraries that allow you to talk to .NET applications, as has been
> done in the past for Java and CORBA. Some of them will be XML-based,
> some will use the remote method call mechanism of .NET (don't know the
> buzzword for that at the moment), and so on.
Pascal:
Rather than .NET being an important technology, I would consider
XML-RPC and WebServices a larger more impacting and important
technology, where .NET can participate in GRID exchanges.
The worldview of GRID communities exchanging "data" through XML is
coming more and more possible. (Specially now that Axis from the Java
side is available as an interoperable tool and it si making rapid
headway into developing _production_ systems and vendor toolkits.)
However, Lisp, can also be a player in this world. There are already
some implementations of XML-RPC in Lisp like this one:
http://www.franz.com/support/tech_corner/index.lhtml#soap072903
Strangely, Franz also has a LISP-RPC api that emulates some of the old
"Common Business Communications Language", published by McCarthy:
http://www-formal.stanford.edu/jmc/cbcl.html
(This of course predates KQML and/or KIF as well ...)
This is strange or eerie because GRID computing sending XML around
is basically the vision that CBCL had in ... 1982 i.e. queries like:
(REQUEST-QUOTE (ADJECTIVE (PENCILS #2) YELLOW)
(GROSS 100))
that have replies like:
(WE-QUOTE (OUR-STOCK-NUMBER A7305)
(QUANTITY 100)
(DELIVERY-DATE 3-10-77)
(PRICE $1.00))
However, sending Lisp through the wire has significant advantages:
you can exchange code ... not only data as with XML.
By code I mean, of course, functions, rules, objects, classes,
macros, patterns, etc. anything possible in Lisp. So the
exchanges would be much more powerful. This mobility also provides
a natural environment friendly perhaps to mobile agents.
Last and not least, the "semantic web" as envisioned today through
its bloated and "dumb" RDF specification residing in web pages,
and its slow and "data driven" XML exchanges... would pale in
comparison with a app-server driven CBCL-like GRID of LISP-RPC
exchanges.
(The "semantic web", imnsho, has severe conceptual hindrances and
blunders because it assumes that the "models" i.e. the ontologies
and the data in organizations are kept in the views (HTML pages)
(??*).
Perhaps someone should remind its "visionaries" about MVC .. ??)
- Mike