Quote:Original post by CoffeeMug
Quote:Original post by Nathan Baum
Using two languages at once is generally a lot of trouble with any two languages where the underlying data and control models are vastly different.
People tend to expect complex things to be complex but simple things can reasonably be expected to be simple. At this point in time there is absolutely no technical reason I can think of that prevents a Lisp implementation from calling C functions in a friendly manner.
(import-c-library "blah.h" "blah.lib")(some-function-in-blah 1 2)
Naturally the implementation must deal with calling conventions and data marshalling but once again, there is no reason why this should be complex for simple things. Intelligent defaults work.
This would work.
As jdh30 pointed out (in typical alarmist form [wink]), there are still incompatabilities to look out for.
If you ever passed a pointer to an object to an imported function, you wouldn't know if it was safe for the GC to collect it. Either the object is made permanent; or you have to provide custom annotation to indicate that the called function won't be aliasing the value.
For example,
we know that "glTexImage2D" doesn't alias its "pixels" argument, but nothing in the declaration tells Lisp that this is the case: it couldn't ever be sure it was safe to free the pixel array. You'd have to explicitly
tell Lisp to free it.
It may be worth noting that C99's "restrict" qualifier is of no use here, in two ways.
The first way is that the aliasing restriction of a restrict-qualified pointer only applies between other restrict-qualified pointers in scope, and not to non-restrict-qualified pointers in scope. For example, the standard mandates that "strtok" alias its first argument, which the standard mandates is restrict-qualified.
The second way is that the language doesn't seek to
enforce the restriction, likely because it is defined in such a way that enforcing it would be prohibitively expensive. So even if "restrict" did have useful semantics, Lisp couldn't be
sure that the programmer had obeyed them.
Quote:
If you familiarize yourself with Erlang you'll find that the bulk of the features that make it an attractive language for its problem domain either cannot be transferred to Lisp all together or aren't helped by Lisp DSL creation mechanisms. In particular, there is no practical way to transfer Erlang's process scheduling system to Lisp. Additionally the bulk of Erlang's code lies in an efficient networking code implementation. DSLs in Lisp are nice but I'd have to spend years implementing a system that would probably be crappier than a current Erlang implementation. In this case rolling my own implementation is really not an option.
In terms of the simple facts, Lisp is Turing complete and therefore can perform any computation Erlang can perform.
Issues of practicality are fair game, though. To make an Erlisp that is as efficient as Erlang would either mean using a Lisp implementation which itself featured support for efficient distributed and parallelised processing (there are Lisps that run on parallelising supercomputers, but I don't know if they're generally available) or effectively making a complete Erlang implementation.
Whether or not it is acceptable to make your own implementation of Erlang or to use a distributed and parallelised DSL which is 'like' Erlang but not an exact clone depends upon your needs.
If you want to make a direct clone of Erlang's semantics with Lisp's syntax, the easiest implementation technique would likely be to write a function which translated your Erlisp DSL into Erlang, gave that to the Erlang compiler, and then used FFI to import it back in.
On the other hand, if you just want something that can evaluate expressions in parallel on different hosts, and a simple message-passing control system is sufficient for your needs, then a DSL may be a reasonable choice when compared to linking Lisp to Erlang.
If the non-distributed and non-parallelised aspects of the problem aren't susceptible to simplification via Lisp's features, then you might as well use Erlang for the whole thing.
