From: ········@yahoo.es
Subject: Needs Lisp a front-end?
Date: 
Message-ID: <1190476492.564446.174880@57g2000hsv.googlegroups.com>
Mathematica language has FullForm for lisp like s-expression and
InputForm for easy to
read expressions.

  Maxima has a particular language builts on Lisp.

 I think Lisp needs a front-end, but on the other hand, is almost
imposible to
agree on a new language.

  That is I think that python, ruby, maxima-language, ... should be
very a good
front-end for Common Lisp.

 But you need to construct that in Lisp and make it powerful enough to
traslate quickly
from InputForm (maxima like) to FullForm (Lisp Like).

  Maxima scope is not lexical, and there are other problems with
strings and vector, but
maxima community is working on the mathematical level most of the
time.

Perhap some lisp hacker should try to make a good front-end.

 That is a killer application: The power of Lisp with the easy reading
of Python or Ruby.

 Maxima is half way.  (For example they can translate fortran code,
multiplatform,
waiting for SBCL on windows to use CFFI, etc).

 Do you think that Lisp needs a Front-End?

From: Robert Dodier
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190484375.260127.251350@y42g2000hsy.googlegroups.com>
········@yahoo.es wrote:

>  Do you think that Lisp needs a Front-End?

I don't think Lisp in general needs a front end, but if you
find that some nonparenthetical language is more useful,
then more power to you.

You may be interested in CL-Python which is an implementation
of Python in Lisp. I was able to build it and it seems to work OK
(although I didn't test it very carefully). My interest here is that
CL-Python could be a user language for Maxima. I seem to have
let that slide; guess it's time to look at that again.

FWIW

Robert Dodier
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190489893.736037.89000@22g2000hsm.googlegroups.com>
On 22 sep, 20:06, Robert Dodier <·············@gmail.com> wrote:
> ········@yahoo.es wrote:
> >  Do you think that Lisp needs a Front-End?
>
> I don't think Lisp in general needs a front end, but if you
> find that some nonparenthetical language is more useful,
> then more power to you.
>
> You may be interested in CL-Python which is an implementation
> of Python in Lisp. I was able to build it and it seems to work OK
> (although I didn't test it very carefully). My interest here is that
> CL-Python could be a user language for Maxima. I seem to have
> let that slide; guess it's time to look at that again.
>
> FWIW
>

> Robert Dodier

 You are trying to write maxima in maxima language and not in Lisp,
also i saw some post
about Lisp not a good language for maxima, ...

 Now you say there is no need of a front-end, but you know clearly
that new people don't like lisp syntax.
So i don't see clearly a relation between what you say here and what
you do in maxima.

Also see the real value that add wxmaxima as a front-end to maxima.
From: Jason Nielsen
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <Pine.LNX.4.64.0709221442130.7486@octopus>
On Sat, 22 Sep 2007, Robert Dodier wrote:

> You may be interested in CL-Python which is an implementation
> of Python in Lisp. I was able to build it and it seems to work OK
> (although I didn't test it very carefully). My interest here is that
> CL-Python could be a user language for Maxima. I seem to have
> let that slide; guess it's time to look at that again.
>

I think that switching maxima over to use CL-Python as a front end would 
be superb!  Unfortunately CL-Python is dependent on Allegro, in particular 
its yacc implementation.  I looked into trying to port Allegro yacc to 
cl-yacc as a first step in the making CL-Python more portable but there is 
no documentation available for Allegro yacc making such a task difficult.

Jason
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190491909.616842.108220@n39g2000hsh.googlegroups.com>
On 22 sep, 20:46, Jason Nielsen <····@math.carleton.ca> wrote:
> On Sat, 22 Sep 2007, Robert Dodier wrote:
> > You may be interested in CL-Python which is an implementation
> > of Python in Lisp. I was able to build it and it seems to work OK
> > (although I didn't test it very carefully). My interest here is that
> > CL-Python could be a user language for Maxima. I seem to have
> > let that slide; guess it's time to look at that again.
>
> I think that switching maxima over to use CL-Python as a front end would
> be superb!  Unfortunately CL-Python is dependent on Allegro, in particular
> its yacc implementation.  I looked into trying to port Allegro yacc to
> cl-yacc as a first step in the making CL-Python more portable but there is
> no documentation available for Allegro yacc making such a task difficult.
>
> Jason

 I think CL-Python as a front end for maxima would be a superb
option.
 Rush to do it!

 Do CL-Python have access to the libraries written in python?
 Does it implements all the builting and modules of python?
From: Willem Broekema
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190496964.594238.278620@w3g2000hsg.googlegroups.com>
On Sep 22, 10:11 pm, ········@yahoo.es wrote:
> I think CL-Python as a front end for maxima would be a superb
> option.
> Rush to do it!

Python is a syntactically clean language, and semantically mostly too.
I think it can be a powerful yet quickly learnable extension language
for systems in general. But I'm wondering what the role of Python
could be in Maxima, or more specific in what way it would be a
significant improvement on what is already there.

>From a brief look at Maxima it seems expressions generally take a form
like:

 diff (4*f(x, y)^2 - u(x, y)^2, x);

This closely resembles Python syntax already:

 diff(4*f(x, y)**2 - u(x, y)**2, x)

Using Python syntax for input of commands in Maxima could result in a
slightly cleaner language. But is that such an improvement over the
current situation?

Using Python for its language semantics seems out of the question, as
that would require all symbols to be defined before use, and lacking
symbols as first-class data type it would lead to painful statements
like "x = Symbol('x')". That is a big step backwards.

A possible benefit of supporting Python input in Maxima, is that it
could allow easier generation of Maxima programs out of Lisp code. The
road from Lisp expressions to Python code might be easier than going
from Lisp to the current Maxima syntax, because the Python source code
can be generated from s-expressions using the CLPython pretty printer,
and there might be other handy tools working on Python source code.
But on the other hand, given that Maxima exists already for a long
time, I would be surprised if there is not some package for creating
Maxima code from Lisp expressions nowadays already. And if there is
not, does that not indicate that there is no demand for it?

> Do CL-Python have access to the libraries written in python?
> Does it implements all the builting and modules of python?

Most built-in functions and data types are currently implemented; the
modules of the standard library are not.

- Willem
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190501465.588471.222100@k79g2000hse.googlegroups.com>
On 22 sep, 23:36, Willem Broekema <········@gmail.com> wrote:
> On Sep 22, 10:11 pm, ········@yahoo.es wrote:
>
> > I think CL-Python as a front end for maxima would be a superb
> > option.
> > Rush to do it!
>
> Python is a syntactically clean language, and semantically mostly too.
> I think it can be a powerful yet quickly learnable extension language
> for systems in general. But I'm wondering what the role of Python
> could be in Maxima, or more specific in what way it would be a
> significant improvement on what is already there.
>
> >From a brief look at Maxima it seems expressions generally take a form
>
> like:
>
>  diff (4*f(x, y)^2 - u(x, y)^2, x);
>
> This closely resembles Python syntax already:
>
>  diff(4*f(x, y)**2 - u(x, y)**2, x)
>
> Using Python syntax for input of commands in Maxima could result in a
> slightly cleaner language. But is that such an improvement over the
> current situation?
>
> Using Python for its language semantics seems out of the question, as
> that would require all symbols to be defined before use, and lacking
> symbols as first-class data type it would lead to painful statements
> like "x = Symbol('x')". That is a big step backwards.
>
> A possible benefit of supporting Python input in Maxima, is that it
> could allow easier generation of Maxima programs out of Lisp code. The
> road from Lisp expressions to Python code might be easier than going
> from Lisp to the current Maxima syntax, because the Python source code
> can be generated from s-expressions using the CLPython pretty printer,
> and there might be other handy tools working on Python source code.
> But on the other hand, given that Maxima exists already for a long
> time, I would be surprised if there is not some package for creating
> Maxima code from Lisp expressions nowadays already. And if there is
> not, does that not indicate that there is no demand for it?
>
> > Do CL-Python have access to the libraries written in python?
> > Does it implements all the builting and modules of python?
>
> Most built-in functions and data types are currently implemented; the
> modules of the standard library are not.
>
> - Willem

 In order to understand the problem with maxima language you can look
to Michel Van den Bergh (sanitize topic)
in maxima pipermail, problem about scope, ... that make maxima
language dangerous to use:
evaluation ocurr depending of a dynamic call.

 That's why python sintax an evaluation rules would be very
appreciated.
From: Matthias Buelow
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5llklhF8ru8vU1@mid.dfncis.de>
Willem Broekema wrote:

> Python is a syntactically clean language, 

It doesn't even attempt to have a context-free grammar, I certainly
wouldn't call it "syntactically clean" with that grouping-by-indentation
nonsense.

Anyway. I thought about this some time ago and came to the conclusion
that a relatively compact and clean (under more than one criterion)
language like Modula (or something similar) would be a good _addition_
to sit on top of a Lisp system, especially when Lisp has taken over the
world. While not quite as powerful as the underlying Lisp in
expressiveness, it would be a refreshing break and give those that
prefer an Algol-style syntax a good interface to programming. Note that
this isn't about replacing Lisp but supplementing it and perhaps could
even be mixed with s-expressions (perhaps something like a
loop-for-sane-people, although my verdict is open on such an approach).
Purely hypothetical brainstorming, of course.
From: Robert Dodier
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190509261.376982.214890@g4g2000hsf.googlegroups.com>
Willem Broekema wrote:

> Using Python syntax for input of commands in Maxima could result in a
> slightly cleaner language. But is that such an improvement over the
> current situation?

Two things that I'd really like to see in the user language are
lexical scope, and a package system. I suppose those could be
bolted onto the existing language, and the result would be somewhat
more usable but still idiosyncratic. Python is altogether better
thought
out than the Maixma language (dare I say it), so why invent a peculiar
language instead of making use of an existing nice language.

> Using Python for its language semantics seems out of the question, as
> that would require all symbols to be defined before use, and lacking
> symbols as first-class data type it would lead to painful statements
> like "x = Symbol('x')". That is a big step backwards.

Yeah. I wonder how hard it would be to extend Python's evaluation
policy (in CL-Python) to allow unevaluated symbols and function
calls. The result would not be a standard Python but that doesn't
bother me too much.

I'm not really sure that CL-Python would really catch on as a
Maxima user language, but I think it is an interesting idea, and
it would be useful to have it in the portfolio of interesting things
people have tried to do with Maxima.

By the way, Willem, thanks a lot for your work on CL-Python.

FWIW

Robert Dodier
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190539340.391345.22660@k79g2000hse.googlegroups.com>
On 23 sep, 03:01, Robert Dodier <·············@gmail.com> wrote:
> Willem Broekema wrote:
> > Using Python syntax for input of commands in Maxima could result in a
> > slightly cleaner language. But is that such an improvement over the
> > current situation?
>
> Two things that I'd really like to see in the user language are
> lexical scope, and a package system. I suppose those could be
> bolted onto the existing language, and the result would be somewhat
> more usable but still idiosyncratic. Python is altogether better
> thought
> out than the Maixma language (dare I say it), so why invent a peculiar
> language instead of making use of an existing nice language.
>
> > Using Python for its language semantics seems out of the question, as
> > that would require all symbols to be defined before use, and lacking
> > symbols as first-class data type it would lead to painful statements
> > like "x = Symbol('x')". That is a big step backwards.
>
> Yeah. I wonder how hard it would be to extend Python's evaluation
> policy (in CL-Python) to allow unevaluated symbols and function
> calls. The result would not be a standard Python but that doesn't
> bother me too much.
>
> I'm not really sure that CL-Python would really catch on as a
> Maxima user language, but I think it is an interesting idea, and
> it would be useful to have it in the portfolio of interesting things
> people have tried to do with Maxima.
>
> By the way, Willem, thanks a lot for your work on CL-Python.
>
> FWIW
>
> Robert Dodier

Thanks a lot to Willem and Robert Dodier for their work on CL-Python
and Maxima.
From: Jason Nielsen
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <Pine.LNX.4.64.0709231518060.10022@octopus>
On Sun, 23 Sep 2007, Robert Dodier wrote:
>
> By the way, Willem, thanks a lot for your work on CL-Python.
>

I'll certainly second this one.  It is pretty impressive that you have 
been able to pretty much get a full Python going in such a short period of 
time!  Testament to the power of common lisp, and of course to your skill.

Thanks again,
Jason
From: Willem Broekema
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190492074.714064.183350@g4g2000hsf.googlegroups.com>
On Sep 22, 8:46 pm, Jason Nielsen <····@math.carleton.ca> wrote:
> I think that switching maxima over to use CL-Python as a front end
> would be superb!  Unfortunately CL-Python is dependent on Allegro, in
> particular its yacc implementation. I looked into trying to port
> Allegro yacc to cl-yacc as a first step in the making CL-Python more
> portable but there is no documentation available for Allegro yacc
> making such a task difficult.

To have cl-yacc as parser behind CLPython, it seems much easier to
translate the grammar rules of the Python language than to re-
implement Allegro's yacc. After all, the grammar rules are s-
expressions in a regular form so a lot of the restructuring can be
automated, and there does not seem to be anything in the grammar that
is not supported by cl-yacc.

In fact, some time ago I already tried to use cl-yacc within CLPython.
For some reason the result was not correct in that the parsing of
valid strings failed. If anyone feels like helping tackling this,
let's discuss it on the CLPython mailing list: http://common-lisp.net/pipermail/clpython-devel/

- Willem
From: Frank Buss
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <gpbxhl18vjxa.3jhjh68e10qe.dlg@40tude.net>
········@yahoo.es wrote:

>  That is a killer application: The power of Lisp with the easy reading
> of Python or Ruby.

This is really a groundbreaking idea, which was never discussed before in
this newsgroup. Do you have some experience in Lisp programming to justify
your idea that it is easier to read and write Python than Lisp?

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190491063.997540.305720@y42g2000hsy.googlegroups.com>
On 22 sep, 18:39, Frank Buss <····@frank-buss.de> wrote:
> ········@yahoo.es wrote:
> >  That is a killer application: The power of Lisp with the easy reading
> > of Python or Ruby.
>
> This is really a groundbreaking idea, which was never discussed before in
> this newsgroup. Do you have some experience in Lisp programming to justify
> your idea that it is easier to read and write Python than Lisp?
>
> --
> Frank Buss, ····@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

To non believer:  Compare these:

In[1]:= (2 x^2 + 3 x y + 6 y x z^2 - 7 x y) / (x + 3 y^2) ^2  /. {x ->
1, y -> 2, z -> 3}



Out[1]= 102/169

FullForm of In[1] is:


ReplaceAll[Times[Plus[Times[2,Power[x,
2]],Times[3,x,y],Times[6,y,x,Power[z,2]],Times[-1,Times[7,x,y]]],
	Power[Power[Plus[x,Times[3,Power[y,2]]],2],-1]],List[Rule[x,1],Rule[y,
2],Rule[z,3]]]]

 Which one is easier to read?
From: Frank Buss
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <58n79stohmt3$.lkz8oe2j9oa1$.dlg@40tude.net>
········@yahoo.es wrote:

> To non believer:  Compare these:
> 
> In[1]:= (2 x^2 + 3 x y + 6 y x z^2 - 7 x y) / (x + 3 y^2) ^2  /. {x ->
> 1, y -> 2, z -> 3}

This looks already unreadable.

> FullForm of In[1] is:
> 
> 
> ReplaceAll[Times[Plus[Times[2,Power[x,
> 2]],Times[3,x,y],Times[6,y,x,Power[z,2]],Times[-1,Times[7,x,y]]],
> 	Power[Power[Plus[x,Times[3,Power[y,2]]],2],-1]],List[Rule[x,1],Rule[y,
> 2],Rule[z,3]]]]
>
>  Which one is easier to read?

You are right, this is even more unreadable, so maybe it is a good idea to
enhance Maxima to write it like you can do it in Lisp:

(let ((x 1)
      (y 2)
      (z 3))
  (/ (+ (* 2 x x)
        (* 3 x y)
        (* 6 y x z z)
        (- (* 7 x y)))
     (expt (+ x (* 3 y y)) 2)))

But for complex formulas sometimes it is easier to write it in the usual
infix notation. There is a package available for Lisp which allows it, and
a short hack written by me:

http://groups.google.de/group/comp.lang.lisp/msg/09563f6e0f0e604e

Most of the time I don't need it, because if the formula is too complex to
read it, it is a good sign to refactor it with smaller functions, like with
Lisp code, too.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <87sl552je2.fsf@web.de>
········@yahoo.es writes:

> On 22 sep, 18:39, Frank Buss <····@frank-buss.de> wrote:
>> ········@yahoo.es wrote:
>> >  That is a killer application: The power of Lisp with the easy reading
>> > of Python or Ruby.
>>
>> This is really a groundbreaking idea,

no, it's a bad idea, as Lisp is  many hundreds of times easier to read
due to its regular prefic syntax than any of those irregular-scribble
idioms that veil the parse tree.
>
> To non believer:  Compare these:
>
> In[1]:= (2 x^2 + 3 x y + 6 y x z^2 - 7 x y) / (x + 3 y^2) ^2  /. {x ->
> 1, y -> 2, z -> 3}
>
>
>
> Out[1]= 102/169
>
> FullForm of In[1] is:
>
>
> ReplaceAll[Times[Plus[Times[2,Power[x,
> 2]],Times[3,x,y],Times[6,y,x,Power[z,2]],Times[-1,Times[7,x,y]]],
> 	Power[Power[Plus[x,Times[3,Power[y,2]]],2],-1]],List[Rule[x,1],Rule[y,
> 2],Rule[z,3]]]]
>
>  Which one is easier to read?

the prefix version.


Klaus Schilling
From: John Thingstad
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <op.ty2e8xe7pqzri1@pandora.upc.no>
P� Sat, 22 Sep 2007 17:54:52 +0200, skrev <········@yahoo.es>:

>
> Perhap some lisp hacker should try to make a good front-end.
>
>  That is a killer application: The power of Lisp with the easy reading
> of Python or Ruby.
>
>  Maxima is half way.  (For example they can translate fortran code,
> multiplatform,
> waiting for SBCL on windows to use CFFI, etc).
>
>  Do you think that Lisp needs a Front-End?
>

No, I don't. I might add that, say, GNU C/C++ translates to a Lisp like  
syntax tree before doing further manipulations. What is wrong with the way  
Lisp is today? I wouldn't have it any other way.. I might add that Dylan  
tred to add infix syntax to Lisp. Yet Lisp survived while Dylan has  
declined. One of the reasons is the abillity to manipulate the syntax tree  
directly. Particularly though macroes.
From: Steven M. Haflich
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <46F6E190.4030309@alum.mit.edu>
········@yahoo.es wrote:
> Mathematica language has FullForm for lisp like s-expression and
> InputForm for easy to
> read expressions.
> 
>   Maxima has a particular language builts on Lisp.
> 
>  I think Lisp needs a front-end, but on the other hand, is almost
> imposible to
> agree on a new language.

I've also followed the slower (but more polite) discussion of your 
proposal on the Maxima list.

As others have sarcastically replied, this issue of syntax has arisen 
from time to time over the last 48 years.   It is true that for Lisp 
beginners who have learned only C or Java, S-expr notation is a hurdle. 
  But there is a good reason it survives, and that has to do with one of 
the 5 language characteristics that give Lisp its power.  Macros that 
operate on first-class program structure (compared to string 
manipulation in C, and a more-or-less prohibition on macros in Java).

Such a large part of Lisp's coding efficiency and expressivity derives 
from the ability to define macros that operate on the same data 
structure as the run-time language.  But macros can be complex and 
steepen learning curve for beginners.  (High plateaus have taller 
learning curves.)  The only thing that keeps macros manageable in CL is 
the fact that the textual representation of the language is isomorphic 
(in the syntax of S-exprs) to the data structure representation of the 
language (as a tree of conses).  Add another level of translation 
between C-style notation and S-expr notation (which are essentially 
equivalent, but require translation to and fro) and macros become much 
harder to manage.  Whether you like or dislike S-expr notation, it's the 
only thing that works well with macros (IMO) and macros are much more 
important to CL than syntax.

There is a freely-usable infix module that modifies the Cl readtable to 
support `normal' Java-C-ish infix notation in Common Lisp.  You can get 
it at the link below, and last time I checked it worked in the common CL 
implementations.  (Nonetheless, you might want to customize it according 
to the needs on your preferred Lisp, but it does work out of the box.)

http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html

But try using this module to write nontrivial Lisp systems that need 
macros, especially macros with multiple levels of backquotes, and you 
might change your opinion aboiut preferred notation.

Kantrowitz' infix module, or some customization if it, might indeed be 
quite useful where you want to accept infix notation from a user in an 
application, e.g. Maxima.
From: Ken Tilton
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <0TGJi.226$Vi4.186@newsfe12.lga>
Steven M. Haflich wrote:
>    It is true that for Lisp 
> beginners who have learned only C or Java, S-expr notation is a hurdle. 

Tell us more about your home planet. The only Earthlings who have a 
problem with Lisp syntax are people who have no interest in Lisp, have 
no intention of trying Lisp, and are just looking for something to say 
to justify their... I was going to say "stance", but that entails an 
ability to walk upright.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: ········@yahoo.es
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1190637191.175454.84210@50g2000hsm.googlegroups.com>
On 24 sep, 06:14, Ken Tilton <···········@optonline.net> wrote:
> Steven M. Haflich wrote:
> >    It is true that for Lisp
> > beginners who have learned only C or Java, S-expr notation is a hurdle.
>
> Tell us more about your home planet. The only Earthlings who have a
> problem with Lisp syntax are people who have no interest in Lisp, have
> no intention of trying Lisp, and are just looking for something to say
> to justify their... I was going to say "stance", but that entails an
> ability to walk upright.
>
> kenny
>
> --http://www.theoryyalgebra.com/
>
> "We are what we pretend to be." -Kurt Vonnegut




   This is very amusing.  I looked in your web page about teaching
algebra to newbies and what i found?

                       FIXED NOTATION

  And a revolutionary method, a simple example of it:   solve 3x+1=4

  I was thinking that since there is no need of a front-end, you
should give your lesson this way:

  Day 1: A Uniform assembly for a universal computational machine
representation.
  Day 2: Trivial coding (ASCII or something else).
  Day 3: Minimum entropic method of information enconding for 4 years
old student.
  Day 4:
          This is day four students, i'll give you 1MB of bits,
mentally generate the asembly code in your
  universal machine, generate the html output, describe how good i'm
in my style of html,
  then continue to read to solve the exercise:

     The end phase is something like:

                <html> ..... solve x + 1 = 2 </html>

--------------------------------------------------------------
 Dear Tilton, the head want to see you today, your method of teaching
is very stimated here.

 We know that dollars are no use to you, only a concrete front-end, a
human trivial creation, so i'll
give you something no so trivial: A kick in your ass.
---------------------------------------------------------------

   By the way, a good teacher is the best front-end, and i would like
my students have the best front-end:
From: Ken Tilton
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <c4QJi.28$lj3.5@newsfe12.lga>
········@yahoo.es wrote:
> On 24 sep, 06:14, Ken Tilton <···········@optonline.net> wrote:
> 
>>Steven M. Haflich wrote:
>>
>>>   It is true that for Lisp
>>>beginners who have learned only C or Java, S-expr notation is a hurdle.
>>
>>Tell us more about your home planet. The only Earthlings who have a
>>problem with Lisp syntax are people who have no interest in Lisp, have
>>no intention of trying Lisp, and are just looking for something to say
>>to justify their... I was going to say "stance", but that entails an
>>ability to walk upright.
>>
>>kenny
>>
>>--http://www.theoryyalgebra.com/
>>
>>"We are what we pretend to be." -Kurt Vonnegut
> 
> 
> 
> 
> 
>    This is very amusing.  I looked in your web page about teaching
> algebra to newbies and what i found?
> 
>                        FIXED NOTATION
> 
>   And a revolutionary method, a simple example of it:   solve 3x+1=4

You forgot. I like loop. No, I love loop. Chock full of syntax. You need 
a new argument, and a better memory.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <876420szme.fsf@web.de>
Ken Tilton <···········@optonline.net> writes:
>
> You forgot. I like loop. 

LOOP is clumsy  and unlispish, as  proven by Graham.
I use DO instead or recursion.

Klaus Schilling
From: Ken Tilton
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <Q%WJi.184$B01.62@newsfe12.lga>
Klaus Schilling wrote:
> Ken Tilton <···········@optonline.net> writes:
> 
>>You forgot. I like loop. 
> 
> 
> LOOP is clumsy  and unlispish, as  proven by Graham.

Agreed. A non sequitor, but agreed.

> I use DO instead or recursion.

I am happy for you. I use loop. Love it. Lisp brilliantly made the 
linked list the center of its universe, and a DSL for lists likewise is 
brilliant. Noobs should make a special effort (2-3 hours) to learn loop 
before doing any serious work, then use it for all iteration just to 
build fluency faster. (mapcar 'yadda list) allowed as an exception.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: John Thingstad
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <op.ty6bsycspqzri1@pandora.upc.no>
P� Mon, 24 Sep 2007 20:10:49 +0200, skrev Klaus Schilling  
<···············@web.de>:

> Ken Tilton <···········@optonline.net> writes:
>>
>> You forgot. I like loop.
>
> LOOP is clumsy  and unlispish, as  proven by Graham.
> I use DO instead or recursion.
>
> Klaus Schilling

look at iterate perhaps.. My choice
From: Frank Goenninger
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <fd962e$i0d$02$1@news.t-online.com>
On 2007-09-24 20:10:49 +0200, Klaus Schilling <···············@web.de> said:

> Ken Tilton <···········@optonline.net> writes:
>> 
>> You forgot. I like loop.
> 
> LOOP is clumsy  and unlispish, as  proven by Graham.
> I use DO instead or recursion.
> 
> Klaus Schilling

With all due respect for opinions but dismissing Loop completely is 
�unlispish�. Use your tools
when you need them - that's what Lisp is fundamentally about.

Ever looked at things like

  (loop
    with theta = (/ pi 2 slices)
    with etages = stacks ;; french floors (etages) zero = ground floor
    with lw/2 = (/ (r-width lbox) 2)
    with lh/2 = (/ (r-height lbox) 2)
    with bx = (- lw/2 baser)
    with by = (- lh/2 baser)
    for etage upto etages
    for oe = 0 then ie
    for ie = (unless (= etage etages)
                     (* (/ (1+ etage) etages)
                          (/ pi 2)))
    for ii = (if (not ie)
                 0
                 (+ (* (abs thickness)
                          (- 1 (cos ie)))))

    for ox = lw/2 then ix
    for oy = lh/2 then iy
    for oz = 0 then iz
    for oc = (cornering baser slices) then ic
    for ic = (when ie
                     (cornering (- baser ii) slices))
    for ix = (- lw/2 ii)
    for iy = (- lh/2 ii)
    for iz = (when ie
                     (* thickness (sin ie)))
     do ...

??? Believe me: That bunch of code was hard enough to understand with 
Loop ;- ) - but
without it ...

No, yes, of course. It's a matter of taste. But there *are* cases when 
Loop comes in handy -
or that's what my experience is. Iff you are a purist, well, then the 
world is sometimes harder
to go by with than what I'd consider necessary ...

Cheers!

   Frank

-- 
  Frank Goenninger

  frgo(at)goenninger(dot)net

  "Don't ask me! I haven't been reading comp.lang.lisp long enough to 
really know ..."

	
From: Espen Vestre
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <m1zlzb7q7c.fsf@gazonk.vestre.net>
Frank Goenninger <····@goenninger.net> writes:

> On 2007-09-24 20:10:49 +0200, Klaus Schilling <···············@web.de> said:
>> LOOP is clumsy  and unlispish, as  proven by Graham.
>> I use DO instead or recursion.
>>
>> Klaus Schilling
>
> With all due respect for opinions but dismissing Loop completely is
> �unlispish�. Use your tools
> when you need them - that's what Lisp is fundamentally about.

And with all due respect for the nostalgic purists among us, I don't
think DO is a tool one needs at all anymore.... Use all the
MAP-functions, use DOTIMES, use DOLIST, but whenever you reach for
your DO-loop, put it back into the dusty shelf where you found it, and
try a LOOP implementation first.
-- 
  (espen)
From: Kent M Pitman
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <ufy13fmir.fsf@nhplace.com>
Frank Goenninger <····@goenninger.net> writes:

> With all due respect for opinions but dismissing Loop completely is
> �unlispish�. Use your tools
> when you need them - that's what Lisp is fundamentally about.

Shame on you, you lazy soul you for writing ugly code like 

> (loop
>    with theta = (/ pi 2 slices)
>    with etages = stacks ;; french floors (etages) zero = ground floor
>    with lw/2 = (/ (r-width lbox) 2)
>    with lh/2 = (/ (r-height lbox) 2)
>    with bx = (- lw/2 baser)
>    with by = (- lh/2 baser)
>    for etage upto etages
>    for oe = 0 then ie
>    for ie = (unless (= etage etages)
>                     (* (/ (1+ etage) etages)
>                          (/ pi 2)))
>    for ii = (if (not ie)
>                 0
>                 (+ (* (abs thickness)
>                          (- 1 (cos ie)))))
>
>    for ox = lw/2 then ix
>    for oy = lh/2 then iy
>    for oz = 0 then iz
>    for oc = (cornering baser slices) then ic
>    for ic = (when ie
>                     (cornering (- baser ii) slices))
>    for ix = (- lw/2 ii)
>    for iy = (- lh/2 ii)
>    for iz = (when ie
>                     (* thickness (sin ie)))
>     do ...

that .  You should rewrite it at least to
something "Lispy" like this, since religious adherence to parenthetical
grouping is ALWAYS better than practical engineering considerations...

  (let* ((theta (/ pi 2 slices))
         (etages stacks) ;; french floors (etages) zero = ground floor
         (lw/2 (/ (r-width lbox) 2))
         (lh/2 (/ (r-height lbox) 2))
         (bx (- lw/2 baser))
         (by (- lh/2 baser))
         (etage -1)
         (oe 0)
         (ie)
         (i1)
         (ox)
         (oy)
         (oz)
         (oc)
         (ic)
         (first-time t))
    (loop
      (incf etage)
      (setq oe (if first-time 0 ie))
      (setq ie (unless (= etage etages)
                 (* (/ (1+ etage) etages)
                    (/ pi 2))))
      (setq i1 (if (not ie)
                    0
                  (+ (* (abs thickness)
                        (- 1 (cos ie))))))
      (setq ox (if first-time lw/2 ix))
      (setq oy (if first-time lh/2 iy))
      (setq oz (if first-time 0 iz))
      (setq oc (if first-time (cornering baser slices) ic))
      (setq ic (when ie
                 (cornering (- baser ii) slices)))
      (setq ix (- lw/2 ii))
      (setq iy (- lh/2 ii))
      (setq iz (when ie
                 (* thickness (sin ie))))
      (progn ...)))

Or, if you're also savvy enough to realize that side-effects are the
worst thing any program can ever do, you should go all the way to 
something more like:

 (labels ((foo (theta etages lw/2 lh/2 bx by etage 
                oe ie i1 ox oy oz oc ic first-time)
            ... do some computation ...
            (foo theta etages lw/2 lh/2 bx by (1+ etage)
                 ie (unless (= (1+ etage) etages)
                      (* (/ (+ etage 2) etages)
                         (/ pi 2)))
                 ...)))
   (foo (/ pi 2 slices) stacks (/ (r-width lbox) 2)
        (/ (r-height lbox) 2) (- lw/2 baser) (- lh/2 baser)
        0 (unless (zerop etages) (* (/ 1 etages) (/ pi 2)))
        (if (zerop etages) 0 ...)
        ...))

Because, after all, the MOST important thing any Lisp (or Scheme!)
program can ever show you is a bunch of unnamed, undifferentiated
initial arguments all in a row, unfettered by any hint of how they
will be used... As long as you can clearly separate the initial values
from the update values, you'll be able to figure out what's going on
much better.

There.  Now don't you feel better?

If not, you can always improve things further by changing
     (unless (zerop etages) (* (/ 1 etages) (/ pi 2)))
to
     (if (not (zerop etages)) (* (/ 1 etages) (/ pi 2)) nil)
That little readability trick should make things TRULY elegant...

;)
From: Frank Goenninger DG1SBG
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <lzve9yvfp7.fsf@pcsde001.de.goenninger.net>
Kent M Pitman <······@nhplace.com> writes:

> Frank Goenninger <····@goenninger.net> writes:
>
>> With all due respect for opinions but dismissing Loop completely is
>> �unlispish�. Use your tools
>> when you need them - that's what Lisp is fundamentally about.
>
> Shame on you, you lazy soul you for writing ugly code like 

[snipped the rest of a very entertaining but also highly educating
post of Kent]

Thanks, Kent, and all the other posters ... I still have to hold my
belly after almost having had a paroxysm of laughter :-)

After that 10 hour M$ Powerpoint session today I am back in good mood
- Yeah! Going from "Lisp front-end" to Loop to Purism ending in a
really enjoyable series of posts... Not possible in any other newsgroup -
that's what makes cll so special. Thx!

Frank
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <87641zmgtd.fsf@web.de>
Frank Goenninger <····@goenninger.net> writes:
> With all due respect for opinions but dismissing Loop completely is
> �unlispish�. Use your tools
> when you need them - 

 DO is all I ever need for iteration

Klaus Schilling
From: Espen Vestre
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <m1641y7uho.fsf@gazonk.netfonds.no>
Klaus Schilling <···············@web.de> writes:

>  DO is all I ever need for iteration

At least it's good job security: No modern softie lisp programmer will
want to touch the code of the Real DO Men ;-P
-- 
  (espen)
From: Matthias Buelow
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5lsqivF9ogsbU2@mid.dfncis.de>
Espen Vestre wrote:

> At least it's good job security: No modern softie lisp programmer will
> want to touch the code of the Real DO Men ;-P

Some time ago (years?), someone posted an example about YE OLDE LISP
HACKER, who would only use TAGBODY and GO...

Well... at least not spoiled by LOOP. :)
From: Matthias Buelow
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5ls28iF9mk0tU1@mid.dfncis.de>
Frank Goenninger wrote:

> Ever looked at things like
> 
>  (loop
>    with theta = (/ pi 2 slices)
>    with etages = stacks ;; french floors (etages) zero = ground floor
>    with lw/2 = (/ (r-width lbox) 2)
>    with lh/2 = (/ (r-height lbox) 2)
>    with bx = (- lw/2 baser)
>    with by = (- lh/2 baser)
>    for etage upto etages
>    for oe = 0 then ie
>    for ie = (unless (= etage etages)
>                     (* (/ (1+ etage) etages)
>                          (/ pi 2)))
>    for ii = (if (not ie)
>                 0
>                 (+ (* (abs thickness)
>                          (- 1 (cos ie)))))
> 
>    for ox = lw/2 then ix
>    for oy = lh/2 then iy
>    for oz = 0 then iz
>    for oc = (cornering baser slices) then ic
>    for ic = (when ie
>                     (cornering (- baser ii) slices))
>    for ix = (- lw/2 ii)
>    for iy = (- lh/2 ii)
>    for iz = (when ie
>                     (* thickness (sin ie)))
>     do ...
> 
> ??? Believe me: That bunch of code was hard enough to understand with
> Loop ;- ) - but
> without it ...

I guess it's supposed to be intuitive but to me it is incomprehensible;
what's the relationship between the "for"s? What's "for ... then" meant
to be? It doesn't resemble anything like the Algol-style languages it
supposedly mimicks. Why create explicit syntax that is gibberish and
only can be assigned meaning to if one knows exactly how the macro works?

I have never seen LOOP examples that I could figure out straight away,
except for very short ones (and yes, I refuse to learn it in detail; a
syntax like that is not supposed to be learned, that would defeat its
very purpose.)
From: Ken Tilton
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <1H8Ki.14$hP.3@newsfe12.lga>
Matthias Buelow wrote:
> Frank Goenninger wrote:
> 
> 
>>Ever looked at things like
>>
>> (loop
>>   with theta = (/ pi 2 slices)
>>   with etages = stacks ;; french floors (etages) zero = ground floor
>>   with lw/2 = (/ (r-width lbox) 2)
>>   with lh/2 = (/ (r-height lbox) 2)
>>   with bx = (- lw/2 baser)
>>   with by = (- lh/2 baser)
>>   for etage upto etages
>>   for oe = 0 then ie
>>   for ie = (unless (= etage etages)
>>                    (* (/ (1+ etage) etages)
>>                         (/ pi 2)))
>>   for ii = (if (not ie)
>>                0
>>                (+ (* (abs thickness)
>>                         (- 1 (cos ie)))))
>>
>>   for ox = lw/2 then ix
>>   for oy = lh/2 then iy
>>   for oz = 0 then iz
>>   for oc = (cornering baser slices) then ic
>>   for ic = (when ie
>>                    (cornering (- baser ii) slices))
>>   for ix = (- lw/2 ii)
>>   for iy = (- lh/2 ii)
>>   for iz = (when ie
>>                    (* thickness (sin ie)))
>>    do ...
>>
>>??? Believe me: That bunch of code was hard enough to understand with
>>Loop ;- ) - but
>>without it ...
> 
> 
> I guess it's supposed to be intuitive but to me it is incomprehensible;

Don't feel bad, I wrote it and I would not even /try/ to understand it 
without the long lost sheets of paper on which I worked out how to 
construct 3D buttons with parameters for radius in the horizontal plane 
and the vertical axis, as well as how many slices to use to smooth 
things out.

> what's the relationship between the "for"s? What's "for ... then" meant
> to be? 

What part of "for { ox = lw/2;; ox = ix }" do you not understand?

> It doesn't resemble anything like the Algol-style languages it
> supposedly mimicks.

I need a quotation here. Something with eyes and beholders, I think.

> Why create explicit syntax that is gibberish and
> only can be assigned meaning to if one knows exactly how the macro works?

The trick is not to give a rat's ass about anyone else understanding 
one's code.

> 
> I have never seen LOOP examples that I could figure out straight away,
> except for very short ones (and yes, I refuse to learn it in detail;

Yeah, that was me for like eight years. I was just as sure I was right 
then as you are now, so you can be sure you are as wrong now as I would 
be if I thought you would listen to me. Diagram that.

> a
> syntax like that is not supposed to be learned, that would defeat its
> very purpose.)

Not all Great Things are intuitive. Look at the double-push in speed 
skating.

    http://home1.gte.net/pjbemail/dpfront.html

Not only did it revolutionize the sport with its efficiency, it is the 
surest way to skate on sketchy surfaces/conditions. (One source says it 
may have originated as a solution to ice skating in the rain or something.)

Without the syntax, eg, I would need progns all over the map, and 
declarations for variables into which I want to collect. What you are 
(and I was) missing is that loop lives in what I like to call The 
Optimization Zone. In TOZ we make sacrifices to appease the God of 
Purity and then write the most appalling code. This TOZ is about 
programmer speed, not runtime speed, so loop is just appalling and 
indispensible in the good Lisp programmer's toolkit.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: ···@telent.net
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <4701520a$0$21100$da0feed9@news.zen.co.uk>
Ken Tilton wrote:
> Not all Great Things are intuitive. Look at the double-push in speed 
> skating.
> 
>    http://home1.gte.net/pjbemail/dpfront.html
> 
> Not only did it revolutionize the sport with its efficiency, it is the 
> surest way to skate on sketchy surfaces/conditions.

With the caveat that if your skate slips on that sketchy surface during 
the underpush, you're almost certainly going to stack because it's in 
the way of where you'd want to put the other foot to save yourself.  The 
_surest_ way to skate in bad conditions is to take shorter strides[*], 
adding DP to that will give you more speed but no more safety.

And on the subject of intuitive, I do see a lot of skaters doing it 
who've not had tuition in it - but in their hands ("on their feet"?) 
it's often questionable that it's any kind of Great Thing.  Like any 
kind of optimisation without profiling, really.

[*] MPC Storm Surge wheels don't hurt either, by all accounts


-dan
From: Ken Tilton
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <3BdMi.30$Qa3.13@newsfe12.lga>
···@telent.net wrote:
> Ken Tilton wrote:
> 
>> Not all Great Things are intuitive. Look at the double-push in speed 
>> skating.
>>
>>    http://home1.gte.net/pjbemail/dpfront.html
>>
>> Not only did it revolutionize the sport with its efficiency, it is the 
>> surest way to skate on sketchy surfaces/conditions.
> 
> 
> With the caveat that if your skate slips on that sketchy surface during 
> the underpush, you're almost certainly going to stack because it's in 
> the way of where you'd want to put the other foot to save yourself.

If the skate skids out it is, well, out isn't it? I mean, that's the 
essence of the problem, wouldn't you say? There's me, there's the 
ground, and there are no skates in between.

>  The 
> _surest_ way to skate in bad conditions is to take shorter strides[*], 
> adding DP to that will give you more speed but no more safety.

Odd. The double push is all about shorter strides, dividing one big push 
into two smaller ones. The underpushing foot is directly under you 
usefully between your COG and that of planet Earth, and the skate is 
more vertical hence less inclined to skid out. The recovering foot is 
well on the way back by the time the underpush has the slightest angle 
to it, which can be avoided anyway by angling the ankle.

kenny

-- 
http://www.theoryyalgebra.com/

"We are what we pretend to be." -Kurt Vonnegut
From: Rainer Joswig
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <joswig-A7B54A.12003025092007@news-europe.giganews.com>
In article <··············@mid.dfncis.de>,
 Matthias Buelow <···@incubus.de> wrote:

> Frank Goenninger wrote:
> 
> > Ever looked at things like
> > 
> >  (loop
> >    with theta = (/ pi 2 slices)
> >    with etages = stacks ;; french floors (etages) zero = ground floor
> >    with lw/2 = (/ (r-width lbox) 2)
> >    with lh/2 = (/ (r-height lbox) 2)
> >    with bx = (- lw/2 baser)
> >    with by = (- lh/2 baser)
> >    for etage upto etages
> >    for oe = 0 then ie
> >    for ie = (unless (= etage etages)
> >                     (* (/ (1+ etage) etages)
> >                          (/ pi 2)))
> >    for ii = (if (not ie)
> >                 0
> >                 (+ (* (abs thickness)
> >                          (- 1 (cos ie)))))
> > 
> >    for ox = lw/2 then ix
> >    for oy = lh/2 then iy
> >    for oz = 0 then iz
> >    for oc = (cornering baser slices) then ic
> >    for ic = (when ie
> >                     (cornering (- baser ii) slices))
> >    for ix = (- lw/2 ii)
> >    for iy = (- lh/2 ii)
> >    for iz = (when ie
> >                     (* thickness (sin ie)))
> >     do ...
> > 
> > ??? Believe me: That bunch of code was hard enough to understand with
> > Loop ;- ) - but
> > without it ...
> 
> I guess it's supposed to be intuitive but to me it is incomprehensible;
> what's the relationship between the "for"s? What's "for ... then" meant
> to be? It doesn't resemble anything like the Algol-style languages it
> supposedly mimicks. Why create explicit syntax that is gibberish and
> only can be assigned meaning to if one knows exactly how the macro works?
> 
> I have never seen LOOP examples that I could figure out straight away,
> except for very short ones (and yes, I refuse to learn it in detail; a
> syntax like that is not supposed to be learned, that would defeat its
> very purpose.)

Klingt auch wie der Suppen-Kaspar.

http://de.wikipedia.org/wiki/Struwwelpeter#Die_Geschichte_vom_Suppen-Kaspar

-- 
http://lispm.dyndns.org
From: Pascal Costanza
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5ls67bF9qq3rU1@mid.individual.net>
Matthias Buelow wrote:

> I guess it's supposed to be intuitive but to me it is incomprehensible;
> what's the relationship between the "for"s? What's "for ... then" meant
> to be? It doesn't resemble anything like the Algol-style languages it
> supposedly mimicks. Why create explicit syntax that is gibberish and
> only can be assigned meaning to if one knows exactly how the macro works?
> 
> I have never seen LOOP examples that I could figure out straight away,
> except for very short ones (and yes, I refuse to learn it in detail; a
> syntax like that is not supposed to be learned, that would defeat its
> very purpose.)

As a Lisper, you should be well aware that there is no such thing as a 
"natural syntax." Of course, you have to learn the LOOP language before 
you can use and read it effectively.

Restricting yourself to do and recursion is the Scheme/minimalist 
approach. LOOP is the Common Lisp approach: It may not be principled, 
but it's damn useful...


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <87wsuely4r.fsf@web.de>
Pascal Costanza <··@p-cos.net> writes:
>
> Restricting yourself to do and recursion is the Scheme/minimalist
> approach.

the minimalist approach is the best

Klaus Schilling
From: Pascal Costanza
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5lsgb0F9s4fuU1@mid.individual.net>
Klaus Schilling wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> Restricting yourself to do and recursion is the Scheme/minimalist
>> approach.
> 
> the minimalist approach is the best

Really? :)

Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <87y7eukbw7.fsf@web.de>
Pascal Costanza <··@p-cos.net> writes:

> Klaus Schilling wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>> Restricting yourself to do and recursion is the Scheme/minimalist
>>> approach.
>> the minimalist approach is the best
>
> Really? :)

of course it is

Klaus Schilling
From: Don Geddis
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <878x6te4zs.fsf@geddis.org>
Klaus Schilling <···············@web.de> wrote on Tue, 25 Sep 2007:
> Pascal Costanza <··@p-cos.net> writes:
>> Restricting yourself to do and recursion is the Scheme/minimalist
>> approach.
>
> the minimalist approach is the best

Is not!

(Extra points for applying the concept of recursion to this minor subthread...)
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
From: Matthias Buelow
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5lsqcfF9ogsbU1@mid.dfncis.de>
Pascal Costanza wrote:

> Restricting yourself to do and recursion is the Scheme/minimalist
> approach. LOOP is the Common Lisp approach: It may not be principled,
> but it's damn useful...

I'm not principally against a construct like that; I just don't like
LOOP. Maybe I should have a look at ITERATE some time and see if it's
more to my liking.
From: Kent M Pitman
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <uwsues7nc.fsf@nhplace.com>
Pascal Costanza <··@p-cos.net> writes:

> Restricting yourself to do and recursion is the Scheme/minimalist
> approach. LOOP is the Common Lisp approach: It may not be principled,
> but it's damn useful...

I might say it slightly differently:  The Common Lisp approach is to
assume that people do not always do things the same way, and in fact
the same person doesn't do things the same way every day, so LOOP is
among the tools that Common Lisp programmers are armed with in order
to fight the forces of dogmatic coding.

I'm not so sure that being tolerant of multiple paradigms is
unprincipled or that rejecting the notion of multiple paradigms is the
gateway to principle.

But I do agree that both LOOP and the recursion approach are useful.
The recursion approach in CL does have the drawback that tail calls
are not free, so one often wants to prefer iterative constructs for
very practical reasons.
From: Pascal Costanza
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <5lqqpbF9hiroU1@mid.individual.net>
Klaus Schilling wrote:
> Ken Tilton <···········@optonline.net> writes:
>> You forgot. I like loop. 
> 
> LOOP is clumsy  and unlispish, as  proven by Graham.
> I use DO instead or recursion.

Graham doesn't have a clue in this respect.

LOOP is more general than DO.

The general structure of a DO form is this:

(do ((var1 init1 expr1)
      (var2 init2 expr2)
      ...)
     (predicate [result])
   body ...)

This is equivalent to the following LOOP form:

(loop for var1 = init1 then expr1
       for var2 = init2 then expr2
       ...
       until predicate
       ; or:
       when predicate return result
       do body ...)

There is no real difference, except that the LOOP version contains a few 
keywords as hints what the different parts mean. IMHO, this makes the 
LOOP version more readable than the DO version.

On top of that, you can use more keywords to express some of the 
recurring idioms. It's neat that you can mix and match different idioms:

Compare:

(loop for var1 in list1
       for var2 = init2 then expr2
       for index from 0
       do body ...)

with:

(do ((tail1 list1 (cdr tail1))
      (var2 init2 expr2)
      (index 0 (1+ index))
     ((null tail1))
   (let ((var1 (car tail1)))
     body ...))

Things get even more convenient in LOOP when you use its collecting / 
value accumulating expressions and destructuring forms.

Really, there is no reason not to switch to LOOP when you usually use DO.

Using recursion is like programming in assembly language - far too 
low-level.

Just my 0.02�.


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Rob Warnock
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <Dfydnf2gRYV5U2XbnZ2dnUVZ_jWdnZ2d@speakeasy.net>
Pascal Costanza  <··@p-cos.net> wrote:
+---------------
| The general structure of a DO form is this:
| 
| (do ((var1 init1 expr1)
|       (var2 init2 expr2)
|       ...)
|      (predicate [result])
|    body ...)
| 
| This is equivalent to the following LOOP form:
| 
| (loop for var1 = init1 then expr1
|        for var2 = init2 then expr2
|        ...
|        until predicate
|        ; or:
|        when predicate return result
|        do body ...)
| 
| There is no real difference...
+---------------

Incorrect. These two are actually *semantically* different!!
To make them the same, you need to use AND instead of all but
the first FOR:

  (loop for var1 = init1 then expr1
	AND var2 = init2 then expr2
	...
	when predicate return result
	do body ...)

Alternatively, you could have used your "all FORs" version
of the LOOP but replaced DO by DO*, then they would have also
been the same [but still different from the other DO/LOOP pair].

+---------------
| Compare:
| (loop for var1 in list1
|        for var2 = init2 then expr2
|        for index from 0
|        do body ...)
| 
| with:
| (do ((tail1 list1 (cdr tail1))
|       (var2 init2 expr2)
|       (index 0 (1+ index))
|      ((null tail1))
|    (let ((var1 (car tail1)))
|      body ...))
+---------------

Again these are different: You need to either (1) use DO* for the
second or (2) in the LOOP replace all FOR except the first with AND.
Warning: (1) & (2) can give different results, depending upon the
form EXPR2!!

+---------------
| Really, there is no reason not to switch to LOOP when you usually use DO.
+---------------

I agree!! But when you do, at least get the semantics right...  ;-}  ;-}


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Harald Hanche-Olsen
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <pcor6kofvwe.fsf@shuttle.math.ntnu.no>
+ Ken Tilton <···········@optonline.net>:

> Steven M. Haflich wrote:
>>    It is true that for Lisp beginners who have learned only C or
>> Java, S-expr notation is a hurdle. 
>
> Tell us more about your home planet. The only Earthlings who have a
> problem with Lisp syntax are people who have no interest in Lisp,
> have no intention of trying Lisp, and are just looking for something
> to say to justify their... I was going to say "stance", but that
> entails an ability to walk upright.

I mostly agree, but we shouldn't overlook the /practical/ hurdle
beginners face with paren counting and indentation until they realize
that the editor will do all that for them and once you get used to
relying on the editor for these mundane tasks, you never need to worry
about it again.  I don't think it is possible to overemphasize this
point.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell
From: Klaus Schilling
Subject: Re: Needs Lisp a front-end?
Date: 
Message-ID: <87sl54p8q0.fsf@web.de>
········@yahoo.es writes:
>

>  Do you think that Lisp needs a Front-End?

never! infix-based syntax frontends are a pain in the hindside
and make understanding of the parse tree unnecessarily hard

Klaus Schilling