Hello Lutz,
I think you had this question already a few times but ill try to hit it again :-)
Although i like intepreters very much sometimes a binary-code could help too..
(its a never ending story ;-) But is there already a wrapper for newLisp or a direct compilation possible from generated code?
Just out of intrest, so dont hit me :-)
Regards, Norman.
into binary code
newLISP is somehow in the middle between an interpreted language and a compiled language. When you load newLISP source it gets translated into an internal binary format which then is evaluated by a virtual machine, at this point there is no 'interpretation' or 'translation' work the VM is fed with addresses of 'C' callable functions and addresses of parameter lists.
Theoretically it would be possible to link this internal representation to a library and newLISP VM, but the load/translation process is so fast, that no speed increase would be gained by it.
You can link newLISP source to the newLISP executable with a procedure described in the manual of the latest development version 7.5.3 "Linking newLISP source and executable". The procedure itself has been available for many versions, but wasn't documented in the manual. This gives you one file/executable program, which can run by itself, similar to compiled/linked binary excutable.
If you would take the compilation/translation process in newLISP to a further step you would give up much of the dynamic nature of newLISP. In newLISP lambda expessions are still accessible as first class objects, as are all other expressions. If you would carry the compilation process beyond the current level you would loose this. Remember that in LISP program and data share the same syntax. In newLISP they are also compiled to the same internal representation.
Lutz
Theoretically it would be possible to link this internal representation to a library and newLISP VM, but the load/translation process is so fast, that no speed increase would be gained by it.
You can link newLISP source to the newLISP executable with a procedure described in the manual of the latest development version 7.5.3 "Linking newLISP source and executable". The procedure itself has been available for many versions, but wasn't documented in the manual. This gives you one file/executable program, which can run by itself, similar to compiled/linked binary excutable.
If you would take the compilation/translation process in newLISP to a further step you would give up much of the dynamic nature of newLISP. In newLISP lambda expessions are still accessible as first class objects, as are all other expressions. If you would carry the compilation process beyond the current level you would loose this. Remember that in LISP program and data share the same syntax. In newLISP they are also compiled to the same internal representation.
Lutz