Alex !

THANK YOU for sharing your design and rationale for the "picoLisp64".

After reading your example and explanations, I fully understand and agree with your decision to use assembler and to not use LLVM.

By sharing your roadmap for the future, you have increased the confidence level in the long term viability of picoLisp as a streamlined, efficient and very powerful platform for the delivery of complex applications.=C2=A0 It's as if you've reawakened the dreams for Symbolics / Genera.

It would appear that you could claim portability to any CPU.=C2=A0 Afterall, porting should only require writing a=C2=A0 translator module for the different instruction set.=C2=A0 If anyone wants JVM or CLI then that should be what needs rewriting.

As for the gcc.l, as.l, and the generic call to external libraries, I have a suggestion:

(For the foregoing, I have to not that my comments pertain to Linux/BSD.=C2=A0 My experience with Windows and Mac OS/X is too limited to be of any benefit.)

Provide a simple plug-in mechanism. This should only require :
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 1.=C2=A0=C2=A0=C2=A0 Shared libraries= written in the normal manner (dlopen/dlsym/dlclose/dlerror) and adhering to a simple set of conventions for picoLisp compatability.
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 2.=C2=A0=C2=A0 A manifest file for ea= ch DL which lists the entry points, argument types and return value type.
a call to (plug-in namespace "module.manifest") would load the plug-in's details into the appropriate spot in the namespace.=C2=A0 From that point on, those external functions would be accessible as if they were part of picoLisp.=C2=A0 IMHO, a plug-in approach is cleaner than a FFI with the corresponding collection of glue functions.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Reply via email to