3 ms·

What has never been clear to me about Lisp is how these implementations differ. The syntax is so simple it doesn't seem to be that, so that would leave builtin

What has never been clear to me about Lisp is how these implementations differ. The syntax is so simple it doesn't seem to be that, so that would leave builtins and libraries. Surely builtins can be emulated and libraries can be ported. So why doesn't there exist some macro (Lispers always brag about them) that could transmogrify code written for one set of builtins and libraries to another?

Someone 15y ago
That is not so easy to do if the differences can be as huge as http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scoping_and_dynamic_scoping http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica.... It becomes a nightmare if your are trying to transmogrify code that itself already transmogrifies code. Such code will make assumptions about how the lisp it runs on behaves.
- rogerbinns 15y ago
  I still don't see how the scoping is difficult. Since macros can see the whole structure and usage of symbols why can't it rename or insert/remove necessary declarations (eg local or set)? I can understand how each level of transmogrification makes things harder to grok but in general wouldn't there only be one level. eg if code was written for LispA and you are running LispB then you just need one level to fix that. (Sure if you are running LispC then you might need A -> B -> C but there aren't that many different Lisps listed!) My question still remains - what was it that made these Lisps so incompatible and couldn't be addressed using the existing much vaunted facilities already in the language?
lispm 15y ago
The runtime environments are widely different. Some of the core libraries are implemented in a different way. There is the idea of a Common Lisp which implement the standard in a straight forward way and implementations which implement the standard with extensions and, for example, using CLOS. Different are threading implementations, extended character support, foreign code interfaces, streams in CLOS or not, error handling in CLOS or not, support for the Meta-Object Protocol or not. Interpreter or not. Compiler or not. Various compilation targets: C, native code, byte-code, JVM byte-code, ... Then there are different tradeoffs: cross-platform, Windows-based, MacOS-based, JVM-based, Unix-based, small footprint, highly-optimizing, ...

Someone 15y ago

That is not so easy to do if the differences can be as huge as http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexical_scoping_and_dynamic_scoping http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica.... It becomes a nightmare if your are trying to transmogrify code that itself already transmogrifies code. Such code will make assumptions about how the lisp it runs on behaves.

rogerbinns 15y ago
I still don't see how the scoping is difficult. Since macros can see the whole structure and usage of symbols why can't it rename or insert/remove necessary declarations (eg local or set)? I can understand how each level of transmogrification makes things harder to grok but in general wouldn't there only be one level. eg if code was written for LispA and you are running LispB then you just need one level to fix that. (Sure if you are running LispC then you might need A -> B -> C but there aren't that many different Lisps listed!) My question still remains - what was it that made these Lisps so incompatible and couldn't be addressed using the existing much vaunted facilities already in the language?

lispm 15y ago

The runtime environments are widely different. Some of the core libraries are implemented in a different way. There is the idea of a Common Lisp which implement the standard in a straight forward way and implementations which implement the standard with extensions and, for example, using CLOS. Different are threading implementations, extended character support, foreign code interfaces, streams in CLOS or not, error handling in CLOS or not, support for the Meta-Object Protocol or not. Interpreter or not. Compiler or not. Various compilation targets: C, native code, byte-code, JVM byte-code, ... Then there are different tradeoffs: cross-platform, Windows-based, MacOS-based, JVM-based, Unix-based, small footprint, highly-optimizing, ...