Ray Blaak wrote:
> Blake McBride <blake> writes:
>> What I am interested in doing is creating C/Java/C# like (Algol)
>> syntax for Lisp as I describe below.
>
> It's already been done. It's called JavaScript.
>
> Really.
>
> JavaScript is a lisp in disguise: dynamic typing, functional values, full
> closures.

While some of what you say is true:

1. JS is not currently compiled and impossibly slow for real
development of stand-alone applications.

2. JS classes are a wart

3. JS doesn't answer most or any of the reasons I gave for the project

4. JS has insufficient libraries to do anything real (except in a
browser) - like file IO, etc.

Blake McBride

> > i like the lisp syntax because it doesn't try to pretend that an "if"
> > is different from a "my-randomly-introduced-abstraction" by having
> > different syntax rules for the various constructs.
>
> Uhh... they _are_ different. Just like how my-randomly-introduced-
> abstraction is different from my-other-randomly-introduced-
> abstraction. It seems like you prefer a uniform syntax because it
> allows for easy code transformation, rather than because it's somehow
> better. Let me ask you this: if you could get macros that work exactly


well, if it makes code transformation easier and i'm transforming code
a lot, then i consider it better.


> like in lisp, are just as elegant, _and_ you could create a completely
> custom visual representation for each abstraction, would you still
> prefer lisp syntax?


with this you made me thinking for a while, but i think i would prefer
the lisp syntax most of the time. maybe some very often used
constructs would benefit from their own easily distinguishable
graphical representations, but it also has benefits that you don't
have to keep a big repository in your had about the available syntaxes
while editing. all you must keep in mind is a repository of names
mapping to abstractions. somehow i have a feeling that having _too
many_ different graphical representations would be a drawback because
while reading the code you must run through what you see on one more
layer in your head. but this is all speculation...


> > it makes
> > transforming code much-much simpler which is very important as long as
> > programming is an art not a well defined algorithm...
>
> A simple _storage medium_ makes code transformation simple. If you
> unhook the visual interface from said storage medium, any kind of
> "syntax" can allow for easy code transformation.

i think you misunderstood me. here by "transformation" i meant when
the programmer is shaping the code by hand, as opposed to programs
doing transformation on a simple storage medium. when you introduce a
new abstraction or change an old one and you transform the current
codebase due to this change.

if you had a custom syntax for something... what would it be worth if
you always had to go back to a uniform representation when you wanted
to edit the code? the purpose of a custom syntax is to make code
smaller and easier to read and write. i think the lisp syntax in most
cases allows you to make stuff smaller (using macros) and (for me)
syntax coloring seems to be enough to make code reading good enough.
all this applies to most of the code i write, but not 100% of it.

so to sum up my opinion: i would definitely like to have a system
where code (and everything else) is not stored in free text (nor in
consed up lists) but instead in annotatable objects. then based on
this it would be cool to have a gui framework where you can develop
custom graphical representations for some often used constructs. but i
think i would still use sexp's for most of the abstractions.

- attila

On Jan 27, 5:57 am, attila.lend...@gmail.com wrote:
> > like in lisp, are just as elegant, _and_ you could create a completely
> > custom visual representation for each abstraction, would you still
> > prefer lisp syntax?
>
> with this you made me thinking for a while, but i think i would prefer
> the lisp syntax most of the time. maybe some very often used
> constructs would benefit from their own easily distinguishable
> graphical representations, but it also has benefits that you don't
> have to keep a big repository in your had about the available syntaxes
> while editing.
This reminds me of the argument against macros. If you have macros in
a language, you now have to keep them all in your head or be prepared
to look them up. If you were to create a custom editor that's visually
extendable, you'd also be able to create an appropriate interface for
it, as well, which means you don't have to edit the raw AST. I can
certainly see the potential for abuse, which is why it wouldn't hurt
to have a "disable code styling" button. If you disable all styling
you basically have the AST.

> all you must keep in mind is a repository of names
> mapping to abstractions. somehow i have a feeling that having _too
> many_ different graphical representations would be a drawback because
> while reading the code you must run through what you see on one more
> layer in your head. but this is all speculation...
I suppose more exotic representations would have somewhat of a
learning curve, but presumably most code would look basically the same
as most other "syntaxy" languages. Interestingly, you can turn this
argument around on macros, too:

"Somehow I have a feeling that having _too many_ different language
constructs would be a drawback because while reading the code you must
run through what you see on one more layer in your head."

With increasingly powerful constructs comes an increasing learning
curve. If you're dealing with somebody that doesn't mind the small
startup cost, it's always better to go for more power.

> so to sum up my opinion: i would definitely like to have a system
> where code (and everything else) is not stored in free text (nor in
> consed up lists) but instead in annotatable objects. then based on
> this it would be cool to have a gui framework where you can develop
> custom graphical representations for some often used constructs. but i
> think i would still use sexp's for most of the abstractions.
I'm not sure what you mean by "a gui framework." If you had a custom
editor, all you'd need to do is provide a plug-in mechanism so that
macros can hook into it and change their appearance and interface.
This would certainly be easier than trying to hook macros into, say,
the parsing code of a language.

> I suppose more exotic representations would have somewhat of a
> learning curve, but presumably most code would look basically the same
> as most other "syntaxy" languages. Interestingly, you can turn this
> argument around on macros, too:
>
> "Somehow I have a feeling that having _too many_ different language
> constructs would be a drawback because while reading the code you must
> run through what you see on one more layer in your head."
>
> With increasingly powerful constructs comes an increasing learning
> curve. If you're dealing with somebody that doesn't mind the small
> startup cost, it's always better to go for more power.


i see your point and you are right.

the more i think about it, the more i believe that any work on
customizing the visual presentation of some AST nodes is just an
extension to macros which can be abused as any other programming tool.
btw, there's work on it already in some scheme systems (DrScheme?).


> > so to sum up my opinion: i would definitely like to have a system
> > where code (and everything else) is not stored in free text (nor in
> > consed up lists) but instead in annotatable objects. then based on
> > this it would be cool to have a gui framework where you can develop
> > custom graphical representations for some often used constructs. but i
> > think i would still use sexp's for most of the abstractions.
>
> I'm not sure what you mean by "a gui framework." If you had a custom


a lot of code (the framework) that makes it possible to write tiny
code fragments that are the customized presentations of some AST
nodes, most probably involving various DSLs (e.g. one for the logical
layout).


> editor, all you'd need to do is provide a plug-in mechanism so that
> macros can hook into it and change their appearance and interface.
> This would certainly be easier than trying to hook macros into, say,
> the parsing code of a language.

i think i mean the same by "a gui framework".

in this hypothetical new world there wouldn't be parsing/reading as
there is today. parsing was only used as an effective way to input a
chunk of the AST by humans.

- attila

On Jan 27, 3:33 pm, attila.lend...@gmail.com wrote:
>>
> i see your point and you are right.
>
> the more i think about it, the more i believe that any work on
> customizing the visual presentation of some AST nodes is just an
> extension to macros which can be abused as any other programming tool.
Yes, exactly. It's basically just a different form of abstraction.

> btw, there's work on it already in some scheme systems (DrScheme?).
I have seen a few screenshots of DrScheme with, e.g., images and stuff
embedded in the source code. Other than that it looks like it's still
just a text editor.

> > > so to sum up my opinion: i would definitely like to have a system
> > > where code (and everything else) is not stored in free text (nor in
> > > consed up lists) but instead in annotatable objects. then based on
> > > this it would be cool to have a gui framework where you can develop
> > > custom graphical representations for some often used constructs. but i
> > > think i would still use sexp's for most of the abstractions.
>
> > I'm not sure what you mean by "a gui framework." If you had a custom
>
> a lot of code (the framework) that makes it possible to write tiny
> code fragments that are the customized presentations of some AST
> nodes, most probably involving various DSLs (e.g. one for the logical
> layout).
Ah, I see. Nevermind, then.

> > editor, all you'd need to do is provide a plug-in mechanism so that
> > macros can hook into it and change their appearance and interface.
> > This would certainly be easier than trying to hook macros into, say,
> > the parsing code of a language.
>
> i think i mean the same by "a gui framework".
>
> in this hypothetical new world there wouldn't be parsing/reading as
> there is today. parsing was only used as an effective way to input a
> chunk of the AST by humans.
Well, you'd still need to serialize/deserialize the AST, which means
you'll need a parser if you want to store it in a file. However, you
don't need anything fancy--you can easily get by with whatever
serialization methods your language provides.

You might do a search on "r-lisp" or "rlisp", possibly in combination
with another keyword, "algol", for an example of a rather conventional
lisp that used Algol-like syntax. (But beware, the term "rlisp" has
also come to refer to some kind of lisp embedded in Ruby, which is not
what I had in mind.)

I did some professional work using r-lisp in the mid 1980s; I found
the syntax satisfactory, but on the whole preferred the use of
parentheses because their use led to less text on the screen.

If memory serves, what we had was a preprocessor that accepted the
Algol-like stuff and emitted the fully parenthesized equivalent.


-- Jay Reynolds Freeman
---------------------
Jay_Reynolds_Freeman
http://web.mac.com/jay_reynolds_freeman (personal web site)

[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]

Blake McBride <blake> writes:

> I'd like to create an Algol-like syntax for Common Lisp.

Do people even know what you mean when you use this term any more?
I usually get blank faces when I use it. :(

> The syntax and semantics would always remain compatible with Lisp.
> The program would be written in Common Lisp. It would read in the
> new syntax and output Common Lisp (the first converter).

This issue is not really new and has been studied in great detail.

Please make sure to read up on CGOL. CGOL was nice for those who
liked that kind of thing because it was entirely non-invasive to
MACLISP. I see no reason a similar thing could not be done for CL if
you were of a mind to...

http://en.wikipedia.org/wiki/CGOL

Dear Kent,

> Please make sure to read up on CGOL. CGOL was nice for those who
> liked that kind of thing because it was entirely non-invasive to
> MACLISP. I see no reason a similar thing could not be done for CL if
> you were of a mind to...
>
> [..]

Thank you for this.

That's really informative. (then the drivels coming from Lisper's
mounths most of the time.)

Btw, you wrote a reply to a post of mine recently in a thread that
discusses lisp1 and lisp2. Your post is a few thousands words, and on
the first reading i didn't feel a urge to reply to any particular
point, and or that it will take me few hours to write a reply to your
well written and long post. Thanks for the info though.

(PS I am cross posting this to the scheme and dylan groups because i
feel its good info people should know. Any who reply to this please
exercise your own judgement)

Xah
xah
∑ http://xahlee.org/

☄

On Jan 28, 12:45 am, Kent M Pitman <pit> wrote:
[..]

Kent M Pitman <pitman> writes:
> Blake McBride <blake> writes:

> Please make sure to read up on CGOL. CGOL was nice for those who
> liked that kind of thing because it was entirely non-invasive to
> MACLISP. I see no reason a similar thing could not be done for CL
> if you were of a mind to...

Tom Phelps, working under Fateman, ported/rewrote CGOL in a CLtL2-era
CL:

http://www.cs.cmu.edu/afs/cs/project...ax/cgol/0.html

The code doesn't seem to work on modern Lisp, but it can be reworked
to do so.

In his paper on the modernization of CGOL, Phelps makes an interesting
observation about the downside of using CGOL as a frontend to Common
Lisp:

The problem is that, except for simple cases, to use CGOL one must
more or less know the meaning of the Lisp translation, which begs
the question, Why not dial direct? Say, for instance, there is a
complex Lisp operator to which CGOL provides a more aesthetically
pleasing interface---arrays, for instance.

make-array dims [:adjustable adj] [:element-type et] [:fill-pointer fp]
{[:initial-element ie] | [:initial-contents ic] | [:displaced-to dt
[:displaced-index-offset dio]]}

To use the CGOL notation I must first figure out how I wish to
utilize this function (as I have forgotten one of the seven optional
parameters) so I look up this function in Lisp (which is how CGOL
defines its notation). Once having determined the Lisp form I need,
I must translate this into CGOL. Why not cut out the middle man?
To be sure, it would ease the life of the CGOL implementor as
optional parameters are handled in an ad hoc way, with
special-purpose code included with every function.

AFAIU, the MACLISP for which CGOL was originally designed didn't have
keyword arguments or quite as many complex macros as CL has; I wonder
whether CL proves to be a less good target for a syntactic frontend
than a language like MACLISP was.

Richard M Kreuter <kreuter> writes:

[..]
> defines its notation). Once having determined the Lisp form I need,
> I must translate this into CGOL. Why not cut out the middle man?
> To be sure, it would ease the life of the CGOL implementor as
> optional parameters are handled in an ad hoc way, with
> special-purpose code included with every function.
>
> AFAIU, the MACLISP for which CGOL was originally designed didn't have
> keyword arguments or quite as many complex macros as CL has; I wonder
> whether CL proves to be a less good target for a syntactic frontend
> than a language like MACLISP was.

An interesting observation, to be sure. But I'm not willing to give up
on the issue without more thought.

For example, it would probably take a bit of work to figure out
details, but using a Pratt parser, which CGOL did, you could make some
preposition or prepositinos (perhaps 'with') that would read a set of
=-separated exprssions and attach them to the expression on the
left. e.g.,

open(x) with direction=:output;

found := member x y with test=#'equal;

On Jan 26, 1:21 am, tim Josling <tejgcc_nos> wrote:
> ... I am teaching by daughter to program at the moment. We have been using
> lisp so far. She was horrified by the parentheses at first, but once we
> started using a text editor with indenting and parenthesis-matching, she
> seems content enough.

I began teaching my daughter Common Lisp (as I began learning it
myself) and she had no problem with the syntax. With no preconceived
idea of what a programming language syntax should look like, it just
seemed "normal".

I decided it would be better to start with Berkeley Logo for our
purposes...

http://lojic.com/blog/2008/01/05/lea...logo-part-one/

....but I may bring her along with me to Common Lisp.

http://lojic.com/blog/2008/01/17/200...language-plan/

> Later we will do C. It will be interesting to see
> how she reacts to C with Lisp as background. For most people, their
> expectations are set with an imperative language as their first language.
> Also of course people are trained with infix mathematical expressions.

Curious how that will go. I would think a garbage collected language
with a REPL would be better for learning an imperative language -
Ruby, Python, etc.

Blake McBride wrote:
> Ray Blaak wrote:
>
> While some of what you say is true:
>
> 1. JS is not currently compiled and impossibly slow for real
> development of stand-alone applications.
>
> 2. JS classes are a wart
>
> 3. JS doesn't answer most or any of the reasons I gave for the project
>
> 4. JS has insufficient libraries to do anything real (except in a
> browser) - like file IO, etc.

Yes, just like Lisp.

On 2 Giu, 11:24, Jon Harrop <j> wrote:
> (me, hating)

P.S. Since I can't win Lisp with arguments, I resort to hating it. I
hope this is OK.

Jon Harrop

jon.harrop.ms.sharp wrote:
> On 2 Giu, 11:24, Jon Harrop <j> wrote:
>> (me, hating)
>
> P.S. Since I can't win Lisp with arguments, I resort to hating it. I
> hope this is OK.
>
> Jon Harrop

lol .. how old are you? .. 4? *whaaaah! whaaaah! whuuhaaah!*

if it's so bad -- what's there to win? .. go away