I would like to have a piece of advice from someone who knows LELISP.
This days, I have to find a solution to pass from LeLisp in HDA/Masai environment to another environment using a more common language such as C/C++.
Have you heard something about that?
>From my side, I have seen something called Lisp-to-C Translator
released in 1992 (but nothing more in my researchs, no contact), and also a compiler Scheme-vers-C (Chicken) but nothing to translate directly LeLisp to C.
I would like to know at least what are the differences between Common Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then maybe pass from Common Lisp to C or anything more actual.
Just in case you don't know: I still maintain Le-Lisp/Aïda/Masaï on Windows and Linux. I recently made the port with VC2005 and it runs perfectly well on Windows x64 too. (see for example: http://www.eligis.com/aida.jpg)
Otherwise, you can check OpenLisp www.eligis.com that has few Le-Lisp functions support. You can contact me directlty for further informations.
C. Jullien
"Christophe" <cne...@logatique.fr> wrote in message
> I would like to have a piece of advice from someone who knows LELISP.
> This days, I have to find a solution to pass from LeLisp in HDA/Masai > environment to another environment using a more common language such as > C/C++.
> Have you heard something about that? >>From my side, I have seen something called Lisp-to-C Translator > released in 1992 (but nothing more in my researchs, no contact), and > also a compiler Scheme-vers-C (Chicken) but nothing to translate > directly LeLisp to C.
> I would like to know at least what are the differences between Common > Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then > maybe pass from Common Lisp to C or anything more actual.
> I would like to have a piece of advice from someone who knows LELISP.
> This days, I have to find a solution to pass from LeLisp in HDA/Masai > environment to another environment using a more common language such as > C/C++.
> Have you heard something about that? > >From my side, I have seen something called Lisp-to-C Translator > released in 1992 (but nothing more in my researchs, no contact), and > also a compiler Scheme-vers-C (Chicken) but nothing to translate > directly LeLisp to C.
> I would like to know at least what are the differences between Common > Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then > maybe pass from Common Lisp to C or anything more actual.
It's worth mentioning that if you do wish to convert the code to a more mainstream lisp then there are lisp specific techniques you can use to do this.
If, for example an s-expression like:- (something a b c) exists in the code, and in the language you are translating to the expression needs to be: (something a b optionx: c) or (something-else b c a)
Then you can make the conversion by loading the relevant files into variables with read (setq sourcefile-data (read "sourcefile.l")) Then converting them using "subst" and "subst-if" or by defining macros and expanding them over the code. For example:- (defmacro something (a b c) (list something-else b a c)) (setq sourcefile-altered (macroexpand sourcefile-data)) (pprint sourcefile-altered stream: some-new-file)
This destroys formatting and comments, but it's useful for testing significant changes to code. Once you know a change works you can find the instances and change them by hand, altering formatting and comments to match.
This assumes read syntax is not significantly different between the lisps.
It's an interesting trick for someone like me who didn't practice Lisp languages.
I take note of that even if I suppose it won't be as simple as this kind of example. Besides, it suppose I know exactly the differences between my quite unknown LeLisp and (probably) Common Lisp.
>> I would like to have a piece of advice from someone who knows LELISP.
>> This days, I have to find a solution to pass from LeLisp in HDA/Masai >> environment to another environment using a more common language such as >> C/C++.
>> Have you heard something about that? >> >From my side, I have seen something called Lisp-to-C Translator >> released in 1992 (but nothing more in my researchs, no contact), and >> also a compiler Scheme-vers-C (Chicken) but nothing to translate >> directly LeLisp to C.
>> I would like to know at least what are the differences between Common >> Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then >> maybe pass from Common Lisp to C or anything more actual.
> It's worth mentioning that if you do wish to convert the code to a more > mainstream lisp then there are lisp specific techniques you can use to > do this.
> If, for example an s-expression like:- > (something a b c) > exists in the code, and in the language you are translating to the > expression needs to be: > (something a b optionx: c) or (something-else b c a)
> Then you can make the conversion by loading the relevant files into > variables with read > (setq sourcefile-data (read "sourcefile.l")) > Then converting them using "subst" and "subst-if" or by defining macros > and expanding them over the code. For example:- > (defmacro something (a b c) (list something-else b a c)) > (setq sourcefile-altered (macroexpand sourcefile-data)) > (pprint sourcefile-altered stream: some-new-file)
> This destroys formatting and comments, but it's useful for testing > significant changes to code. Once you know a change works you can find > the instances and change them by hand, altering formatting and comments > to match.
> This assumes read syntax is not significantly different between the > lisps.
Thre alternatives:
- before reading the source from CL, change the read-table macros to read the comments as sexps: ;... --> (line-comment "...") #|...|# --> (block-comment "...") #+/#- --> sharp-condition+/- etc. Then you can manipulate the form forest and write it back, comments included.
- instead of using CL, use emacs, and implement the substitutions in the buffer. You may still lose comments embedded in the forms you substitute, or you can easily extract them from the text and add them to the substitution. At least, comments out of forms are left alone.
- just write compatibility functions and macros:
(defpackage "LELISP" (:use "COMMON-LISP") (:shadow "CAR") (:export "SOMETHING" ... "CAR" ...)) (in-package "LELISP") (defun car (x) "CAR à la mode LeLisp") ...) (defmacro something (a b c) `(something-else ,b ,c ,a)) ...
Then you only need (use-package "LELISP") before loading the lelisp files.
For the general idea you're right but rember that Le-Lisp is dynamically scoped, you can't make migration so easily. Le-Lisp has also a complete package mechanism used for OOP (#:foo:bar:gee:my-fun) you can't translate in Common Lisp "on the fly". Finally, Christophe's system uses proprietary (no source included) Aïda/Masaï a *huge* graphic library that must be translated too. It's perhaps the most difficult task. IMHO, i'ts impossible to convert such program to anything else at a reasonable cost (less than 6 months for an experimented Lisp programmer that knows both Le-Lisp and the target system).
"Pascal Bourguignon" <s...@mouse-potato.com> wrote in message
>>> I would like to have a piece of advice from someone who knows LELISP.
>>> This days, I have to find a solution to pass from LeLisp in HDA/Masai >>> environment to another environment using a more common language such as >>> C/C++.
>>> Have you heard something about that? >>> >From my side, I have seen something called Lisp-to-C Translator >>> released in 1992 (but nothing more in my researchs, no contact), and >>> also a compiler Scheme-vers-C (Chicken) but nothing to translate >>> directly LeLisp to C.
>>> I would like to know at least what are the differences between Common >>> Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then >>> maybe pass from Common Lisp to C or anything more actual.
>> It's worth mentioning that if you do wish to convert the code to a more >> mainstream lisp then there are lisp specific techniques you can use to >> do this.
>> If, for example an s-expression like:- >> (something a b c) >> exists in the code, and in the language you are translating to the >> expression needs to be: >> (something a b optionx: c) or (something-else b c a)
>> Then you can make the conversion by loading the relevant files into >> variables with read >> (setq sourcefile-data (read "sourcefile.l")) >> Then converting them using "subst" and "subst-if" or by defining macros >> and expanding them over the code. For example:- >> (defmacro something (a b c) (list something-else b a c)) >> (setq sourcefile-altered (macroexpand sourcefile-data)) >> (pprint sourcefile-altered stream: some-new-file)
>> This destroys formatting and comments, but it's useful for testing >> significant changes to code. Once you know a change works you can find >> the instances and change them by hand, altering formatting and comments >> to match.
>> This assumes read syntax is not significantly different between the >> lisps.
> Thre alternatives:
> - before reading the source from CL, change the read-table macros to > read the comments as sexps: ;... --> (line-comment "...") > #|...|# --> (block-comment "...") > #+/#- --> sharp-condition+/- > etc. Then you can manipulate the form forest and write it back, > comments included.
> - instead of using CL, use emacs, and implement the substitutions in > the buffer. You may still lose comments embedded in the forms you > substitute, or you can easily extract them from the text and add > them to the substitution. At least, comments out of forms are left > alone.
> - just write compatibility functions and macros:
> (defpackage "LELISP" > (:use "COMMON-LISP") > (:shadow "CAR") > (:export "SOMETHING" ... "CAR" ...)) > (in-package "LELISP") > (defun car (x) "CAR à la mode LeLisp") ...) > (defmacro something (a b c) `(something-else ,b ,c ,a)) > ...
> Then you only need (use-package "LELISP") before loading the lelisp > files.
> Finally, Christophe's system uses proprietary (no source included) > Aïda/Masaï a *huge* graphic library that must be translated too. > It's perhaps the most difficult task.
>> For the general idea you're right but rember that Le-Lisp is dynamically >> scoped, you can't make migration so easily.
> This shouldn't be too difficult. You can shadow the forms that introduce > new variables by equivalent forms that declare them all special.
In that case, ALL variables should be declared as special. The task is globally the same as writing a Le-Lisp compiler that generates Common Lisp code. That why I said it will take about 6 month for an exprt in both Le-Lisp and Common Lisp. Note that Le-Lisp is NOT a toy Lisp, it has been used since 1982 on many complex systems. For instance, it's still in use to generate processor mask on Bull mainframe (not few KLOC as you can imagine) and as CAD system for a major pneumatic manufacturor.
>> Le-Lisp has also a complete package mechanism used for OOP >> (#:foo:bar:gee:my-fun) you can't translate in Common Lisp "on the fly".
It's little bit more complicated than hierarchical packages, it also includes a fast lookup heavily used by send mechanism. Associated with package there is also TCONS (a kind of tagged CONS) that can implement only whit a HUGE performance penalty.
>> Finally, Christophe's system uses proprietary (no source included) >> Aïda/Masaï a *huge* graphic library that must be translated too. >> It's perhaps the most difficult task.
Christophe wrote: > Pascal Costanza > "---You can shadow [=hide?] the forms that introduce new variables by > equivalent forms that declare them all special.---"
In Common Lisp, forms that introduce new bindings create lexically scoped bindings by default. Example:
(let ((x 42)) ...)
Here, x is lexically scoped. You can change this by declaring a variable special:
(let ((x 42)) (declare (special x)) ...)
If you don't want to go through the whole source code and do this manually, you can use the following idiom:
This is strongly simplified (because it doesn't handle some special cases), but I hope you get the idea.
Shadowing symbols shouldn't be done like above (by saying (shadow 'let)), but instead all shadowings should be declared in a defpackage form.
Since there are quite a number of forms that introduce new bindings (including all the defun, defmethod, etc. forms), this will be quite some work, especially until all the special cases are treated correctly. (So Christian is right that this is not trivial.)
> There is some elements I misunderstand (because of my English maybe, > but also because informatic concepts...)
> Pascal Bourguignon > "Then you can manipulate ---the form forest---"
Lisp uses a limited number Special forms (i.e. well know forms with specific behaviors, like 'if', 'while' or 'for' in C if you like). Special Forms (SF) decribe part of the language semantic.
> Pascal Costanza > "---You can shadow [=hide?] the forms that introduce new variables by > equivalent forms that declare them all special.---"
> Christian Julien : > "---IMHO---, i'ts impossible to convert...."
In My Umble Opinion
> "Le-Lisp is dynamically ----scoped----"
Argh! difficult to explain. A variable is bound to a value until it is bound to another value anywhere in the program.
(defun foo (x) (bar))
(defun bar () (print x))
(setq x 100)
In Le-Lisp:
(bar) -> 100 but (foo 10) -> 10
In Common Lisp (lexically scoped) (bar) -> 100 (foo 10) -> 100
You can see that the same code produce different result, none is right or wrong, they simply use different semantic even I personnaly consider that Lexical Scope (as in CLtL or as in ISLISP) is far better. Historical Lisp implementation used to be dynamically scoped.
> "---fast lookup heavily used by send mechanism---" = ?
Lookup = find value or function depending of a context. The send function is the way to call method in Le-Lisp (send 'draw obj) while Common Lisp uses generic functions (draw obj)
> "Associated with package there is also ---TCONS--- (a kind of ---tagged > CONS---) that can implement only whit a HUGE performance penalty." = ?
It's an internal Le-Lisp feature, it's not the place here to discuss this implementation detail but trying to implement this in Common Lisp will slowdown the application a lot.
If you prefer French, you can switch to fr.comp.lang.lisp unless Pascal prefers English.
Christophe wrote: > There is some elements I misunderstand (because of my English maybe, > but also because informatic concepts...)
I think others have described the other terms.
> Pascal Bourguignon > "Then you can manipulate ---the form forest---"
A form is an s-expression like (setq a b) or (print "32.9").
Something like (defun foo () (bar a b) (print x)) is an executable statement, but before it is executed it is stored as a tree.
'read' will read the tree in it's textual form above from the file it's in, it will then construct a tree in memory representing it. Then if the code is interpreted the interpreter will walk the tree and execute the relevant functions as it goes. If it's compiled then the compiler will walk the tree and construct executable code.
So, a file of forms like (defun ...) (defvar ....) becomes a forest of trees in memory.
What Pascal and I were talking about earlier in the thread was reading a file with 'read' then processing it when in it's tree form. Then writing it back out again using print, 'print' is not like print in Basic, it is the inverse of 'read' it converts trees in memory back into their textual form.
Special forms, which someone else mentioned are forms implemented by the lisp compiler/interpreter, (like and, cons, car or cdr) as opposed to those defined in libraries or program code. For the above purpose the difference between normal and special forms isn't really that important.
I think I assumed too much prior knowledge in my previous post.
"Rob Thorpe" <robert.tho...@antenova.com> writes: > Christophe wrote: >> There is some elements I misunderstand (because of my English maybe, >> but also because informatic concepts...)
> I think others have described the other terms.
>> Pascal Bourguignon >> "Then you can manipulate ---the form forest---"
> A form is an s-expression like (setq a b) or (print "32.9").
> Something like (defun foo () (bar a b) (print x)) is an executable > statement, but before it is executed it is stored as a tree.
> 'read' will read the tree in it's textual form above from the file it's > in, it will then construct a tree in memory representing it. Then if > the code is interpreted the interpreter will walk the tree and execute > the relevant functions as it goes. If it's compiled then the compiler > will walk the tree and construct executable code.
> So, a file of forms like > (defun ...) > (defvar ....) > becomes a forest of trees in memory.
> What Pascal and I were talking about earlier in the thread was reading > a file with 'read' then processing it when in it's tree form. Then > writing it back out again using print, 'print' is not like print in > Basic, it is the inverse of 'read' it converts trees in memory back > into their textual form.
> Special forms, which someone else mentioned are forms implemented by > the lisp compiler/interpreter, (like and, cons, car or cdr) as opposed > to those defined in libraries or program code. For the above purpose > the difference between normal and special forms isn't really that > important.
No. Special forms are forms that are directly interpreted by the interpreter, or directly implemented by the compiler; they are the true primitives of the language. Funtions and macros can be implemented by the programmer, using other functions and macros and ultimately, special forms.
AND is not specified to be a special form, because it can be implemented as a macro:
(shadow '(cons car cdr)) (defun cons (a d) (lambda (sel) (ecase sel ((car) a) ((cdr) d)))) (defun car (c) (funcall c 'car)) (defun cdr (c) (funcall c 'cdr))
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons, protons, etc.) comprising this product are exactly the same in every measurable respect as those used in the products of other manufacturers, and no claim to the contrary may legitimately be expressed or implied.
If you want to convert from Le-Lisp to anything else you have to:
1) make a compiler that compiles Le-Lisp semantic mainly provided by special forms to the target language (Lisp or not) 2) implement Le-Lisp library in the target language (language libraries, system libraries and graphic libraries) 3) implement all basic Le-Lisp types that have not target equivalent 4) provide runtime support the same way as Le-Lisp (GC, itsoft for reader, printer and clock ...). 5) implement a dynamic code loader for compiled .lo (kind of FASL) 6) all of what is missing form point 1 to 5.
For a simple school, text only homework project (about 1 to 5 KOLC), point 1 and few functions from 2 could be made in one week For a real application, especially an application that uses Aida/Masai, a life time is not enought. 10 years ago, Aida/Masai was a very high end interface generator not especially targeted to Lisp specific code. Many big companies in France have made complex GUI applications with Aida/Masai
I think you have two reasonable choices:
- Analyse your needs, take any modern computer language that correspond the most of the type of computing you need (Lisp or not), write or buy equivalent missing library and rewrite the application from scratch.
- The other "reasonable" solution is to ask for Le-Lisp/Aida/Masai support to maintain your application alive on maintream operation systems: Windows x32/x64 or Linux x32. If you choose this solution my company will be glad to help you but this discussion is out of the scope of this newsgroup.
Christian
"Christophe" <cne...@logatique.fr> wrote in message
> I would like to have a piece of advice from someone who knows LELISP.
> This days, I have to find a solution to pass from LeLisp in HDA/Masai > environment to another environment using a more common language such as > C/C++.
> Have you heard something about that? >>From my side, I have seen something called Lisp-to-C Translator > released in 1992 (but nothing more in my researchs, no contact), and > also a compiler Scheme-vers-C (Chicken) but nothing to translate > directly LeLisp to C.
> I would like to know at least what are the differences between Common > Lisp and LeLisp to be able to pass from LeLisp to Common Lisp and then > maybe pass from Common Lisp to C or anything more actual.
> Thanks to your comments, I have a better idea of the whole available > choices.
> The main purpose of this investigation was to find a simple and cheap > solution (...of course , everyone can understand that!). > The answer to this request in clearly NO.
> Besides, I may not have been clear enough on one point : > we only needs to rebuild an exe for actual material (computer & OS) but > rewriting the code in understandable C code human readable is not > absolutely required; it was just the first idea.
> To finish, I have one more question (even if I may know the answer) : > what about emulate the old system (DEC computer with Ultrix) on a > recent system? > What does exist? (I sent a mail to the creator of GXemul and he admits > it's subsist several bugs so we can't leave it to an unreliable > solution).
If I understand you well, your Le-Lisp/Aida/Masai application runs on DEC Ultrix. The amazing thing with Le-Lisp is its compatibility when run on different systems. You don't even have to recompile your application, .LO files (Lisp file already compiled) load to native code on different achitecture. Since, DEC Ultrix is a unix family operating system it should not take too long to port on Linux (but Windows is also a good target). "Not too long" means few days. The only difficulty I see is if you have external C code you have to port (for example a I/O module that read from serial port). Could tou tell me Le-Lisp version you are running ? At Le-Lisp prompt: ? (version) = xxxxx ? (subversion) = yyyy
> The amazing thing with Le-Lisp is its compatibility when run on different systems.
Because it is an interpreted language, right?
> You don't even have to recompile your application, .LO files (Lisp file already compiled) > load to native code on different achitecture.
*.lo files = compiled Lisp? You mean that it's the same as *.obj in C ? What do I have to do, just find a Lisp interpreter running on Linux for example and...that's all? What the equivalent to the program.exe for the application (I know, I should know it but we gave me all files without any explaination)?
On the other hand, I don't know if we need all of the other files too :
> The amazing thing with Le-Lisp is its compatibility when run on different > systems.
Because it is an interpreted language, right?
> You don't even have to recompile your application, .LO files (Lisp file > already compiled) > load to native code on different achitecture. > *.lo files = compiled Lisp?
Right!
> You mean that it's the same as *.obj in C ?
Yes and no! yes because .lo are compiled files, no because the loader translates Pseudo-code in true machine code. It's a little bit like .class with JIT in Java world.
> What do I have to do, just find a Lisp interpreter running on Linux for > example and...that's all?
Mmmm ... Yes! To be more precise, you need Le-Lisp/Aida/Masai dev. environment for Linux and you generally don't have to recompile you application. Once again, it's like Java. The VM behind Le-Lisp makes the hard work.
Once it's done, you have a binary file lelisp31bin and a core image yourapp.core that together are your application. Then, you can distribute this application at the cost of a runtime fee (this is the bad news, Le-Lisp is not free).
> What the equivalent to the program.exe for the application (I know, I > should know it but we gave me all files without any explaination)?
> On the other hand, I don't know if we need all of the other files too : > *.adb ("ADA body file") > *.ada ("ADA file") > *.ads ("ADA spec file) > *.cat ("Security catalog") > *.aida, *.am, *.deb > *.gpr ("Gnat Project File) > *.met > *.siz
...
None are part of Le-Lisp
> ADA files just have to be compiled separately on the new system? > How do they work with *.lo?
Ada is not part of Le-Lisp but seems to be used beside Le-Lisp (probably using a subshell call form Le-Lisp). You have to find a gnat (GNU Ada compiler) for Linux - Very easy to find on the Web.
> I'm very sorry to be so lost... :-( > > The only difficulty I see is if you have external C code you have to > > port > If I look at the files, there is no *.c
Good point, it seems you have a pure Lisp application, it should be fairly easy to port.
> Could tou tell me Le-Lisp version you are running ? > I don't konw...
To go further, I need to know if you have the original files (.ll or .lo) of your application + a Makefile that rebuild the system.
In any case, expect few days or few weeks to make the port.
Could you tell me in few words the purpose of this application and what part Ada is playing ?
> HAVE A GOOD WEEK END ;-)
Thanks and a happy new year for everyone from this newgroup.
