From: Christophe
Subject: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135694996.752940.35470@g47g2000cwa.googlegroups.com>
Hi,

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.

Any help will be welcomed!
Thank you.

From: Rob Thorpe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135779840.802770.217660@g44g2000cwa.googlegroups.com>
Christophe wrote:
> Hi,
>
> 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.
From: Christophe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135783651.637323.216500@g14g2000cwa.googlegroups.com>
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.
From: Pascal Bourguignon
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <87y8243dzz.fsf@thalassa.informatimago.com>
"Rob Thorpe" <·············@antenova.com> writes:

> Christophe wrote:
>> Hi,
>>
>> 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.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"Logiciels libres : nourris au code source sans farine animale."
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b3818d$0$29203$8fcfb975@news.wanadoo.fr>
Hi Pascal,

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" <····@mouse-potato.com> wrote in message 
···················@thalassa.informatimago.com...
> "Rob Thorpe" <·············@antenova.com> writes:
>
>> Christophe wrote:
>>> Hi,
>>>
>>> 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.
>
>
> -- 
> __Pascal Bourguignon__                     http://www.informatimago.com/
>
> "Logiciels libres : nourris au code source sans farine animale." 
From: Pascal Costanza
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <41hpamF1f2mglU1@individual.net>
Christian Jullien wrote:
> Hi Pascal,
> 
> 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.

> 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".

Hierarchical packages exist in Allegro Common Lisp - 
http://www.franz.com/support/tech_corner/hierpackuser.lhtml - and as a 
library for other Common Lisps - 
http://www.tfeb.org/lisp/hax.html#HIERARCHICAL-PACKAGES

> 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.

This sounds like the hard part.


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Christophe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135851539.150953.274890@g49g2000cwa.googlegroups.com>
I am still carefully reading your messages.

Thanks to everyone for your advices.
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b3bee7$0$6652$8fcfb975@news.wanadoo.fr>
"Pascal Costanza" <··@p-cos.net> wrote in message 
····················@individual.net...
> Christian Jullien wrote:
>> Hi Pascal,
>>
>> 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".
>
> Hierarchical packages exist in Allegro Common Lisp - 
> http://www.franz.com/support/tech_corner/hierpackuser.lhtml - and as a 
> library for other Common Lisps - 
> http://www.tfeb.org/lisp/hax.html#HIERARCHICAL-PACKAGES

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.
>
> This sounds like the hard part.
>
>
> Pascal
>
> -- 
> My website: http://p-cos.net
> Closer to MOP & ContextL:
> http://common-lisp.net/project/closer/ 
From: Pascal Costanza
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <41huskF1e0ommU1@individual.net>
Christian Jullien wrote:
> "Pascal Costanza" <··@p-cos.net> wrote in message 
> ····················@individual.net...
> 
>>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.

Right.

> The task is globally the same as writing a Le-Lisp compiler that generates 
> Common Lisp code.

Probably.

> That why I said it will take about 6 month for an exprt in both Le-Lisp and 
> Common Lisp.

I didn't want to suggest that it's trivial to do this. Even for the 
stuff that seems straightforward at first, the devil is probably in the 
details.


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Christophe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135871807.937053.141880@g14g2000cwa.googlegroups.com>
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---"

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...."

"Le-Lisp is dynamically ----scoped----"

"---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." = ?
From: Rob Thorpe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135881085.835554.46170@g14g2000cwa.googlegroups.com>
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.
From: Pascal Bourguignon
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <877j9n2e86.fsf@thalassa.informatimago.com>
"Rob Thorpe" <·············@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 'and)
(defmacro and (&rest args)
  (cond
    ((null args) t)
    ((null (cdr args)) (car args))
    (t (let ((val (gensym)))
         `(let ((,val ,(car args)))
            (if ,val (and ,@(cdr args)) nil))))))


CAR, CDR and CONS are not specified to be special forms
because they can be implemented with the special form FUNCTION:


(remember that LAMBDA is a macro that expands to FUNCTION:

    (defun print-tree (tree &optional (stream *standard-output*))
      ;; WARNING: doesn't handle circles nor identify EQ subtrees.
      (cond
       ((null tree) (princ "()"))
       ((atom tree) (princ tree stream))
       (t (princ "(" stream)
          (dolist (item (butlast tree))
            (print-tree item stream)
            (princ " " stream))
          (print-tree (car (last tree)) stream)
          (princ ")" stream)))
      tree)

    (print-tree   (macroexpand-1 '(lambda (x) (1+ x))))

prints:

   (FUNCTION (LAMBDA (X) (1+ X)))

)


(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))

(values (car (cons 1 2)) (cdr (cons 1 2)))
--> 1 ;
    2


But FUNCTION or QUOTE couldn't be implemented with a function or a
macro (unless you implement a new level of interperter/compiler).


 
> I think I assumed too much prior knowledge in my previous post.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

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.
From: Pascal Costanza
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <41igirF1en8jdU1@individual.net>
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:

(shadow 'let)

(defmacro let (bindings &body body)
   `(cl:let ,bindings
      (declare (special ,@(mapcar #'car bindings)))
      ,@body))

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.)

I hope this helps.


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b40f4d$0$29183$8fcfb975@news.wanadoo.fr>
Sorry, when experts talk together they quickly use their own slang.

"Christophe" <······@logatique.fr> wrote in message 
·····························@g14g2000cwa.googlegroups.com...
> 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. 
From: Pascal Costanza
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <41ijh2F1c8nmlU1@individual.net>
Christian Jullien wrote:

> If you prefer French, you can switch to fr.comp.lang.lisp unless Pascal 
> prefers English. 

I don't speak French, but feel free to switch anyway...


Pascal

-- 
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b22f9e$0$21277$8fcfb975@news.wanadoo.fr>
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" <······@logatique.fr> wrote in message 
····························@g47g2000cwa.googlegroups.com...
> Hi,
>
> 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.
>
> Any help will be welcomed!
> Thank you.
> 
From: Christophe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135765739.591159.280810@z14g2000cwz.googlegroups.com>
Thank you very much for your answer.
I just sent you a mail for some details.

If someone else has any other idea to complete the available solutions,
don't hesitate to let your opinion.
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b51aa6$0$19701$8fcfb975@news.wanadoo.fr>
To summerize the initial question:

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" <······@logatique.fr> wrote in message 
····························@g47g2000cwa.googlegroups.com...
> Hi,
>
> 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.
>
> Any help will be welcomed!
> Thank you.
> 
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b53135$0$20184$8fcfb975@news.wanadoo.fr>
"Christophe" <······@logatique.fr> wrote in message 
····························@g49g2000cwa.googlegroups.com...
> 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
From: Christophe
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <1135952980.021323.181300@g44g2000cwa.googlegroups.com>
Christian Jullien a écrit :

> 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 :

*.adb ("ADA body file")
*.ada ("ADA file")
*.ads ("ADA spec file)
*.cat ("Security catalog")
*.aida, *.am, *.deb
*.gpr ("Gnat Project File)
*.met
*.siz
...

ADA files just have to be compiled separately on the new system?
How do they work with *.lo?

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


> Could tou tell me Le-Lisp version you are running ?
I don't konw...



HAVE A GOOD WEEK END ;-)
From: Christian Jullien
Subject: Re: LELISP (-->LISP) --> C/C++ or other common language
Date: 
Message-ID: <43b54aca$0$21289$8fcfb975@news.wanadoo.fr>
"Christophe" <······@logatique.fr> wrote in message 
·····························@g44g2000cwa.googlegroups.com...

Christian Jullien a �crit :

> 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)?

The equivalent will be a shell script:

-- yourapp.sh --
#!/bin/sh
$LELISP/lelisp31bin -r $LELISP/yourapp.core
-----------------

> 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.