I am getting interested in writing applications for mobile phones, and
would of course prefer to use some kind of Lisp language. The standard
for many modern phones is J2ME, which is a cut-down Java Virtual Machine
(e.g. it has no support for floating-point arithmetic). I'd be very
interested to hear if anyone knows of any Lisp-like languages that target
such a platform.
Best wishes,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> writes:
> I am getting interested in writing applications for mobile phones, and
> would of course prefer to use some kind of Lisp language. The standard
> for many modern phones is J2ME, which is a cut-down Java Virtual Machine
> (e.g. it has no support for floating-point arithmetic). I'd be very
> interested to hear if anyone knows of any Lisp-like languages that target
> such a platform.
Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
managed to get a rudimentary application to run on a mobile phone
simulator, but IIRC it seems current J2ME relies on magic comments for
some things, and they weren't easy to create in linj. I don't know if
he pursued the issue further.
...Peder...
--
N/A
"Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
···················@modesty.klingenberg.no...
> William Bland <·······@abstractnonsense.com> writes:
>
> > I am getting interested in writing applications for mobile phones, and
> > would of course prefer to use some kind of Lisp language. The standard
> > for many modern phones is J2ME, which is a cut-down Java Virtual Machine
> > (e.g. it has no support for floating-point arithmetic). I'd be very
> > interested to hear if anyone knows of any Lisp-like languages that
target
> > such a platform.
>
> Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
> managed to get a rudimentary application to run on a mobile phone
> simulator, but IIRC it seems current J2ME relies on magic comments for
> some things, and they weren't easy to create in linj. I don't know if
> he pursued the issue further.
Hmmm... J2ME is just regular Java, with a few limitations (e.g. no floats)
and using the MIDP API, but the syntax is Java's, and I have never seen
any kind of "magic comments" there. As far as I can tell, any system
generating Java bytecode could be used for writing J2ME applications, as
long as it is able to use the MIDP classes instead of the regular J2SE
ones (I don't know if Linj does that).
--
Matthieu Villeneuve
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <circql$e6a$1@amma.irisa.fr>
Matthieu Villeneuve wrote:
> "Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
> ···················@modesty.klingenberg.no...
>
>>William Bland <·······@abstractnonsense.com> writes:
>>
>>
>>>I am getting interested in writing applications for mobile phones, and
>>>would of course prefer to use some kind of Lisp language. The standard
>>>for many modern phones is J2ME, which is a cut-down Java Virtual Machine
>>>(e.g. it has no support for floating-point arithmetic). I'd be very
>>>interested to hear if anyone knows of any Lisp-like languages that
>
> target
>
>>>such a platform.
>>
>>Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
>>managed to get a rudimentary application to run on a mobile phone
>>simulator, but IIRC it seems current J2ME relies on magic comments for
>>some things, and they weren't easy to create in linj. I don't know if
>>he pursued the issue further.
>
>
> Hmmm... J2ME is just regular Java, with a few limitations (e.g. no floats)
> and using the MIDP API, but the syntax is Java's, and I have never seen
> any kind of "magic comments" there. As far as I can tell, any system
> generating Java bytecode could be used for writing J2ME applications, as
> long as it is able to use the MIDP classes instead of the regular J2SE
> ones (I don't know if Linj does that).
>
Linj is not the tool you need.
Why ? Linj translates lisp code into java code. But J2ME code is not exactly java code. J2ME code requires optimization and so you need to be able to control the output java code. You need to write java in lisp and not java from lisp.
I followed the same way and my conclusion is : we need a s-expr java tool. This way you really write java code in lisp and you can write abstractions for it.
So i began to write sava. It's nearly operationnal, and cl compliant. I think i will make an announcement next week.
Christophe Turle
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87ekkubqi8.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Matthieu Villeneuve wrote:
>> "Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
>> ···················@modesty.klingenberg.no...
>>
>>>William Bland <·······@abstractnonsense.com> writes:
>>>
>>>
>>>>I am getting interested in writing applications for mobile phones, and
>>>>would of course prefer to use some kind of Lisp language. The standard
>>>>for many modern phones is J2ME, which is a cut-down Java Virtual Machine
>>>>(e.g. it has no support for floating-point arithmetic). I'd be very
>>>>interested to hear if anyone knows of any Lisp-like languages that
>> target
>>
>>>>such a platform.
>>>
>>>Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
>>>managed to get a rudimentary application to run on a mobile phone
>>>simulator, but IIRC it seems current J2ME relies on magic comments for
>>>some things, and they weren't easy to create in linj. I don't know if
>>>he pursued the issue further.
>> Hmmm... J2ME is just regular Java, with a few limitations (e.g. no
>> floats)
>> and using the MIDP API, but the syntax is Java's, and I have never seen
>> any kind of "magic comments" there. As far as I can tell, any system
>> generating Java bytecode could be used for writing J2ME applications, as
>> long as it is able to use the MIDP classes instead of the regular J2SE
>> ones (I don't know if Linj does that).
>>
>
> Linj is not the tool you need.
>
> Why ? Linj translates lisp code into java code. But J2ME code is not
> exactly java code. J2ME code requires optimization and so you need
> to be able to control the output java code. You need to write java
> in lisp and not java from lisp.
Could you elaborate on this?
What kind of control do you need?
Can you give me an example of the kind of support that you need?
Thanks in advance,
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <cis0i7$koh$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>Matthieu Villeneuve wrote:
>>
>>>"Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
>>>···················@modesty.klingenberg.no...
>>>
>>>
>>>>William Bland <·······@abstractnonsense.com> writes:
>>>>
>>>>
>>>>
>>>>>I am getting interested in writing applications for mobile phones, and
>>>>>would of course prefer to use some kind of Lisp language. The standard
>>>>>for many modern phones is J2ME, which is a cut-down Java Virtual Machine
>>>>>(e.g. it has no support for floating-point arithmetic). I'd be very
>>>>>interested to hear if anyone knows of any Lisp-like languages that
>>>
>>>target
>>>
>>>
>>>>>such a platform.
>>>>
>>>>Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
>>>>managed to get a rudimentary application to run on a mobile phone
>>>>simulator, but IIRC it seems current J2ME relies on magic comments for
>>>>some things, and they weren't easy to create in linj. I don't know if
>>>>he pursued the issue further.
>>>
>>>Hmmm... J2ME is just regular Java, with a few limitations (e.g. no
>>>floats)
>>>and using the MIDP API, but the syntax is Java's, and I have never seen
>>>any kind of "magic comments" there. As far as I can tell, any system
>>>generating Java bytecode could be used for writing J2ME applications, as
>>>long as it is able to use the MIDP classes instead of the regular J2SE
>>>ones (I don't know if Linj does that).
>>>
>>
>>Linj is not the tool you need.
>>
>>Why ? Linj translates lisp code into java code. But J2ME code is not
>>exactly java code. J2ME code requires optimization and so you need
>>to be able to control the output java code. You need to write java
>>in lisp and not java from lisp.
>
>
> Could you elaborate on this?
First, let me say that i find Linj a great tool.
Can you express in Linj, all possible Java programs ? I believe that's not the case (i presume it was not your goal). I think your goal was to generate one java program from a CL one. But in some apps, your goal is really to have a specific java program. An example of this is when you have to follow some coding rules (eg : always put an 'else' statement). I'm convinced we need to express java program as s-expr to do it the best.
I think J2ME programs require some fine tuning control. But perhaps i'm wrong, and after a while using sava, i will just thinking it adds nothing. Time will tell.
>
> What kind of control do you need?
1- extension : implement my own lisp->java translation.
2- java code layout
3- give the modifiers.
> Can you give me an example of the kind of support that you need?
1- redefining the way Linj convert the "format" command.
2-
if (...)
{
...
}
instead of
if (...) {
...
}
3- can i tell Linj to put a particular modifier on a field : "strictfp", "transient" ...
> Thanks in advance,
Just my 2 cents you know.
> Ant�nio Leit�o.
Christophe Turle
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87acviuy25.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Antonio Menezes Leitao wrote:
>> Christophe Turle <······@nospam.fr> writes:
>>
>>>Matthieu Villeneuve wrote:
>>>
>>>>"Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
>>>
>>>Linj is not the tool you need.
>>>
>>>Why ? Linj translates lisp code into java code. But J2ME code is not
>>>exactly java code. J2ME code requires optimization and so you need
>>>to be able to control the output java code. You need to write java
>>>in lisp and not java from lisp.
>> Could you elaborate on this?
>
> First, let me say that i find Linj a great tool.
>
> Can you express in Linj, all possible Java programs ?
Of course you can.
At the very least, Linj provides a few special operators (I call them
'assembly' operators) that allow you to express everything you might
possibly want.
Here is one example:
(defun foo (x/int)
(java "x++")
x)
The translation is:
public static int foo(int x) {
x++
return x;
}
Sometimes, you might also need to specify the type of a Java
expression:
(defun bar (x/int)
(if (> x 10)
(java-expression int "(x > 10) ? x++ : 5")
x))
The translation is:
public static int bar(int x) {
if (x > 10) {
return (x > 10) ? x++ : 5;
} else {
return x;
}
}
Obviously, these operators are rarely needed (very rarely indeed) as
normal Linj code can do whatever you want without resorting to
'assembly' code. To be honest, I've never used them, but in the
beginning I was afraid that they might be needed.
> I believe that's not the case (i presume it was not your goal).
I hope I proved that that is the case. In fact, it was one of my
goals. I should mention that one of the Linj goals is that the
generated Java code might be handed to 'normal' Java programmers.
They change it and sometimes I must translate their changes back into
Linj. I have never found a situation where I couldn't make that
reverse translation (even without using the above mentioned special
operators). This shows that, in practice, there's nothing that you
can do in Java but not in Linj.
> I think your goal was to generate one java program from a CL
> one.
Sure, but it's not really CL precisely because it must deal with all
the Java nuisances in an clear way. I spent a great deal of time
trying to make it look more and more like Common Lisp but, in the
beginning, it really looked like Java in an sexp form. I think I
managed to make it look like CL without limiting the generated Java
code but other users might have a different opinion, of course.
> But in some apps, your goal is really to have a specific java
> program. An example of this is when you have to follow some coding
> rules (eg : always put an 'else' statement). I'm convinced we need
> to express java program as s-expr to do it the best.
If that's your only requirement, I can assure you that it is trivial
to achieve. You just have to define a macro:
(defmacro my-when (test &body body)
`(if ,test
(progn ,@body)
(progn)))
Then, use the macro:
(defun baz (x/int)
(my-when (> x 6)
(my-when (< x 10)
(princ x))
(princ (+ x 6))))
and get a "nice" translation:
public static void baz(int x) {
if (x > 6) {
if (x < 10) {
System.out.print(x);
} else {
}
System.out.print(x + 6);
} else {
}
}
However, I must inform you that, AFAIK, that's not the recommended way
to write if-statements.
> I think J2ME programs require some fine tuning control. But perhaps
> i'm wrong, and after a while using sava, i will just thinking it
> adds nothing. Time will tell.
>
>> What kind of control do you need?
>
> 1- extension : implement my own lisp->java translation.
Can't help you on that :-)
> 2- java code layout.
Linj follows (I hope) the rules promoted by Sun. But there are
several variables that allow for small variations in code layout.
Unfortunately, they aren't well documented.
However, nothing prevents you of feeding the generated Java code
through a Java beautifier. There are several available.
> 3- give the modifiers.
That's trivial. It's exemplified in the manual:
(defun paranoid (a b c)
(declare (int a b)
(boolean c)
(returns double)
(visibility :private)
(throws i-o-exception write-aborted-exception)
(modifiers :abstract :final :synchronized)))
private static final synchronized abstract double paranoid(int a, int b, boolean c)
throws WriteAbortedException, IOException;
>
>> Can you give me an example of the kind of support that you need?
>
> 1- redefining the way Linj convert the "format" command.
In what way?
I ask because translating 'format' was one of the hardest tasks during
the development of Linj. I'm not very happy with the idea of having
to change it so I wonder what are you trying to achieve.
Can you give me an example?
> 2-
>
> if (...)
> {
> ...
> }
>
> instead of
>
> if (...) {
> ...
> }
Pragmatically speaking, you are not writing Java :-)
The code conventions are an important part of a programming language
and the coding standards presented in the Java Language Specification
strongly suggest that you should only use the second alternative.
But if using the first alternative is one of your requirements either
you use the above mentioned Java beautifiers (a trivial step in your
tool-chain) or I'll think about adding another variable that controls
the '{' placement.
> 3- can i tell Linj to put a particular modifier on a field : "strictfp", "transient" ...
Sure. Here is another example:
(defclass xpto ()
((a :type int :final t :transient t)
(b :initform 2.0 :strictfp t)))
And the translation:
public class Xpto extends Object {
// constants
protected final transient int a;
// slots
protected strictfp float b = 2.0f;
}
BTW, you can avoid the //constants and //slots comments after setting
the variable *write-category-comment* to nil.
I hope I answered your questions.
Thanks for your comments,
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <ciscrn$oje$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>Antonio Menezes Leitao wrote:
>>
>>>Christophe Turle <······@nospam.fr> writes:
>>>
>>>
>>>>Matthieu Villeneuve wrote:
>>>>
>>>>
>>>>>"Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
>>>>
>>>>Linj is not the tool you need.
>>>>
>>>>Why ? Linj translates lisp code into java code. But J2ME code is not
>>>>exactly java code. J2ME code requires optimization and so you need
>>>>to be able to control the output java code. You need to write java
>>>>in lisp and not java from lisp.
>>>
>>>Could you elaborate on this?
>>
>>First, let me say that i find Linj a great tool.
>>
>>Can you express in Linj, all possible Java programs ?
>
>
> Of course you can.
>
> At the very least, Linj provides a few special operators (I call them
> 'assembly' operators) that allow you to express everything you might
> possibly want.
>
> Here is one example:
>
> (defun foo (x/int)
> (java "x++")
> x)
>
> The translation is:
>
> public static int foo(int x) {
> x++
> return x;
> }
>
> Sometimes, you might also need to specify the type of a Java
> expression:
>
> (defun bar (x/int)
> (if (> x 10)
> (java-expression int "(x > 10) ? x++ : 5")
> x))
>
> The translation is:
>
> public static int bar(int x) {
> if (x > 10) {
> return (x > 10) ? x++ : 5;
> } else {
> return x;
> }
> }
>
> Obviously, these operators are rarely needed (very rarely indeed) as
> normal Linj code can do whatever you want without resorting to
> 'assembly' code. To be honest, I've never used them, but in the
> beginning I was afraid that they might be needed.
>
>
>>I believe that's not the case (i presume it was not your goal).
>
>
> I hope I proved that that is the case. In fact, it was one of my
> goals. I should mention that one of the Linj goals is that the
> generated Java code might be handed to 'normal' Java programmers.
> They change it and sometimes I must translate their changes back into
> Linj. I have never found a situation where I couldn't make that
> reverse translation (even without using the above mentioned special
> operators). This shows that, in practice, there's nothing that you
> can do in Java but not in Linj.
>
>
>>I think your goal was to generate one java program from a CL
>>one.
>
>
> Sure, but it's not really CL precisely because it must deal with all
> the Java nuisances in an clear way. I spent a great deal of time
> trying to make it look more and more like Common Lisp but, in the
> beginning, it really looked like Java in an sexp form. I think I
> managed to make it look like CL without limiting the generated Java
> code but other users might have a different opinion, of course.
>
>
>>But in some apps, your goal is really to have a specific java
>>program. An example of this is when you have to follow some coding
>>rules (eg : always put an 'else' statement). I'm convinced we need
>>to express java program as s-expr to do it the best.
>
>
> If that's your only requirement, I can assure you that it is trivial
> to achieve. You just have to define a macro:
>
> (defmacro my-when (test &body body)
> `(if ,test
> (progn ,@body)
> (progn)))
>
> Then, use the macro:
>
> (defun baz (x/int)
> (my-when (> x 6)
> (my-when (< x 10)
> (princ x))
> (princ (+ x 6))))
>
> and get a "nice" translation:
>
> public static void baz(int x) {
> if (x > 6) {
> if (x < 10) {
> System.out.print(x);
> } else {
>
> }
> System.out.print(x + 6);
> } else {
>
> }
> }
>
> However, I must inform you that, AFAIK, that's not the recommended way
> to write if-statements.
>
>
>>I think J2ME programs require some fine tuning control. But perhaps
>>i'm wrong, and after a while using sava, i will just thinking it
>>adds nothing. Time will tell.
>>
>>
>>>What kind of control do you need?
>>
>>1- extension : implement my own lisp->java translation.
>
>
> Can't help you on that :-)
>
>
>>2- java code layout.
>
>
> Linj follows (I hope) the rules promoted by Sun. But there are
> several variables that allow for small variations in code layout.
> Unfortunately, they aren't well documented.
>
> However, nothing prevents you of feeding the generated Java code
> through a Java beautifier. There are several available.
>
>
>>3- give the modifiers.
>
>
> That's trivial. It's exemplified in the manual:
>
> (defun paranoid (a b c)
> (declare (int a b)
> (boolean c)
> (returns double)
> (visibility :private)
> (throws i-o-exception write-aborted-exception)
> (modifiers :abstract :final :synchronized)))
>
> private static final synchronized abstract double paranoid(int a, int b, boolean c)
> throws WriteAbortedException, IOException;
>
>
>>
>>
>>>Can you give me an example of the kind of support that you need?
>>
>>1- redefining the way Linj convert the "format" command.
>
>
> In what way?
>
> I ask because translating 'format' was one of the hardest tasks during
> the development of Linj. I'm not very happy with the idea of having
> to change it so I wonder what are you trying to achieve.
>
> Can you give me an example?
>
>>2-
>>
>>if (...)
>>{
>> ...
>>}
>>
>>instead of
>>
>>if (...) {
>> ...
>>}
>
>
> Pragmatically speaking, you are not writing Java :-)
>
> The code conventions are an important part of a programming language
> and the coding standards presented in the Java Language Specification
> strongly suggest that you should only use the second alternative.
perhaps i'm not agree with them ;-)
> But if using the first alternative is one of your requirements either
> you use the above mentioned Java beautifiers (a trivial step in your
> tool-chain) or I'll think about adding another variable that controls
> the '{' placement.
>
>
>>3- can i tell Linj to put a particular modifier on a field : "strictfp", "transient" ...
>
>
> Sure. Here is another example:
>
> (defclass xpto ()
> ((a :type int :final t :transient t)
> (b :initform 2.0 :strictfp t)))
>
> And the translation:
>
> public class Xpto extends Object {
>
> // constants
>
> protected final transient int a;
>
> // slots
>
> protected strictfp float b = 2.0f;
> }
>
> BTW, you can avoid the //constants and //slots comments after setting
> the variable *write-category-comment* to nil.
>
> I hope I answered your questions.
yes, in fact you answered all my questions. And i will keep an eye on Linj (it was my prefered lisp->java tool).
But, there's still 2 points :
1- It's not enough open for me. Take the example of '{', you say that you may do it (thx ;-)). I prefer a tool every one can make evolved. There are too many layers hidden and known just from you.
2- There's a side-effect of using cl function name to finally produce "equivalent" java expressions. You always have to do the translation in your head. It's why i prefer seeing java s-expr. But i'm not sure of this.
I'm semi-convinced because i've not yet written java code using lisp. So i have no killer examples, just forseen visions ;-). The next step to be trully convinced on one way or the other is to do. So i will practice. Next week, i hope to be able to introduce sava with samples from Sun blue print Divelog.
to conclude 1/2 point for you ;-)
> Thanks for your comments,
>
> Ant�nio Leit�o.
Christophe Turle
> yes, in fact you answered all my questions. And i will keep an eye on
> Linj (it was my prefered lisp->java tool).
>
> But, there's still 2 points :
>
> 1- It's not enough open for me. Take the example of '{', you say that
> you may do it (thx ;-)). I prefer a tool every one can make evolved.
> There are too many layers hidden and known just from you.
>
> 2- There's a side-effect of using cl function name to finally produce
> "equivalent" java expressions. You always have to do the translation in
> your head. It's why i prefer seeing java s-expr. But i'm not sure of
> this.
>
> I'm semi-convinced because i've not yet written java code using lisp. So
> i have no killer examples, just forseen visions ;-). The next step to be
> trully convinced on one way or the other is to do. So i will practice.
> Next week, i hope to be able to introduce sava with samples from Sun
> blue print Divelog.
>
> to conclude 1/2 point for you ;-)
>
>> Thanks for your comments,
>> Ant�nio Leit�o.
>
>
> Christophe Turle
>
Sure you don't want to program in plain Java ? ;)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <citvq5$5vq$1@amma.irisa.fr>
John Thingstad wrote:
>
>> yes, in fact you answered all my questions. And i will keep an eye on
>> Linj (it was my prefered lisp->java tool).
>>
>> But, there's still 2 points :
>>
>> 1- It's not enough open for me. Take the example of '{', you say that
>> you may do it (thx ;-)). I prefer a tool every one can make evolved.
>> There are too many layers hidden and known just from you.
>>
>> 2- There's a side-effect of using cl function name to finally produce
>> "equivalent" java expressions. You always have to do the translation
>> in your head. It's why i prefer seeing java s-expr. But i'm not sure
>> of this.
>>
>> I'm semi-convinced because i've not yet written java code using lisp.
>> So i have no killer examples, just forseen visions ;-). The next step
>> to be trully convinced on one way or the other is to do. So i will
>> practice. Next week, i hope to be able to introduce sava with samples
>> from Sun blue print Divelog.
>>
>> to conclude 1/2 point for you ;-)
>>
>>> Thanks for your comments,
>>> Ant�nio Leit�o.
>>
>>
>>
>> Christophe Turle
>>
>
> Sure you don't want to program in plain Java ? ;)
>
Sure. My goal is to make my tool programs in java not me ! But i want to expose all the layers. And the basic one is java s-expr. From it, i (or others) will perhaps converge to Linj but with the possibility to hack each level to suit your own taste. If i'm right, lot's of code may also be used to write other 's???' module (sphp, sharp, s++, ...). Opening Lisp to all other language. It's a different approach from the FFI one. At the end there's no more lisp code. Of course, if you can use Lisp directly, the better ;-)
And when you have this foundation, you can really rock : what about a S2ME module using SAVA with all Sun J2ME idioms. I bet you can win most run contests with them.
Christophe Turle
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <874qlpgwkx.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Sure. My goal is to make my tool programs in java not me ! But i
> want to expose all the layers. And the basic one is java
> s-expr. From it, i (or others) will perhaps converge to Linj but
> with the possibility to hack each level to suit your own taste.
Linj also expose several layers. They are just not documented well
enough (because I must also spend my time on other projects). But
whenever someone asks me how to do something I explain how to access
the lower levels. Fortunately, it is rarely needed.
> If i'm right, lot's of code may also be used to write other 's???'
> module (sphp, sharp, s++, ...). Opening Lisp to all other
> language. It's a different approach from the FFI one. At the end
> there's no more lisp code. Of course, if you can use Lisp directly,
> the better ;-)
Been there, done that. I might have been unsufficiently smart for the
task but my conclusion was that if you want to achive good-looking
code on the target language from good-looking code on the source
language you must include lots and lots of knowledge about the target
language on the translator _and_ on your source language. This means
that you will have to build one different translator for each target
language and, moreover, your source language will only be 'general
purpose' in the intersection of the features common to all target
languages. The larger the number of target languages, the smaller the
intersection. In the end, you might end up with a incredibly huge
language that has very similar (but different) constructs. The bad
news is that each source program will only be translatable to one
specific target language.
> And when you have this foundation, you can really rock : what about
> a S2ME module using SAVA with all Sun J2ME idioms. I bet you can win
> most run contests with them.
I wish you luck.
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <cj0o6i$t3$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>Sure. My goal is to make my tool programs in java not me ! But i
>>want to expose all the layers. And the basic one is java
>>s-expr. From it, i (or others) will perhaps converge to Linj but
>>with the possibility to hack each level to suit your own taste.
>
>
> Linj also expose several layers. They are just not documented well
> enough (because I must also spend my time on other projects). But
> whenever someone asks me how to do something I explain how to access
> the lower levels. Fortunately, it is rarely needed.
>
>
>>If i'm right, lot's of code may also be used to write other 's???'
>>module (sphp, sharp, s++, ...). Opening Lisp to all other
>>language. It's a different approach from the FFI one. At the end
>>there's no more lisp code. Of course, if you can use Lisp directly,
>>the better ;-)
>
>
> Been there, done that. I might have been unsufficiently smart for the
> task but my conclusion was that if you want to achive good-looking
> code on the target language from good-looking code on the source
> language you must include lots and lots of knowledge about the target
> language on the translator _and_ on your source language. This means
> that you will have to build one different translator for each target
> language and, moreover, your source language will only be 'general
> purpose' in the intersection of the features common to all target
> languages. The larger the number of target languages, the smaller the
> intersection. In the end, you might end up with a incredibly huge
> language that has very similar (but different) constructs.
> The bad
> news is that each source program will only be translatable to one
> specific target language.
one counter-example : you !
If i give you a spec ( the source program ) i'm sure you are able to translate it to lots
of specific languages. And i'm pretty sure that beside some specific knowledge about each target language
you also have lots of general (design) knowledge you can apply for each translation.
The goal is to express it in lisp (through specific DSL). So it can be re-used.
>>And when you have this foundation, you can really rock : what about
>>a S2ME module using SAVA with all Sun J2ME idioms. I bet you can win
>>most run contests with them.
>
>
> I wish you luck.
luck ? i hope it is not a requirement ;-) but thx.
> Ant�nio Leit�o.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87acvhyj41.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
>> The code conventions are an important part of a programming language
>> and the coding standards presented in the Java Language Specification
>> strongly suggest that you should only use the second alternative.
>
> perhaps i'm not agree with them ;-)
You don't have to. But if you want to see your code being used by
other Java programmers you should pay attention not only to syntax and
semantics but also to pragmatics. If you don't need to see your code
being used by other Java programmers then it doesn't really matter if
the '{' is on the previous line or in the next line.
>> I hope I answered your questions.
>
> yes, in fact you answered all my questions. And i will keep an eye
> on Linj (it was my prefered lisp->java tool).
>
> But, there's still 2 points :
>
> 1- It's not enough open for me. Take the example of '{', you say
> that you may do it (thx ;-)). I prefer a tool every one can make
> evolved. There are too many layers hidden and known just from you.
I'm not sure yet that open source software is the solution to software
evolution. But I have an open mind (I hope) so maybe I can be
convinced that it's a good solution.
> 2- There's a side-effect of using cl function name to finally
> produce "equivalent" java expressions. You always have to do the
> translation in your head. It's why i prefer seeing java s-expr. But
> i'm not sure of this.
I'm not sure I understand you but if you are talking about translation
between Lisp names and Java names then you don't need to worry. Linj
obeys your names. Here are one example (from the manual) that shows
several alternatives:
(defun ···@^ (!! a-normal-name reallyFunny)
(declare (type int !! a-normal-name reallyFunny))
(let ((BIGNAME 1)
(ok? t))
(if (< !! +the-biggest+)
BIGNAME
(···@^ (1- !!) 0 (+ a-normal-name reallyFunny)))))
The translation shows that the names that follow Lisp conventions are
translated into Java conventions and names that follow Java
conventions are translated verbatim:
public static int percent$SharpAtUp(int bangBang, int aNormalName, int reallyFunny) {
int BIGNAME = 1;
boolean okP = true;
if (bangBang < THE_BIGGEST) {
return BIGNAME;
} else {
return percent$SharpAtUp(bangBang - 1, 0, aNormalName + reallyFunny);
}
}
Note, in particular, the translation of the names reallyFunny and
BIGNAME. They follow Java conventions and are not subject to further
translation.
Thanks again for your comments,
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <ciu1ol$6m5$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>>The code conventions are an important part of a programming language
>>>and the coding standards presented in the Java Language Specification
>>>strongly suggest that you should only use the second alternative.
>>
>>perhaps i'm not agree with them ;-)
>
>
> You don't have to. But if you want to see your code being used by
> other Java programmers you should pay attention not only to syntax and
> semantics but also to pragmatics.
Yes i agree. But their '{' is really not a good choice. The code you look at is really not as clear as if you have added a newline. And clarity of code is one of the most important thing when program. I love programs you can understand quickly. It's why i love DSL. It's difficult but the reward is there, for sure.
> If you don't need to see your code
> being used by other Java programmers then it doesn't really matter if
> the '{' is on the previous line or in the next line.
>
>
>>>I hope I answered your questions.
>>
>>yes, in fact you answered all my questions. And i will keep an eye
>>on Linj (it was my prefered lisp->java tool).
>>
>>But, there's still 2 points :
>>
>>1- It's not enough open for me. Take the example of '{', you say
>>that you may do it (thx ;-)). I prefer a tool every one can make
>>evolved. There are too many layers hidden and known just from you.
>
>
> I'm not sure yet that open source software is the solution to software
> evolution. But I have an open mind (I hope) so maybe I can be
> convinced that it's a good solution.
Linj is not a finished product (Java 2.56 may add a new feature). So imagine now that you die tomorrow. What if someone want to continue Linj-like program ? He may use your tool to have an idea of what input-ouput is good but that's all. He has to restart from scratch. bad news. The least is that it's not sufficient to be open source to add wealth (last night "hackers & painters" clin d'oeil ;-)) to the lisp community. You have to design for others, with cleanly readable open layers, each layer may be swapped by others (and they will be). Some design patterns will then emerge, but at the difference of other language, we will able to use them with lisp itself. That way we will able to tackle problems not even thinkable by language community. And then you may become rich.
Christophe Turle.
"If it's not simple, it's not finished, and even ..."
Christophe Turle wrote:
> Antonio Menezes Leitao wrote:
>> Christophe Turle <······@nospam.fr> writes:
>>>> The code conventions are an important part of a programming language
>>>> and the coding standards presented in the Java Language Specification
>>>> strongly suggest that you should only use the second alternative.
>>> perhaps i'm not agree with them ;-)
>> You don't have to. But if you want to see your code being used by
>> other Java programmers you should pay attention not only to syntax and
>> semantics but also to pragmatics.
> Yes i agree. But their '{' is really not a good choice. The code you
> look at is really not as clear as if you have added a newline.
My newsreader displays your paragraph as one long line.
Adding newlines once in a while would indeed be a good idea ;-)
--
Jens Axel Søgaard
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87wtylqir0.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
>>>
>>>But, there's still 2 points :
>>>
>>>1- It's not enough open for me. Take the example of '{', you say
>>>that you may do it (thx ;-)). I prefer a tool every one can make
>>>evolved. There are too many layers hidden and known just from you.
>> I'm not sure yet that open source software is the solution to
>> software
>> evolution. But I have an open mind (I hope) so maybe I can be
>> convinced that it's a good solution.
> Linj is not a finished product (Java 2.56 may add a new
> feature). So imagine now that you die tomorrow.
> What if someone want to continue Linj-like program ?
No problem. Linj does not belong to me. It belongs to an entity
named eValuator and the life-span of such entity is not directly
related to my life-span. There are other members of eValuator that
know about Linj and that can continue the development of Linj. That's
the beauty of an organization. It lives even when its members die
(sometimes the opposite happens, too).
> He may use your tool to have an idea of what input-ouput is good but
> that's all. He has to restart from scratch. bad news. The least is
> that it's not sufficient to be open source to add wealth (last night
> "hackers & painters" clin d'oeil ;-)) to the lisp community. You
> have to design for others, with cleanly readable open layers, each
> layer may be swapped by others (and they will be).
I would like to see a complex piece of software where those things are
as easy to do as you seem to think.
> Some design patterns will then emerge, but at the difference of
> other language, we will able to use them with lisp itself. That way
> we will able to tackle problems not even thinkable by language
> community. And then you may become rich.
Could you elaborate on that last sentence? Somehow, I dont see how to
derive that conclusion from the previous statements. Maybe you can
give me one example.
Thanks a lot,
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <cj0qhv$1gg$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>>>But, there's still 2 points :
>>>>
>>>>1- It's not enough open for me. Take the example of '{', you say
>>>>that you may do it (thx ;-)). I prefer a tool every one can make
>>>>evolved. There are too many layers hidden and known just from you.
>>>
>>>I'm not sure yet that open source software is the solution to
>>>software
>>>evolution. But I have an open mind (I hope) so maybe I can be
>>>convinced that it's a good solution.
>
>
>> Linj is not a finished product (Java 2.56 may add a new
>>feature). So imagine now that you die tomorrow.
>>What if someone want to continue Linj-like program ?
>
>
> No problem. Linj does not belong to me. It belongs to an entity
> named eValuator and the life-span of such entity is not directly
> related to my life-span. There are other members of eValuator that
> know about Linj and that can continue the development of Linj. That's
> the beauty of an organization. It lives even when its members die
> (sometimes the opposite happens, too).
company dies too as you write ...
And during that time only eValuator can improve it. We may only give suggestions.
But as a product i understand the way it is.
>>He may use your tool to have an idea of what input-ouput is good but
>>that's all. He has to restart from scratch. bad news. The least is
>>that it's not sufficient to be open source to add wealth (last night
>>"hackers & painters" clin d'oeil ;-)) to the lisp community. You
>>have to design for others, with cleanly readable open layers, each
>>layer may be swapped by others (and they will be).
>
>
> I would like to see a complex piece of software where those things are
> as easy to do as you seem to think.
Easy ?? oh no, i don't think it's easy at all. Producing simple, clean things are
the graal whatever the domain. But we have to try and try again.
example : here some code from my "sava-lg.lisp" file. 95% of the content is like this :
----------------------------------------------------------
...
(def-keyword-type modifier public protected private static abstract final native synchronized transient volatile strictfp)
(def-declaration class ((modifiers :0-* modifier-p) name (members :0-*)))
(def-declaration field ((modifiers :0-* modifier-p) type name))
(def-declaration import ((identifiers :0-*)))
(def-declaration method ((modifiers :0-* modifier-p) type name (args 1 listp) (statements :0-*)))
...
----------------------------------------------------------------------------
It's clean, but not finished. there's no sign of "extends" in the class declaration. But with little time,
every one may update this file and go his own way.
an other code snippet : "sava-print.lisp"
----------------------------------------------------------------------------
...
(set-pprint-dispatch 'sava:class-declaration
(lambda (s x)
(let ((*class-name* (sava::class-declaration-name x)))
(format s "~{~s ~}class ~s"
(sava::class-declaration-modifiers x)
(sava::class-declaration-name x) )
(pprint-newline :mandatory s)
(pprint-logical-block (s (sava::class-declaration-members x))
(write-char #\{ s)
(pprint-indent :block 2 s)
(loop (pprint-exit-if-list-exhausted)
(pprint-newline :mandatory s)
(write (pprint-pop) :stream s) ))
(pprint-newline :mandatory s)
(write-char #\} s)
))
0 *PD* )
(set-pprint-dispatch 'sava:import-declaration
(lambda (s x)
(format s "import ~{~W~^.~} ;"
(sava::import-declaration-identifiers x) ))
0 *PD* )
...
----------------------------------------------------------------------------
It's not finished and not as beautiful as the file before. The key point is : If you know the pretty-printer,
you may change this file very quickly. All is (or should) centered on pretty-printing. Orthogonality. Or even you may
use you own sava-print. modularity. Or perahps re-use (by refactoring some code) it to pretty-print 's++'. abstraction.
(what's makes me hungry is that i'm using Clisp and its pretty-printer is buggy !)
there's also the utils file. not well polished. But i see in it some pattern-matching framework, i may extract.
>
>>Some design patterns will then emerge, but at the difference of
>>other language, we will able to use them with lisp itself. That way
>>we will able to tackle problems not even thinkable by language
>>community. And then you may become rich.
>
>
> Could you elaborate on that last sentence? Somehow, I dont see how to
> derive that conclusion from the previous statements. Maybe you can
> give me one example.
Imagine you compete with your lisp and all other guys just have an assembler. Don't you think you may become rich ?
Higher level makes you gain time, and when you have time you can spend it thinking about new, difficult problems to solve.
And then you win $$$ ;-)
Christophe Turle.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87brfvprwq.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Antonio Menezes Leitao wrote:
>> Christophe Turle <······@nospam.fr> writes:
>>
>>>>>But, there's still 2 points :
>>>>>
>>>>>1- It's not enough open for me. Take the example of '{', you say
>>>>>that you may do it (thx ;-)). I prefer a tool every one can make
>>>>>evolved. There are too many layers hidden and known just from you.
>>>>
>>>>I'm not sure yet that open source software is the solution to
>>>>software
>>>>evolution. But I have an open mind (I hope) so maybe I can be
>>>>convinced that it's a good solution.
>>
>>> Linj is not a finished product (Java 2.56 may add a new
>>>feature). So imagine now that you die tomorrow.
>>> What if someone want to continue Linj-like program ?
>> No problem. Linj does not belong to me. It belongs to an entity
>> named eValuator and the life-span of such entity is not directly
>> related to my life-span. There are other members of eValuator that
>> know about Linj and that can continue the development of Linj. That's
>> the beauty of an organization. It lives even when its members die
>> (sometimes the opposite happens, too).
>
> company dies too as you write ...
>
> And during that time only eValuator can improve it. We may only give
> suggestions.
Do you prefer to spend your time debugging all the applications that
you use or do you prefer to tell the people who wrote them that you
found a bug (or some feature that you think is needed) and wait for
them to solve it?
I must say that I like when I fill a bug report for, say, Allegro
Common Lisp and they solve the bug for me. It would be a huge waste
of my time to try to read, understand, and modify the Allegro Common
Lisp implementation. In the end, I would probably introduce even more
bugs.
> But as a product i understand the way it is.
Note that I never said that I will never open-source Linj. But I'm
not yet convinced it's the best solution. I'll wait a little longer
to see some really, really, convincing argument and then I might
change my opinion.
>>>He may use your tool to have an idea of what input-ouput is good but
>>>that's all. He has to restart from scratch. bad news. The least is
>>>that it's not sufficient to be open source to add wealth (last night
>>>"hackers & painters" clin d'oeil ;-)) to the lisp community. You
>>>have to design for others, with cleanly readable open layers, each
>>>layer may be swapped by others (and they will be).
And who will pay all that effort?
> ----------------------------------------------------------
> ...
>
> It's clean, but not finished. there's no sign of "extends" in the
> class declaration. But with little time, every one may update this
> file and go his own way.
>
You say "little time" but I'm sure you are grossly underestimating the
effort needed to extend your tool. Linj has reached a point where it
is quite simple to add extensions but it took quite a long time to
reach this point. But if someone finds a bug while adding an
extension he might spend a huge amount of time just trying to
understand it.
> an other code snippet : "sava-print.lisp"
> ...
I'm looking forward to see an example of sava source code (including a
method definition, if possible) and the result of the translation.
> It's not finished and not as beautiful as the file before. The key
> point is : If you know the pretty-printer, you may change this file
> very quickly.
That's an easy task (but learning the pretty-printer is not) and,
moreover, you are talking about something that a Java code beautifier
can solve instantly.
I would like to hear your opinion regarding changing other (more
complex) parts of your translator such as messing with the type
inference process. Do you think that's something easy to do?
> All is (or should) centered on pretty-printing. Orthogonality. Or
> even you may use you own sava-print. modularity. Or perahps re-use
> (by refactoring some code) it to pretty-print 's++'. abstraction.
Sure. Someone can change the pretty-printer. Then, you decide that
you want to change your AST. What happens then?
> (what's makes me hungry is that i'm using Clisp and its
> pretty-printer is buggy !)
So, according to your theory, you just have to look at the CLISP
source code, identify the bug and correct it. I'll wait to see how
long will it take you to do that.
But in the good spirit of the open-source community, I'll give you an
hint. One of the problems with CLISP's pretty printer is that they
didn't implement real pretty-printer streams. AFAIKS, they use
dynamic variables to contain the pretty-printing information and this
affects all streams, even those that do not want to pretty-print
anything such as the one created by the princ-to-string function.
You might try if the following solution helps your tool:
(progn
(let ((old-princ-to-string (symbol-function 'princ-to-string)))
(defun new-princ-to-string (obj)
(let ((sys::*prin-line-prefix* nil)
(sys::*prin-miserp* nil)
(sys::*prin-indentation* 0)
(sys::*prin-level* 0))
(funcall old-princ-to-string obj))))
(compile 'new-princ-to-string)
(setf (symbol-function 'princ-to-string)
(symbol-function 'new-princ-to-string)))
It helps Linj a lot (it doesn't generate incorrect code) but the
result is ugly anyway. Of course, there are more bugs to solve so you
still have lots of places where you can test your theory.
>>>Some design patterns will then emerge, but at the difference of
>>>other language, we will able to use them with lisp itself. That way
>>>we will able to tackle problems not even thinkable by language
>>>community. And then you may become rich.
>> Could you elaborate on that last sentence? Somehow, I dont see how
>> to derive that conclusion from the previous statements. Maybe you
>> can give me one example.
>
> Imagine you compete with your lisp and all other guys just have an
> assembler. Don't you think you may become rich ? Higher level makes
> you gain time, and when you have time you can spend it thinking
> about new, difficult problems to solve. And then you win $$$ ;-)
Now I'm sure: you are joking.
Ant�nio Leit�o.
"Antonio Menezes Leitao" <··············@evaluator.pt> a �crit dans le
message de ···················@evaluator.pt...
> Christophe Turle <······@nospam.fr> writes:
>
> > Antonio Menezes Leitao wrote:
> >> Christophe Turle <······@nospam.fr> writes:
> >>
> >>>>>But, there's still 2 points :
> >>>>>
> >>>>>1- It's not enough open for me. Take the example of '{', you say
> >>>>>that you may do it (thx ;-)). I prefer a tool every one can make
> >>>>>evolved. There are too many layers hidden and known just from you.
> >>>>
> >>>>I'm not sure yet that open source software is the solution to
> >>>>software
> >>>>evolution. But I have an open mind (I hope) so maybe I can be
> >>>>convinced that it's a good solution.
> >>
> >>> Linj is not a finished product (Java 2.56 may add a new
> >>>feature). So imagine now that you die tomorrow.
> >>> What if someone want to continue Linj-like program ?
> >> No problem. Linj does not belong to me. It belongs to an entity
> >> named eValuator and the life-span of such entity is not directly
> >> related to my life-span. There are other members of eValuator that
> >> know about Linj and that can continue the development of Linj. That's
> >> the beauty of an organization. It lives even when its members die
> >> (sometimes the opposite happens, too).
> >
> > company dies too as you write ...
> >
> > And during that time only eValuator can improve it. We may only give
> > suggestions.
>
> Do you prefer to spend your time debugging all the applications that
> you use or do you prefer to tell the people who wrote them that you
> found a bug (or some feature that you think is needed) and wait for
> them to solve it?
>
> I must say that I like when I fill a bug report for, say, Allegro
> Common Lisp and they solve the bug for me. It would be a huge waste
> of my time to try to read, understand, and modify the Allegro Common
> Lisp implementation. In the end, I would probably introduce even more
> bugs.
It depends where your interest lies. If your are fond of Lisp interpreter
mechanics, having access to Allegro lisp code could be a great thing and not
a waste of time. Some people will just want to use Linj and so it's ok for
them. Others want more because they are interested in this type of things.
> > But as a product i understand the way it is.
>
> Note that I never said that I will never open-source Linj. But I'm
> not yet convinced it's the best solution. I'll wait a little longer
> to see some really, really, convincing argument and then I might
> change my opinion.
>
> >>>He may use your tool to have an idea of what input-ouput is good but
> >>>that's all. He has to restart from scratch. bad news. The least is
> >>>that it's not sufficient to be open source to add wealth (last night
> >>>"hackers & painters" clin d'oeil ;-)) to the lisp community. You
> >>>have to design for others, with cleanly readable open layers, each
> >>>layer may be swapped by others (and they will be).
>
> And who will pay all that effort?
>
1- you are paid by works of others in your community. Some used lots of
their time to make cmucl, clisp, McClim, Emacs, Slime, ... I thanx them a
lot. And making a tool they may use one is a reward in itself.
2- If you want to make money, use your community to sell out of your
community. Selling is better than nothing to help progress but giving is
even better. So give to your community to push its progress and then use it
to make and sell products outside. just my 2 cents.
>
> > ----------------------------------------------------------
> > ...
> >
> > It's clean, but not finished. there's no sign of "extends" in the
> > class declaration. But with little time, every one may update this
> > file and go his own way.
> >
>
> You say "little time" but I'm sure you are grossly underestimating the
> effort needed to extend your tool. Linj has reached a point where it
> is quite simple to add extensions but it took quite a long time to
> reach this point. But if someone finds a bug while adding an
> extension he might spend a huge amount of time just trying to
> understand it.
>
> > an other code snippet : "sava-print.lisp"
> > ...
>
> I'm looking forward to see an example of sava source code (including a
> method definition, if possible) and the result of the translation.
ok, have a look : http://perso.wanadoo.fr/turle/lisp/sava.html
> > It's not finished and not as beautiful as the file before. The key
> > point is : If you know the pretty-printer, you may change this file
> > very quickly.
>
> That's an easy task (but learning the pretty-printer is not)
The pretty-printer is part of standard common-lisp. It's useful to know
about it.
> and,
> moreover, you are talking about something that a Java code beautifier
> can solve instantly.
They are not enough open for my taste.
And pretty-printing is so useful that it's important to master it. In lisp
of course !
> I would like to hear your opinion regarding changing other (more
> complex) parts of your translator such as messing with the type
> inference process. Do you think that's something easy to do?
For now, I'm not there and i've never tackle this problem. The integration
shouldn't be over-difficult. And for the inference engine, someone more
competent than me may do it.
> > All is (or should) centered on pretty-printing. Orthogonality. Or
> > even you may use you own sava-print. modularity. Or perahps re-use
> > (by refactoring some code) it to pretty-print 's++'. abstraction.
>
> Sure. Someone can change the pretty-printer. Then, you decide that
> you want to change your AST. What happens then?
AST ??
I and others are free to change it at any time. The best will hopefully stay
alive.
Backward compatibilty ? hum, not with a freeware ! The "someone" will follow
because he agrees
with the change or he will stay with the last version or he will begin a new
version.
> > (what's makes me hungry is that i'm using Clisp and its
> > pretty-printer is buggy !)
>
> So, according to your theory, you just have to look at the CLISP
> source code, identify the bug and correct it. I'll wait to see how
> long will it take you to do that.
First, i'm not interested by building Lisp interpreters. clisp will stay a
black box.
Second , if i were, i'm not sure the Clisp code is extensible enough for me.
it's just
open-source. So it would take some times.
> But in the good spirit of the open-source community, I'll give you an
> hint. One of the problems with CLISP's pretty printer is that they
> didn't implement real pretty-printer streams. AFAIKS, they use
> dynamic variables to contain the pretty-printing information and this
> affects all streams, even those that do not want to pretty-print
> anything such as the one created by the princ-to-string function.
>
> You might try if the following solution helps your tool:
>
> (progn
> (let ((old-princ-to-string (symbol-function 'princ-to-string)))
> (defun new-princ-to-string (obj)
> (let ((sys::*prin-line-prefix* nil)
> (sys::*prin-miserp* nil)
> (sys::*prin-indentation* 0)
> (sys::*prin-level* 0))
> (funcall old-princ-to-string obj))))
>
> (compile 'new-princ-to-string)
>
> (setf (symbol-function 'princ-to-string)
> (symbol-function 'new-princ-to-string)))
>
> It helps Linj a lot (it doesn't generate incorrect code) but the
> result is ugly anyway. Of course, there are more bugs to solve so you
> still have lots of places where you can test your theory.
I tested your trick, but i have yet the bad indentation. :(
> >>>Some design patterns will then emerge, but at the difference of
> >>>other language, we will able to use them with lisp itself. That way
> >>>we will able to tackle problems not even thinkable by language
> >>>community. And then you may become rich.
>
> >> Could you elaborate on that last sentence? Somehow, I dont see how
> >> to derive that conclusion from the previous statements. Maybe you
> >> can give me one example.
> >
> > Imagine you compete with your lisp and all other guys just have an
> > assembler. Don't you think you may become rich ? Higher level makes
> > you gain time, and when you have time you can spend it thinking
> > about new, difficult problems to solve. And then you win $$$ ;-)
>
> Now I'm sure: you are joking.
are you sure ? "hackers & painters" from Paul Graham enlights my point of
vue on how to make money. you should read.
Christophe Turle.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87y8ixfjgv.fsf@evaluator.pt>
"ctu" <······@nospam.com> writes:
> "Antonio Menezes Leitao" <··············@evaluator.pt> a �crit dans le
> message de ···················@evaluator.pt...
>> Christophe Turle <······@nospam.fr> writes:
>>
>> >>>He may use your tool to have an idea of what input-ouput is good but
>> >>>that's all. He has to restart from scratch. bad news. The least is
>> >>>that it's not sufficient to be open source to add wealth (last night
>> >>>"hackers & painters" clin d'oeil ;-)) to the lisp community. You
>> >>>have to design for others, with cleanly readable open layers, each
>> >>>layer may be swapped by others (and they will be).
>>
>> And who will pay all that effort?
>>
> 1- you are paid by works of others in your community. Some used lots of
> their time to make cmucl, clisp, McClim, Emacs, Slime, ... I thanx them a
> lot. And making a tool they may use one is a reward in itself.
Given the fact that "cmucl", "clisp" and "emacs" are not digestible
things, I wonder how do you avoid starving. Let's be a bit more
realistic: food costs 'money' as you surely know. You can't pay food
with the 'works of others': you need money.
> 2- If you want to make money, use your community to sell out of your
> community. Selling is better than nothing to help progress but giving is
> even better. So give to your community to push its progress and then use it
> to make and sell products outside. just my 2 cents.
You are wrong. But don't worry: you will understand that in due
time :-)
>> I'm looking forward to see an example of sava source code (including a
>> method definition, if possible) and the result of the translation.
>
> ok, have a look : http://perso.wanadoo.fr/turle/lisp/sava.html
I did look at it and it looks promising. But having travelled the
same path that you are now entering I see some shortcommings that you
might want to think about:
- You are inventing a new language that looks like Java with
parenthesis. However, it's even more verbose than Java. In
particular, you force the programmer to explicitely mark method
calls with the symbol 'call' (there are 23 such occurrencies in
your example). That's unfriendly.
Compare
x.m1().m2() in Java
(call (call x m1) m2) in Sava
(m2 (m1 x)) in Linj
I suggest you think about a better syntax for method calls as they
are really frequent in Java.
- Your variable declarations are fully typed. However, if you look at
them you will immediately notice a pattern:
(var JMenuBar mb (new JMenuBar ()))
(var JMenu menu (new JMenu ("File")))
(var JMenuItem item (new JMenuItem ("Exit")))
(var DiveLog dl (new DiveLog ()))
This suggest that you can either invent a new syntax that avoids
duplication of the type (easy) or you add type-inference to
automatically infer the correct type for the declaration (hard).
- I didn't understand the syntax of the 'new' operator. Why the extra
list around the parameters?
- It looks to me that (at least, at this stage of development), that
the Sava compiler does not do any semantic analysis. This mean that
non-syntactical errors in a sava program will show up only in the
Java compilation phase and you will have to relate the Java code
with the original Sava code. I bet you will find this extremelly
annoying. At least, I do. Linj tries really hard to identify all
static semantic errors so that you never need to look at the Java
source. Obviously, when a dynamic semantic error shows up, you
might be able to understand it just by looking at the stack trace
but if you need to look at the line number, then it's the 'Java line
number', not the 'Linj line number'. This is really annoying.
- In the beginning, Linj didn't look like Common Lisp (some people
might say that it still doesn't look :-). However, at one time I
decided that, for those who want to use Linj, it is harder to learn
a new language than to learn a small number of extensions to a
language that they already know. I still think the same.
>> That's an easy task (but learning the pretty-printer is not)
>
> The pretty-printer is part of standard common-lisp. It's useful to know
> about it.
>
>> and,
>> moreover, you are talking about something that a Java code beautifier
>> can solve instantly.
>
> They are not enough open for my taste.
Life is to short for you to find (or invent) everything you need in a
form that suits your taste. Hey, I would love if my car could fly,
but it can't, so I use it that way and I'm happy.
> And pretty-printing is so useful that it's important to master it. In lisp
> of course !
I humbly confess that I programmed in Common Lisp for years without
ever using pretty-printing streams. I only learned a bit about them
when I decided to build Linj. And it is still the only place where I
use them.
>> I would like to hear your opinion regarding changing other (more
>> complex) parts of your translator such as messing with the type
>> inference process. Do you think that's something easy to do?
>
> For now, I'm not there and i've never tackle this problem. The integration
> shouldn't be over-difficult. And for the inference engine, someone more
> competent than me may do it.
You are very optimistic.
>> > All is (or should) centered on pretty-printing. Orthogonality. Or
>> > even you may use you own sava-print. modularity. Or perahps re-use
>> > (by refactoring some code) it to pretty-print 's++'. abstraction.
>>
>> Sure. Someone can change the pretty-printer. Then, you decide that
>> you want to change your AST. What happens then?
>
> AST ??
Abstract Syntax Tree. In your sava example, it's the contents of
*cu-divelog*.
> I and others are free to change it at any time. The best will hopefully stay
> alive.
>
> Backward compatibilty ? hum, not with a freeware ! The "someone" will follow
> because he agrees
> with the change or he will stay with the last version or he will begin a new
> version.
Ok. I'll drop this discussion. I guess we value different things.
>> > (what's makes me hungry is that i'm using Clisp and its
>> > pretty-printer is buggy !)
>>
>> So, according to your theory, you just have to look at the CLISP
>> source code, identify the bug and correct it. I'll wait to see how
>> long will it take you to do that.
>
> First, i'm not interested by building Lisp interpreters. clisp will stay a
> black box.
CLISP is not only an interpreter. It also includes a compiler. Given
the fact that you are developing a compiler from your Lisp-like
language Sava to Java, it's strange you don't want to take a look at
CLISP. Not even to correct its obvious bugs?
> Second , if i were, i'm not sure the Clisp code is extensible enough
> for me. it's just open-source. So it would take some times.
You put requirements in the software that you use that are really hard
to fullfil. You want free software but not just free software. It
must also be open-source but not just open-source. It must also be
extensible enough for you (and probably, not just for you). And when
do you expect this ideallistic world will happen?
>> It helps Linj a lot (it doesn't generate incorrect code) but the
>> result is ugly anyway. Of course, there are more bugs to solve so you
>> still have lots of places where you can test your theory.
>
> I tested your trick, but i have yet the bad indentation. :(
Sure. As I told you there are more bugs waiting to be solved (and,
moreover, my solution is not really a solution).
>> > Imagine you compete with your lisp and all other guys just have an
>> > assembler. Don't you think you may become rich ? Higher level makes
>> > you gain time, and when you have time you can spend it thinking
>> > about new, difficult problems to solve. And then you win $$$ ;-)
>>
>> Now I'm sure: you are joking.
>
> are you sure ? "hackers & painters" from Paul Graham enlights my point of
> vue on how to make money. you should read.
I didn't know that Paul Graham made money that way :-)
Ant�nio Leit�o.
On Sun, 26 Sep 2004 10:49:36 +0100, Antonio Menezes Leitao
<··············@evaluator.pt> wrote:
>> are you sure ? "hackers & painters" from Paul Graham enlights my point
>> of
>> vue on how to make money. you should read.
>
> I didn't know that Paul Graham made money that way :-)
>
> Ant�nio Leit�o.
Selling books is one way to make money.
Making a name for yourself, even in a niche market, should also help.
I am sure that buying his book helps him make money ;)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> >> are you sure ? "hackers & painters" from Paul Graham enlights my point
> >> of
> >> vue on how to make money. you should read.
> >
> > I didn't know that Paul Graham made money that way :-)
> >
> > Ant�nio Leit�o.
>
> Selling books is one way to make money.
> Making a name for yourself, even in a niche market, should also help.
> I am sure that buying his book helps him make money ;)
For sure, but his book is not just to make money. There's a lot of real
content in his book.
His "go upstairs" picture worth more than the money i spent to buy the book.
Christophe Turle.
> >> I'm looking forward to see an example of sava source code (including a
> >> method definition, if possible) and the result of the translation.
> >
> > ok, have a look : http://perso.wanadoo.fr/turle/lisp/sava.html
>
> I did look at it and it looks promising. But having travelled the
> same path that you are now entering I see some shortcommings that you
> might want to think about:
>
> - You are inventing a new language that looks like Java with
> parenthesis. However, it's even more verbose than Java. In
> particular, you force the programmer to explicitely mark method
> calls with the symbol 'call' (there are 23 such occurrencies in
> your example). That's unfriendly.
>
> Compare
>
> x.m1().m2() in Java
>
> (call (call x m1) m2) in Sava
>
> (m2 (m1 x)) in Linj
>
> I suggest you think about a better syntax for method calls as they
> are really frequent in Java.
This is the base syntax : the explicit s-expr. If i have decided to write in
lisp instead of Java is because i can now level up and build layers upon it.
I can define macros, but even better anybody may write their own macros on
top of it. So abstractions can now appear. And you have
the possibility of using macroexpand to see the result.
> - Your variable declarations are fully typed. However, if you look at
> them you will immediately notice a pattern:
>
> (var JMenuBar mb (new JMenuBar ()))
> (var JMenu menu (new JMenu ("File")))
> (var JMenuItem item (new JMenuItem ("Exit")))
> (var DiveLog dl (new DiveLog ()))
>
> This suggest that you can either invent a new syntax that avoids
> duplication of the type (easy)
As said above, it is possible by using well-known macros. We have the CL
extensibilty,
just using it when the need will arise.
> - I didn't understand the syntax of the 'new' operator. Why the extra
> list around the parameters?
Cause you may have a body following. "New" definition in sava.lisp :
(def-declaration new (class (args 1 listp) (statements :0-*)))
which means that a (new ...) is first composed of a class then a list
representing its arguments
and finally zero or more statements (for anonymous class).
> - It looks to me that (at least, at this stage of development), that
> the Sava compiler does not do any semantic analysis. This mean that
> non-syntactical errors in a sava program will show up only in the
> Java compilation phase and you will have to relate the Java code
> with the original Sava code. I bet you will find this extremelly
> annoying. At least, I do. Linj tries really hard to identify all
> static semantic errors so that you never need to look at the Java
> source. Obviously, when a dynamic semantic error shows up, you
> might be able to understand it just by looking at the stack trace
> but if you need to look at the line number, then it's the 'Java line
> number', not the 'Linj line number'. This is really annoying.
Yes, i agree. I will add this as need will arise.
> - In the beginning, Linj didn't look like Common Lisp (some people
> might say that it still doesn't look :-). However, at one time I
> decided that, for those who want to use Linj, it is harder to learn
> a new language than to learn a small number of extensions to a
> language that they already know. I still think the same.
I agree again. It's why my process begun with a java file (which syntax is
hopefully well known)
And i have translated it as the more natural way (for me) to an s-expr
syntax. I think Sava users
will first want to translate some java code to sava. This translation is
intended to be the easiest possible. When they will see that they can
translate any java program very easily into
sava, i bet they will use it, because they will able to build abstractions
around it.
> I humbly confess that I programmed in Common Lisp for years without
> ever using pretty-printing streams. I only learned a bit about them
> when I decided to build Linj. And it is still the only place where I
> use them.
Yes, it's because pretty printing seems not required for most projects. But
in fact, using it
,to print debug information for example, makes us gaining lots of time. The
only problem, as you
stated is that we must forced ourself to learn it the first time.
> >> > All is (or should) centered on pretty-printing. Orthogonality. Or
> >> > even you may use you own sava-print. modularity. Or perahps re-use
> >> > (by refactoring some code) it to pretty-print 's++'. abstraction.
> >>
> >> Sure. Someone can change the pretty-printer. Then, you decide that
> >> you want to change your AST. What happens then?
> >
> > AST ??
>
> Abstract Syntax Tree. In your sava example, it's the contents of
> *cu-divelog*.
yes i realized this, this morning in my bed ;-)
At the beginning, i'm sure that the AST will change often, but after a while
it will (hopefully)
converge.
> CLISP is not only an interpreter. It also includes a compiler. Given
> the fact that you are developing a compiler from your Lisp-like
> language Sava to Java, it's strange you don't want to take a look at
> CLISP.
Perhaps the compiler design aspect is not clear enough for me to understand.
I like
small examples.
> Not even to correct its obvious bugs?
no time for this nor interest.
> You put requirements in the software that you use that are really hard
> to fullfil. You want free software but not just free software. It
> must also be open-source but not just open-source. It must also be
> extensible enough for you (and probably, not just for you). And when
> do you expect this ideallistic world will happen?
When i dunno. But c.l.l./common-lisp.net are very active and contribute a
lot toward this goal.
Christophe Turle.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87sm95ezgd.fsf@evaluator.pt>
"Christophe Turle" <······@nospam.com> writes:
> This is the base syntax : the explicit s-expr. If i have decided to
> write in lisp instead of Java is because i can now level up and
> build layers upon it. I can define macros, but even better anybody
> may write their own macros on top of it. So abstractions can now
> appear. And you have the possibility of using macroexpand to see the
> result.
You are preaching at the choir. Linj has lots of stuff that is done
with macros (I even showed you one). But you will soon find out that
there are things that no plain macro can solve and that need type
inference.
>> This suggest that you can either invent a new syntax that avoids
>> duplication of the type (easy)
>
> As said above, it is possible by using well-known macros. We have the CL
> extensibilty,
> just using it when the need will arise.
It's not so simple. Even in Common Lisp, there are things that macros
can't do.
>> - I didn't understand the syntax of the 'new' operator. Why the extra
>> list around the parameters?
>
> Cause you may have a body following. "New" definition in sava.lisp :
>
> (def-declaration new (class (args 1 listp) (statements :0-*)))
>
> which means that a (new ...) is first composed of a class then a list
> representing its arguments
> and finally zero or more statements (for anonymous class).
I see. Normal users will need another macro for the much more
frequent situation where they will instantiate non-anonymous inner
classes.
>> - It looks to me that (at least, at this stage of development), that
>> the Sava compiler does not do any semantic analysis. This mean that
>> non-syntactical errors in a sava program will show up only in the
>> Java compilation phase and you will have to relate the Java code
>> with the original Sava code. I bet you will find this extremelly
>> annoying. At least, I do. Linj tries really hard to identify all
>> static semantic errors so that you never need to look at the Java
>> source. Obviously, when a dynamic semantic error shows up, you
>> might be able to understand it just by looking at the stack trace
>> but if you need to look at the line number, then it's the 'Java line
>> number', not the 'Linj line number'. This is really annoying.
>
> Yes, i agree. I will add this as need will arise.
Maybe I'm just a lousy programmer but it looks to me that you are
being overly optimistic about software (re)engineering. You keep
saying that you'll add this and that as if you were just playing with
Lego.
>> - In the beginning, Linj didn't look like Common Lisp (some people
>> might say that it still doesn't look :-). However, at one time I
>> decided that, for those who want to use Linj, it is harder to learn
>> a new language than to learn a small number of extensions to a
>> language that they already know. I still think the same.
>
> I agree again. It's why my process begun with a java file (which
> syntax is hopefully well known) And i have translated it as the more
> natural way (for me) to an s-expr syntax. I think Sava users will
> first want to translate some java code to sava. This translation is
> intended to be the easiest possible. When they will see that they
> can translate any java program very easily into sava, i bet they
> will use it, because they will able to build abstractions around it.
Ok. That's a plan.
> At the beginning, i'm sure that the AST will change often, but after
> a while it will (hopefully) converge.
Meanwhile, all the pretty-printing stuff the some Sava user developed
might not work anymore because you felt that you could change it at
any time you wanted. Your users will not be happy, believe me.
Ant�nio Leit�o.
> Maybe I'm just a lousy programmer but it looks to me that you are
> being overly optimistic about software (re)engineering. You keep
> saying that you'll add this and that as if you were just playing with
> Lego.
Yes that's the point. When i program, my goal is to build legos. The hard
part
for me is generally the start. I tend to write slowly to discover the good
abstractions.
During that time, others may have write lots of functionnalities :( .
The good thing comes after a while, others program begin to crumble on
themselves since they are too huge to maintain. Mines are curiously more and
more clean. I have less and less bugs and the development time becomes
shorter due to best design.
I have not a wonderful method. I believe it's just a mix of known issue :
DSL, meta-programming, declarativity, re-factoring and test-driven
development.
But, all is not shiny, i'm really too slow. I'm actually trying to write
programs more quickly. Thinking less, and refactoring more using
pre-versions.
really just my subjective self-opinion.
Christophe Turle.
Antonio Menezes Leitao <··············@evaluator.pt> wrote in message news:<··············@evaluator.pt>...
[...]
> I'm not sure I understand you but if you are talking about translation
> between Lisp names and Java names then you don't need to worry. Linj
> obeys your names. Here are one example (from the manual) that shows
> several alternatives:
>
> (defun ···@^ (!! a-normal-name reallyFunny)
> (declare (type int !! a-normal-name reallyFunny))
> (let ((BIGNAME 1)
> (ok? t))
> (if (< !! +the-biggest+)
> BIGNAME
> (···@^ (1- !!) 0 (+ a-normal-name reallyFunny)))))
>
> The translation shows that the names that follow Lisp conventions are
> translated into Java conventions and names that follow Java
> conventions are translated verbatim:
>
> public static int percent$SharpAtUp(int bangBang, int aNormalName, int reallyFunny) {
> int BIGNAME = 1;
> boolean okP = true;
> if (bangBang < THE_BIGGEST) {
> return BIGNAME;
> } else {
> return percent$SharpAtUp(bangBang - 1, 0, aNormalName + reallyFunny);
> }
> }
>
> Note, in particular, the translation of the names reallyFunny and
> BIGNAME. They follow Java conventions and are not subject to further
> translation.
And what happens when i have a variable named BangBang? If you have a
solution, i don't see how it can be elegant. Why don't you simply
actually do some escaping?
Paul Khuong
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87d60clkb3.fsf@evaluator.pt>
··········@pvk.ca (pkhuong) writes:
> Antonio Menezes Leitao <··············@evaluator.pt> wrote in message news:<··············@evaluator.pt>...
> [...]
>> I'm not sure I understand you but if you are talking about translation
>> between Lisp names and Java names then you don't need to worry. Linj
>> obeys your names. Here are one example (from the manual) that shows
>> several alternatives:
>>
>> (defun ···@^ (!! a-normal-name reallyFunny)
>> (declare (type int !! a-normal-name reallyFunny))
>> (let ((BIGNAME 1)
>> (ok? t))
>> (if (< !! +the-biggest+)
>> BIGNAME
>> (···@^ (1- !!) 0 (+ a-normal-name reallyFunny)))))
>>
>> The translation shows that the names that follow Lisp conventions are
>> translated into Java conventions and names that follow Java
>> conventions are translated verbatim:
>>
>> public static int percent$SharpAtUp(int bangBang, int aNormalName, int reallyFunny) {
>> int BIGNAME = 1;
>> boolean okP = true;
>> if (bangBang < THE_BIGGEST) {
>> return BIGNAME;
>> } else {
>> return percent$SharpAtUp(bangBang - 1, 0, aNormalName + reallyFunny);
>> }
>> }
>>
>> Note, in particular, the translation of the names reallyFunny and
>> BIGNAME. They follow Java conventions and are not subject to further
>> translation.
> And what happens when i have a variable named BangBang? If you have a
> solution, i don't see how it can be elegant. Why don't you simply
> actually do some escaping?
If you want to know what happens, why don't you try it?
Here is one funny example:
(let ((!! 1) (bang-bang 2))
(print (+ !! bang-bang)))
Note that both !! and bang-bang will be translated into bangBang. The
good news is that if you try to compile that you will get:
Error in function linj::build-java-symbol:
Same java symbol bangBang designating different linj names !! and bang-bang
That's the most 'elegant' solution I could think at the time. Maybe
there are more elegant solutions.
However, you question is pertinent as there are other situations where
I don't detect the error. For example, on the slightly different
example, Linj will accept the code (and produce incorrect Java code):
(let ((!! 1) (bangBang 2))
(print (+ !! bangBang)))
Why? Because I decided to accept that both bang-bang (Lisp notation)
and bangBang (Java notation) represent the same Java symbol (namely,
bangBang). The idea is that when you use Java notation you are
telling the Linj compiler that you know what you are doing and you
don't want to do any error checking on possible conflicts. I could
change that but I must confess that I like it this way.
Anyway, if you follow Common Lisp code conventions then you will not
use symbols in Java notation. In this case, no problem occurs.
Thanks for your comments,
Ant�nio Leit�o.
"Christophe Turle" <······@nospam.fr> wrote in message
·················@amma.irisa.fr...
> Matthieu Villeneuve wrote:
> > "Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
> > ···················@modesty.klingenberg.no...
> >
> >>William Bland <·······@abstractnonsense.com> writes:
> >>
> >>
> >>>I am getting interested in writing applications for mobile phones, and
> >>>would of course prefer to use some kind of Lisp language. The standard
> >>>for many modern phones is J2ME, which is a cut-down Java Virtual
Machine
> >>>(e.g. it has no support for floating-point arithmetic). I'd be very
> >>>interested to hear if anyone knows of any Lisp-like languages that
> >
> > target
> >
> >>>such a platform.
> >>
> >>Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
> >>managed to get a rudimentary application to run on a mobile phone
> >>simulator, but IIRC it seems current J2ME relies on magic comments for
> >>some things, and they weren't easy to create in linj. I don't know if
> >>he pursued the issue further.
> >
> >
> > Hmmm... J2ME is just regular Java, with a few limitations (e.g. no
floats)
> > and using the MIDP API, but the syntax is Java's, and I have never seen
> > any kind of "magic comments" there. As far as I can tell, any system
> > generating Java bytecode could be used for writing J2ME applications, as
> > long as it is able to use the MIDP classes instead of the regular J2SE
> > ones (I don't know if Linj does that).
> >
>
> Linj is not the tool you need.
>
> Why ? Linj translates lisp code into java code. But J2ME code is not
> exactly java code. J2ME code requires optimization and so you need to be
> able to control the output java code. You need to write java in lisp and
> not java from lisp.
I really don't see why J2ME is "not exactly" Java code, other than because
of the restrictions (such as no floats) and the standard API. J2ME code
doesn't *require* special optimization in order to run on the device.
Could you please expand a little on this?
Thanks,
--
Matthieu Villeneuve
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <cj0nmt$li$1@amma.irisa.fr>
Matthieu Villeneuve wrote:
> "Christophe Turle" <······@nospam.fr> wrote in message
> ·················@amma.irisa.fr...
>
>>Matthieu Villeneuve wrote:
>>
>>>"Peder O. Klingenberg" <·····@news.klingenberg.no> wrote in message
>>>···················@modesty.klingenberg.no...
>>>
>>>
>>>>William Bland <·······@abstractnonsense.com> writes:
>>>>
>>>>
>>>>
>>>>>I am getting interested in writing applications for mobile phones, and
>>>>>would of course prefer to use some kind of Lisp language. The standard
>>>>>for many modern phones is J2ME, which is a cut-down Java Virtual
>
> Machine
>
>>>>>(e.g. it has no support for floating-point arithmetic). I'd be very
>>>>>interested to hear if anyone knows of any Lisp-like languages that
>>>
>>>target
>>>
>>>
>>>>>such a platform.
>>>>
>>>>Linj (http://www.evaluator.pt/linj.html) may be close. A collegue
>>>>managed to get a rudimentary application to run on a mobile phone
>>>>simulator, but IIRC it seems current J2ME relies on magic comments for
>>>>some things, and they weren't easy to create in linj. I don't know if
>>>>he pursued the issue further.
>>>
>>>
>>>Hmmm... J2ME is just regular Java, with a few limitations (e.g. no
>
> floats)
>
>>>and using the MIDP API, but the syntax is Java's, and I have never seen
>>>any kind of "magic comments" there. As far as I can tell, any system
>>>generating Java bytecode could be used for writing J2ME applications, as
>>>long as it is able to use the MIDP classes instead of the regular J2SE
>>>ones (I don't know if Linj does that).
>>>
>>
>>Linj is not the tool you need.
>>
>>Why ? Linj translates lisp code into java code. But J2ME code is not
>>exactly java code. J2ME code requires optimization and so you need to be
>>able to control the output java code. You need to write java in lisp and
>>not java from lisp.
>
>
> I really don't see why J2ME is "not exactly" Java code, other than because
> of the restrictions (such as no floats) and the standard API. J2ME code
> doesn't *require* special optimization in order to run on the device.
J2ME is for embedded device. If you program in J2ME as in J2SE you will have some troubles.(newline ;-))
It's not a syntaxic issue. It's more the way you have to code.
For example, use a limited number of class or pre-allocate your ressource before using them.
Instead of relying on the GC. It's why mobile company tend to have preferences for C background guys instead
of pure Java ones.
Christophe Turle.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87brfw9fxp.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Matthieu Villeneuve wrote:
>> I really don't see why J2ME is "not exactly" Java code, other than
>> because
>> of the restrictions (such as no floats) and the standard API. J2ME code
>> doesn't *require* special optimization in order to run on the device.
>
> J2ME is for embedded device. If you program in J2ME as in J2SE you
> will have some troubles.(newline ;-))
I see...you are joking.
> It's not a syntaxic issue. It's more the way you have to code.
That's a vague statement...
> For example, use a limited number of class or pre-allocate your
> ressource before using them. Instead of relying on the GC.
And in what way is that difficult to do in 'normal' Java (or in Linj)?
> It's why mobile company tend to have preferences for C background
> guys instead of pure Java ones.
I would say that "Lisp background guys" would know better how to deal
with GC problems.
Ant�nio Leit�o.
From: Christophe Turle
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <cj11r1$3mc$1@amma.irisa.fr>
Antonio Menezes Leitao wrote:
> Christophe Turle <······@nospam.fr> writes:
>
>
>>Matthieu Villeneuve wrote:
>
>
>>>I really don't see why J2ME is "not exactly" Java code, other than
>>>because
>>>of the restrictions (such as no floats) and the standard API. J2ME code
>>>doesn't *require* special optimization in order to run on the device.
>>
>>J2ME is for embedded device. If you program in J2ME as in J2SE you
>>will have some troubles.(newline ;-))
>
>
> I see...you are joking.
The "(newline ;-))" was for someone who ask me not too write long line, since he doesn't have
a line wrapper. Else i was not really joking.
>
>
>>It's not a syntaxic issue. It's more the way you have to code.
>
>
> That's a vague statement...
it's why i gave an example below ;)
>
>>For example, use a limited number of class or pre-allocate your
>>ressource before using them. Instead of relying on the GC.
>
>
> And in what way is that difficult to do in 'normal' Java (or in Linj)?
It's just that J2SE and J2ME idioms are not all the same. Of course, you can do
it in 'normal' JAVA, it's the way you use it which differs. Perhaps you will never
write a statement like this :
"System.out.println( "Title" ) ;"
but instead :
"
private static String Title = "Title" ;
...
System.out.println( Title ) ;"
This way GC is not used.
so the translation of "(print "Title")" from lisp->java might differ under J2SE or J2ME.
>>It's why mobile company tend to have preferences for C background
>>guys instead of pure Java ones.
>
>
> I would say that "Lisp background guys" would know better how to deal
> with GC problems.
C guys know how to manage memory since they must do it. GC users (lisp users included) don't have to worry about it.
So how do you want them to handle memory management better than C guys ? in general of course.
Christophe Turle.
Christophe Turle <······@nospam.fr> wrote in message news:<············@amma.irisa.fr>...
> [snip] Perhaps you will never
> write a statement like this :
>
> "System.out.println( "Title" ) ;"
>
> but instead :
>
> "
> private static String Title = "Title" ;
> ...
> System.out.println( Title ) ;"
>
> This way GC is not used.
>
> so the translation of "(print "Title")" from lisp->java might differ under J2SE or J2ME.
I am starting to see your point. You might write Java code one way in
J2SE for readability, and another way in J2ME to be super careful to
avoid GC.
In J2SE, Strings that are known constants at compile time are
interned. So your two Java examples are equivalent, I think. Does
anyone know if the same is true for J2ME?
"Mark McConnell" <···············@yahoo.com> a �crit dans le message de
·································@posting.google.com...
> Christophe Turle <······@nospam.fr> wrote in message
news:<············@amma.irisa.fr>...
> > [snip] Perhaps you will never
> > write a statement like this :
> >
> > "System.out.println( "Title" ) ;"
> >
> > but instead :
> >
> > "
> > private static String Title = "Title" ;
> > ...
> > System.out.println( Title ) ;"
> >
> > This way GC is not used.
> >
> > so the translation of "(print "Title")" from lisp->java might differ
under J2SE or J2ME.
>
> I am starting to see your point. You might write Java code one way in
> J2SE for readability,
yes. What's is important is that it works. You know that Linj will do the
job for you,
so at last you may forget that the target language is Java.
The goal here is to have an application.
> and another way in J2ME to be super careful to
> avoid GC.
yes, for example. The goal is to have a java program. But Antonio showed me
that Linj can generate
every java program possible. So It may be used for J2ME devt.
The open layers are the only things Linj should still need imho.
Christophe Turle.
From: Antonio Menezes Leitao
Subject: Re: Some kind of Lisp targeting J2ME?
Date:
Message-ID: <87fz57pumb.fsf@evaluator.pt>
Christophe Turle <······@nospam.fr> writes:
> Antonio Menezes Leitao wrote:
>> Christophe Turle <······@nospam.fr> writes:
>>
>>>Matthieu Villeneuve wrote:
>>
>>>>I really don't see why J2ME is "not exactly" Java code, other than
>>>>because
>>>>of the restrictions (such as no floats) and the standard API. J2ME code
>>>>doesn't *require* special optimization in order to run on the device.
>>>
>>>J2ME is for embedded device. If you program in J2ME as in J2SE you
>>>will have some troubles.(newline ;-))
>> I see...you are joking.
>
> The "(newline ;-))" was for someone who ask me not too write long
> line, since he doesn't have a line wrapper. Else i was not really
> joking.
I see. Sorry for the confusion.
>
>>
>>>It's not a syntaxic issue. It's more the way you have to code.
>> That's a vague statement...
>
> it's why i gave an example below ;)
>
>>
>>>For example, use a limited number of class or pre-allocate your
>>>ressource before using them. Instead of relying on the GC.
>> And in what way is that difficult to do in 'normal' Java (or in
>> Linj)?
>
> It's just that J2SE and J2ME idioms are not all the same. Of course,
> you can do it in 'normal' JAVA, it's the way you use it which
> differs. Perhaps you will never write a statement like this :
>
> "System.out.println( "Title" ) ;"
>
> but instead :
>
> "
> private static String Title = "Title" ;
> ...
> System.out.println( Title ) ;"
>
> This way GC is not used.
>
> so the translation of "(print "Title")" from lisp->java might differ
> under J2SE or J2ME.
I must confess that I don't know enough J2ME but it looks to me that
there are lots of techniques to reduce memory demands that make sense
on J2ME but not on J2SE. Building a translator that generates Java
code (from just one Lisp source) with radically different memory
management strategies (such as relying on GC or using object pooling)
is a _huge_ task. It's not just a local difference in the generated
code: it might need to generate a completely different application.
This means that (at least, in 2004) you should think about the target
of your program. If it's J2ME, then use whatever techniques you want
but Linj will still be able to help you and free you from writing a
single line of Java. Using your example, you just have to write
;;;;;;;;;;;;;;;
(defconstant title "Title")
(print title)
;;;;;;;;;;;;;;;
instead of
;;;;;;;;;;;;;;;
(print "Title").
;;;;;;;;;;;;;;;
Anyway, I'm becoming a bit puzzled with your initial criticism that
"You need to write java in lisp and not java from lisp." Seems to me
that this statement is in contradiction with the requirement that the
translation of "(print "Title")" from lisp->java should depend on the
target environment. Maybe I didn't understant your initial criticism.
>>>It's why mobile company tend to have preferences for C background
>>>guys instead of pure Java ones.
>> I would say that "Lisp background guys" would know better how to deal
>> with GC problems.
>
> C guys know how to manage memory since they must do it.
I agree. But usually they don't now how to fine-tune a GC.
> GC users (lisp users included) don't have to worry about it. So how
> do you want them to handle memory management better than C guys ? in
> general of course.
"C guys" usually know nothing about copying collectors, mark and sweep
collectors, incremental collectors and generational collectors. "Lisp
guys" should know a little bit. This knowledge might be needed when
we need to optimize an application. Moreover, when you move to a
different JVM implementation, you might get a different collector with
different characteristics. I would prefer to have someone that knows
how to tune different GC algoritms than someone that only knows how to
live _without_ GC algoritms.
Ant�nio Leit�o.