Let me make this absolutely clear up front, I love Lisp syntax, and
think it is the best syntax for a variety of reasons. I won't
enumerate the reasons here (I've done so in another article) except to
say that having programs represented like data and having the language
able to manipulate the programs at runtime is a whole order of
magnitude more powerful and expressive than any other language syntax
I've ever used.
Additionally, I would never want to change Lisp's syntax except for
the following. I program a lot in the commercial world. Virtually
every programmer I've ever worked with hates Lisp because of the
syntax - the parenthesis. I unsuccessfully argue that Lisp syntax is
no easier or harder than any other language _once you get used to it_.
If you started out programming in Pascal, C, Java, C#, etc., of course
Lisp will initially look strange but once you get used to Lisp's
parenthesis I don't believe it is any harder than any other syntax.
In fact, I'd argue that once you get used to Lisp's syntax, it turns
out to be easier because we don't have one syntax for function
definitions, one for type definitions, one for structures, etc. Lisp
has only one syntax. But I digress...
What I am interested in doing is creating C/Java/C# like (Algol)
syntax for Lisp as I describe below. Dylan originally and elegantly
used a lisp syntax. It was later changed to an Algol syntax for the
only reason of making it appeal to mainstream programmers. The
original intent was to change syntax's but keep it compatible and
interchangeable with its original lisp syntax. Of course, semantics
were to remain the same. So, for instance, the "if" function would
return a value - something unusual in a typical Algol language. The
Dylan team failed in this attempt for totally political reasons and
not technical reasons (based on communications I had with someone
closely involved). By "failed" I mean that they lost interest in and
ability to _interchange_ the language syntax with its original Lisp
roots. They, somewhat arbitrarily, made changes to the system without
regard to continued backward compatibility.
I'd like to create an Algol-like syntax for Common Lisp. 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).
I'd also like to have the ability to read in Lisp and output the new
syntax so that new syntax programmers would feel comfortable with code
written in Lisp syntax (the second converter).
Starting with something similar to Dylan would probably be a good
idea since this is what they originally intended and a lot of thought
was initially given in this area.
Doing this would make the system very portable. Any Common Lisp
system would be able to compile the converters. Once the language
converters (in both directions) were compiled new syntax code would be
able to be converted to Common Lisp and compiled or used by the native
Common Lisp system.
Now the reason for all this is several fold as follows:
1. Mainstream programmers would better entertain the use of such a
"new" language since it'll look familiar to them.
2. Lisp programmers would be able to code in native Common Lisp in a
mainstream world since the other programmers would see it in their
(Algol) syntax (using the second converter).
3. Existing Common Lisp environments could be used so no new compilers
would need to be built.
4. The mainstream programmers (after using the system for a while)
would slowly begin to discover the beautiful and powerful advantages
of a lisp environment (such as macros). This would really help the
language catch on.
5. Ultimately, this would create the possibility of getting more
mainstream programmers to take Lisp more seriously and start using
true lisp.
Now, knowing Lisp, a lot of this has probably already been done but I
don't know anything about it. Does anyone know about other similar
projects?
Secondly, is anyone interested in such a project?
Thanks for your time.
Blake McBride
·····@mcbride.name
http://blake.mcbride.name
> enumerate the reasons here (I've done so in another article) except to
> say that having programs represented like data and having the language
> able to manipulate the programs at runtime is a whole order of
> magnitude more powerful and expressive than any other language syntax
> I've ever used.
you can represent programs using an AST built up from, let's say CLOS
objects as opposed to cons cells. it would also have all the
properties you mentioned, it has not much to do with the syntax used.
using a more complex syntax would only mean that the AST would not be
as simple as a graph(*) built up from cons cells anymore, and
therefore writing macros would not be as simple as consing up a tree
from cons cells. (not that i would consider it a problem, see Slate
for an example of Smalltalk syntax and full-featured macros).
it would even have the useful property that you could easily annotate
the objects representing the code with random information without
disturbing the compilier or any other algorithms working on the AST
and not knowing the meaning of your annotation. but this could be done
using the original simple lisp syntax, only not using cons cells to
represent code. using cons cells and free-text makes it pointlessly
hard to annotate code and to store it in some database.
while using objects with the property of being able to hold
information without affecting the previously added information to it,
would make it much simpler to create projections of the code (thinking
of features like filtering out log statements and comment, etc)
many people around lisp think that cons cells are the great idea
behind lisp. in my opinion it's only a great tool to experiment with
metaprogramming and other complex ideas while we hardly understand the
problem domain. cons cell is just a good way to build up singly linked
lists and trees, no more no less. it's not too usedul to implement
hashtables nor representing programs or any other (non-trivially)
structured data.
</rant>
- attila
* due to symbols it's actually a graph, only a certain view of it can
be considered as a tree.
Check out my paper:
• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations
http://xahlee.org/UnixResource_dir/writ/notations.html
If you are serious, you probably should spend 2000+ dollars and buy a
copy of Mathematica, and study it for few months.
It is a living example of infix notation layed on top of sexp, and
inter-mixable anytime, in parts or whole.
I don't imagine this to be too diffilut if you are a parser expert.
For it to be successful (here we define success as wide adoption), you
have to pass the political hurdles. Passing the political hurdle,
basically means to get the old timer Lispers to use or recommend your
thing. This will be nign impossible, until they all dead. (which i
don't expect to happen in the next 20 years)
Few recommendations on how to go about:
• write a parser in emacs lisp. So that, pressing a button, will
convert all source code in a buffer from sexp to infix or vice versa.
And when it is in sexp form, it can be compiled by any lisp without
changing a single character.
• work alone. Don't go to public forums and say, let's work on this
together. Work alone and shut the fuck up.
• When you have this parser in emacs, and tried on hundreds of
existing lisp libraries and different implementations and non gives
you problems. Then, do the following:
• be extremely gentle, kind, and ass-kissing manner, and approach the
lisp organizations, for inclusion of your parser or idea. Appoarch
FSF, to have them include this in emacs. Approach the various lisp
companies, and show them your parser, or any associated paper.
• I repeat, you need to do this in a humble, ass-kissing manner. The
success of your algor-lisp syntax, depends on your ability of this.
Xah
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 25, 10:07 pm, Blake McBride <·····@mcbride.name> wrote:
> Let me make this absolutely clear up front, I love Lisp syntax, and
> think it is the best syntax for a variety of reasons. I won't
> enumerate the reasons here (I've done so in another article) except to
> say that having programs represented like data and having the language
> able to manipulate the programs at runtime is a whole order of
> magnitude more powerful and expressive than any other language syntax
> I've ever used.
>
> Additionally, I would never want to change Lisp's syntax except for
> the following. I program a lot in the commercial world. Virtually
> every programmer I've ever worked with hates Lisp because of the
> syntax - the parenthesis. I unsuccessfully argue that Lisp syntax is
> no easier or harder than any other language _once you get used to it_.
> If you started out programming in Pascal, C, Java, C#, etc., of course
> Lisp will initially look strange but once you get used to Lisp's
> parenthesis I don't believe it is any harder than any other syntax.
> In fact, I'd argue that once you get used to Lisp's syntax, it turns
> out to be easier because we don't have one syntax for function
> definitions, one for type definitions, one for structures, etc. Lisp
> has only one syntax. But I digress...
>
> What I am interested in doing is creating C/Java/C# like (Algol)
> syntax for Lisp as I describe below. Dylan originally and elegantly
> used a lisp syntax. It was later changed to an Algol syntax for the
> only reason of making it appeal to mainstream programmers. The
> original intent was to change syntax's but keep it compatible and
> interchangeable with its original lisp syntax. Of course, semantics
> were to remain the same. So, for instance, the "if" function would
> return a value - something unusual in a typical Algol language. The
> Dylan team failed in this attempt for totally political reasons and
> not technical reasons (based on communications I had with someone
> closely involved). By "failed" I mean that they lost interest in and
> ability to _interchange_ the language syntax with its original Lisp
> roots. They, somewhat arbitrarily, made changes to the system without
> regard to continued backward compatibility.
>
> I'd like to create an Algol-like syntax for Common Lisp. 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).
>
> I'd also like to have the ability to read in Lisp and output the new
> syntax so that new syntax programmers would feel comfortable with code
> written in Lisp syntax (the second converter).
>
> Starting with something similar to Dylan would probably be a good
> idea since this is what they originally intended and a lot of thought
> was initially given in this area.
>
> Doing this would make the system very portable. Any Common Lisp
> system would be able to compile the converters. Once the language
> converters (in both directions) were compiled new syntax code would be
> able to be converted to Common Lisp and compiled or used by the native
> Common Lisp system.
>
> Now the reason for all this is several fold as follows:
>
> 1. Mainstream programmers would better entertain the use of such a
> "new" language since it'll look familiar to them.
>
> 2. Lisp programmers would be able to code in native Common Lisp in a
> mainstream world since the other programmers would see it in their
> (Algol) syntax (using the second converter).
>
> 3. Existing Common Lisp environments could be used so no new compilers
> would need to be built.
>
> 4. The mainstream programmers (after using the system for a while)
> would slowly begin to discover the beautiful and powerful advantages
> of a lisp environment (such as macros). This would really help the
> language catch on.
>
> 5. Ultimately, this would create the possibility of getting more
> mainstream programmers to take Lisp more seriously and start using
> true lisp.
>
> Now, knowing Lisp, a lot of this has probably already been done but I
> don't know anything about it. Does anyone know about other similar
> projects?
>
> Secondly, is anyone interested in such a project?
>
> Thanks for your time.
>
> Blake McBride
> ·····@mcbride.namehttp://blake.mcbride.name
On Sat, 26 Jan 2008 00:07:52 -0600, Blake McBride wrote:
> I'd like to create an Algol-like syntax for Common Lisp. 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).
> ...
> Now, knowing Lisp, a lot of this has probably already been done but I
> don't know anything about it. Does anyone know about other similar
> projects?
>
> Secondly, is anyone interested in such a project?
>
> Thanks for your time.
>
> Blake McBride
> ·····@mcbride.name
> http://blake.mcbride.name
There are plenty of projects for replacing the grammar of bits of lisp.
Apart from the ones that are part of the official language (format and
loop), there are numerous infix projects to do infix notation
for arithmetic expressions eg
http://www.cliki.net/infix
Interestingly there are projects in the other direction eg Liskell gives
Haskell a less enigmatic syntax (using parentheses). There is at least one
for Java, and one for C.
My question would be - How do you do macros well, without parentheses?
To my mind the biggest obstacles to Lisp are not the parentheses. They are
1a. Lack of standard foreign function interface (calling C from Lisp).
1b. Inability to call Lisp from other languages.
2. Lack of a standard or dominant GUI interface.
3. Lack of standard threading.
4. The lack of orthogonality in the language. Lots of random things to
learn. MAP* being the prime example.
... 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.
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.
Tim Josling
tim Josling wrote:
> On Sat, 26 Jan 2008 00:07:52 -0600, Blake McBride wrote:
>
>> I'd like to create an Algol-like syntax for Common Lisp. 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).
>> ...
>> Now, knowing Lisp, a lot of this has probably already been done but I
>> don't know anything about it. Does anyone know about other similar
>> projects?
>>
>> Secondly, is anyone interested in such a project?
>>
>> Thanks for your time.
>>
>> Blake McBride
>> ·····@mcbride.name
>> http://blake.mcbride.name
>
> There are plenty of projects for replacing the grammar of bits of lisp.
> Apart from the ones that are part of the official language (format and
> loop), there are numerous infix projects to do infix notation
> for arithmetic expressions eg
>
> http://www.cliki.net/infix
>
> Interestingly there are projects in the other direction eg Liskell gives
> Haskell a less enigmatic syntax (using parentheses). There is at least one
> for Java, and one for C.
>
> My question would be - How do you do macros well, without parentheses?
Good question. I think this is/was a major issue with the Dylan
conversion. I haven't given it a lot of thought yet but I intuitively
feel that it wouldn't be too hard.
>
> To my mind the biggest obstacles to Lisp are not the parentheses. They are
> 1a. Lack of standard foreign function interface (calling C from Lisp).
> 1b. Inability to call Lisp from other languages.
> 2. Lack of a standard or dominant GUI interface.
> 3. Lack of standard threading.
> 4. The lack of orthogonality in the language. Lots of random things to
> learn. MAP* being the prime example.
What I was referring to was the main reason mainstream programmers don't
use Lisp not what the may experience once they started to use it. I
think 99% of mainstream programmers who have looked at Lisp never got
past the parentheses to the issues you raise.
As an aside, I think the issues you raise are not difficult to solve.
The real problem is getting people to agree on the solution.
>
> ... 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.
>
> 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.
I have a son I started to teach programming to. He hasn't seen anything
except Lisp & Scheme so he doesn't know anything different. He has no
trouble at all with the syntax.
>
> Tim Josling
On Jan 26, 1:21 am, tim Josling <·············@westnet.com.au> 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/learning-logo-part-one/
...but I may bring her along with me to Common Lisp.
http://lojic.com/blog/2008/01/17/2008-programming-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.
*ahem*
Ever thought of, you know, ditching text editors as the visual
interface for coding? All those nasty problems with macros and syntax?
Gone. You could even set up an editor to support lisp-like rendering
along with non-ugly rendering of code. Granted, I have no idea why
you'd _want_ that in this sort of situation, since it seems people
only really "like" lisp syntax because it facilitates macros. In an
environment like above, no visual interface affects the structure of
the code.
On Jan 26, 12:07 am, Blake McBride <·····@mcbride.name> wrote:
> Let me make this absolutely clear up front, I love Lisp syntax, and
> think it is the best syntax for a variety of reasons. I won't
> enumerate the reasons here (I've done so in another article) except to
> say that having programs represented like data and having the language
> able to manipulate the programs at runtime is a whole order of
> magnitude more powerful and expressive than any other language syntax
> I've ever used.
>
> Additionally, I would never want to change Lisp's syntax except for
> the following. I program a lot in the commercial world. Virtually
> every programmer I've ever worked with hates Lisp because of the
> syntax - the parenthesis. I unsuccessfully argue that Lisp syntax is
> no easier or harder than any other language _once you get used to it_.
> If you started out programming in Pascal, C, Java, C#, etc., of course
> Lisp will initially look strange but once you get used to Lisp's
> parenthesis I don't believe it is any harder than any other syntax.
> In fact, I'd argue that once you get used to Lisp's syntax, it turns
> out to be easier because we don't have one syntax for function
> definitions, one for type definitions, one for structures, etc. Lisp
> has only one syntax. But I digress...
>
> What I am interested in doing is creating C/Java/C# like (Algol)
> syntax for Lisp as I describe below. Dylan originally and elegantly
> used a lisp syntax. It was later changed to an Algol syntax for the
> only reason of making it appeal to mainstream programmers. The
> original intent was to change syntax's but keep it compatible and
> interchangeable with its original lisp syntax. Of course, semantics
> were to remain the same. So, for instance, the "if" function would
> return a value - something unusual in a typical Algol language. The
> Dylan team failed in this attempt for totally political reasons and
> not technical reasons (based on communications I had with someone
> closely involved). By "failed" I mean that they lost interest in and
> ability to _interchange_ the language syntax with its original Lisp
> roots. They, somewhat arbitrarily, made changes to the system without
> regard to continued backward compatibility.
>
> I'd like to create an Algol-like syntax for Common Lisp. 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).
>
> I'd also like to have the ability to read in Lisp and output the new
> syntax so that new syntax programmers would feel comfortable with code
> written in Lisp syntax (the second converter).
>
> Starting with something similar to Dylan would probably be a good
> idea since this is what they originally intended and a lot of thought
> was initially given in this area.
>
> Doing this would make the system very portable. Any Common Lisp
> system would be able to compile the converters. Once the language
> converters (in both directions) were compiled new syntax code would be
> able to be converted to Common Lisp and compiled or used by the native
> Common Lisp system.
>
> Now the reason for all this is several fold as follows:
>
> 1. Mainstream programmers would better entertain the use of such a
> "new" language since it'll look familiar to them.
>
> 2. Lisp programmers would be able to code in native Common Lisp in a
> mainstream world since the other programmers would see it in their
> (Algol) syntax (using the second converter).
>
> 3. Existing Common Lisp environments could be used so no new compilers
> would need to be built.
>
> 4. The mainstream programmers (after using the system for a while)
> would slowly begin to discover the beautiful and powerful advantages
> of a lisp environment (such as macros). This would really help the
> language catch on.
>
> 5. Ultimately, this would create the possibility of getting more
> mainstream programmers to take Lisp more seriously and start using
> true lisp.
>
> Now, knowing Lisp, a lot of this has probably already been done but I
> don't know anything about it. Does anyone know about other similar
> projects?
>
> Secondly, is anyone interested in such a project?
>
> Thanks for your time.
>
> Blake McBride
> ·····@mcbride.namehttp://blake.mcbride.name
> Ever thought of, you know, ditching text editors as the visual
> interface for coding? All those nasty problems with macros and syntax?
> Gone. You could even set up an editor to support lisp-like rendering
macros will always be needed in form of runnable programs no matter
how smart your editor is. and definitely not as some kind of
templating mechanism, IOW, i don't want my macros to be expanded
(except while compiling and debugging)...
> along with non-ugly rendering of code. Granted, I have no idea why
> you'd _want_ that in this sort of situation, since it seems people
> only really "like" lisp syntax because it facilitates macros. In an
> environment like above, no visual interface affects the structure of
> the code.
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. it makes
transforming code much-much simpler which is very important as long as
programming is an art not a well defined algorithm...
- attila
On Jan 26, 12:13 pm, ··············@gmail.com wrote:
> > Ever thought of, you know, ditching text editors as the visual
> > interface for coding? All those nasty problems with macros and syntax?
> > Gone. You could even set up an editor to support lisp-like rendering
>
> macros will always be needed in form of runnable programs no matter
> how smart your editor is. and definitely not as some kind of
> templating mechanism, IOW, i don't want my macros to be expanded
> (except while compiling and debugging)...
Apparently I wasn't clear enough. I was implying that it makes macros
easier to implement with a non-ugly interface, not that they're
unnecessary.
> 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
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?
> 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 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, ··············@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, ··············@gmail.com wrote:
> > 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.
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
---------------------
····················@mac.com
http://web.mac.com/jay_reynolds_freeman (personal web site)
Curtis W <·········@gmail.com> writes:
> *ahem*
>
> ... since it seems people
> only really "like" lisp syntax because it facilitates macros.
I don't. I like macros because they make it easy to use lisp syntax.
Joost.
Joost Diepenmaat <·····@zeekat.nl> writes:
> Curtis W <·········@gmail.com> writes:
>
> > *ahem*
> >
> > ... since it seems people
> > only really "like" lisp syntax because it facilitates macros.
>
> I don't. I like macros because they make it easy to use lisp syntax.
I like Lisp syntax because c-m-f and friends work on it.
Blake McBride wrote:
> I'd like to create an Algol-like syntax for Common Lisp. 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).
>
> I'd also like to have the ability to read in Lisp and output the new
> syntax so that new syntax programmers would feel comfortable with code
> written in Lisp syntax (the second converter).
Macros will probably be hard, but you may want to take a look at
Jonathan Bachrach's work on d-expressions, an attempt to integrate a
'full' macro system into Dylan.
I think that additional parsing and pretty-printing steps are not really
worthwhile because they don't really go the whole way. Instead, I think
it would be neater if the internal AST is an object graph which can be
presented and modified using an MVC approach (or something similar).
This could potentially give us a system in which you could mix and match
different (domain-specific) syntaxes, or maybe even fully graphical
program elements.
The research on intentional programming goes in that direction. See also
Andrew Eisenberg's work on edit-time metaobject protocols, or Robert
Wensman's work at http://www.ida.liu.se/~robwe/ which is probably more
Lispy. Scheme's syntax objects may be a good starting point.
I'd be surprised if there weren't even more related approaches in the
past, with some good ideas...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Sat, 26 Jan 2008 00:07:52 -0600, Blake McBride wrote:
> I'd like to create an Algol-like syntax for Common Lisp. 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).
Since you've cross-posted to comp.lang.scheme, I'll point out that the
plt-scheme folk have Algol, Java(ish) and a more literal infix/scheme
syntax front end available ("Honu"). Not Common Lisp, but perhaps worth
a look, to see how successful or effective the effort is. They probably
have papers on it all, too.
> I'd also like to have the ability to read in Lisp and output the new
> syntax so that new syntax programmers would feel comfortable with code
> written in Lisp syntax (the second converter).
The PLT algol-syntax modules don't do this, as far as I know (haven't
actually tried them, myself.) I have a suspicion that the resulting code
might look "funny", simply because it's likely to be less imperative and
more functional than your target market is used to. C and Java code
doesn't spend a whole lot of time cons'ing, in my experience. (Sure,
that's not all of Lisp, either, but it does happen some of the time,
versus none at all...)
> Starting with something similar to Dylan would probably be a good idea
> since this is what they originally intended and a lot of thought was
> initially given in this area.
True. It would be really interesting to hear from insiders about some of
the forces that made keeping the sexpr version working hard.
Cheers,
--
Andrew
I'm new to Lisp, but I was quite surprised by how over-hyped (in my
own opinion) the parenthesis thing. After reading an intro to it in a
tutorial, I was prepared to see an ugly lump of source code. Instead I
saw something similar to C like syntax, but with the opening
parenthesis before, not after the function. It is quite clear now how
this is a benefit.
Example code:
Lisp-like
(defun my-func ()
(format t "hello world"))
C-like
(defun my-func()
(format t "hello world")
)
There really is not that much difference when you look at it like
that, except the lisp version is more beautiful (in my opinion).
Blake McBride <·····@mcbride.name> 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.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak wrote:
> Blake McBride <·····@mcbride.name> 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
Blake McBride wrote:
> Ray Blaak wrote:
>> 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.
Yes, just like Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 2 Giu, 11:24, Jon Harrop <····@ffconsultancy.com> 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
···················@gmail.com wrote:
> On 2 Giu, 11:24, Jon Harrop <····@ffconsultancy.com> 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
--
Lars Rune Nøstdal
http://nostdal.org/
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Blake McBride <·····@mcbride.name> 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...
>
> http://en.wikipedia.org/wiki/CGOL
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
···@xahlee.org
∑ http://xahlee.org/
☄
On Jan 28, 12:45 am, Kent M Pitman <······@nhplace.com> wrote:
> [ comp.lang.lisp only;http://www.nhplace.com/kent/PFAQ/cross-posting.html]
>
> Blake McBride <·····@mcbride.name> 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
From: Richard M Kreuter
Subject: Re: Algol-like syntax for Lisp
Date:
Message-ID: <87abmphhg6.fsf@progn.net>
Kent M Pitman <······@nhplace.com> writes:
> Blake McBride <·····@mcbride.name> 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/ai-repository/ai/lang/lisp/code/syntax/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.
--
RmK
Richard M Kreuter <·······@progn.net> writes:
> 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.
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;