Lisp and Scheme with fewer parentheses
bir...@tpg.com.au
Please keep an open mind whist reading this post. If you're not
interested in new syntaxes for Lisp/Scheme, please read no further.
defun factorial (n)
if (<= n 1)
^ 1
* n
factorial (- n 1)
Still there? OK, good. I'm looking for people who are interested in
using a lisp/scheme with Python-style indentation for lists.
The goal of the project is to provide this syntax as open source
add-ons to Scheme and Lisps. I have a small collection of links and
source code by people who have played with this idea in the past.
There is an open-source front-end for my tiny Lisp which converts
indented syntax into the traditional. This is available on the web
on-line for interactive play. Hence I also have running indented code
(See below). So far it all seems to work as you would expect,
code=data, macros etc.
I would like to hook up with folk who have an open mind and can provide
feedback, find issues, make comments, write code samples, provide tests
or whatever.
Send an email to me (rot13 "ove...@gct.pbz.nh") and I'll forward the
links to the project site.
Cheers
Bill Birch
#### Eight Queens
#### Taken from "Lisp" by Winston & Horn 2nd edition
#### Problem 11-9
####
DEFUN QUEEN (SIZE) (QUEEN-AUX NIL 0 SIZE)
DEFUN QUEEN-AUX (BOARD N SIZE)
COND
(= N SIZE)
BOARD-PRINT (REVERSE BOARD)
else
QUEEN-SUB BOARD N 0 SIZE
DEFUN QUEEN-SUB (BOARD N M SIZE)
COND
(= M SIZE)
else
COND
(CONFLICT N M BOARD)
else
QUEEN-AUX (CONS (LIST N M) BOARD) (+ N 1) SIZE
QUEEN-SUB BOARD N (+ M 1) SIZE
DEFUN CONFLICT (cN cM cBOARD)
COND
(NULL cBOARD) NIL
(OR (THREAT cN cM (CAAR cBOARD) (CADAR cBOARD)) (CONFLICT cN cM
(CDR cBOARD)))
DEFUN THREAT (I J A B)
OR
= I A
= J B
= (- I J) (- A B)
= (+ I J) (+ A B)
DEFUN BOARD-PRINT (BOARD)
BOARD-PRINT-AUX BOARD (LENGTH BOARD)
DEFUN BOARD-PRINT-AUX (BOARD SIZE)
TERPRI
COND
(NULL BOARD)
else
BOARD-PRINT-SUB (CADAR BOARD) 0 SIZE
BOARD-PRINT-AUX (CDR BOARD) SIZE
DEFUN BOARD-PRINT-SUB (COLUMN N SIZE)
COND
(= N SIZE)
else
COND
(= COLUMN N)
PRINC "Q"
else
PRINC "."
PRINC " "
BOARD-PRINT-SUB COLUMN (+ N 1) SIZE
Bruce Stephens
[...]
> I have a small collection of links and source code by people who
> have played with this idea in the past.
Right, it's been done before. SRFI-49, for example.
It's obviously relatively straightforward to do, but apparently not
that successful. So why bother trying again?
[...]
Ken Tilton
bir...@tpg.com.au wrote:
> Hi,
>
> Please keep an open mind whist reading this post.
PWUAUAUUAAAHAHAHAHAHAHAAHAHAHAHHHOOHOHHHOHH Oh Christ I'm gonna pee
PWUAHAHHAHAHHAAHHHAOHOHOHOO...nice try, tho.
> If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
And miss the fun? Besides, my stomach is growling something fierce. I
haven't finished this, you might want to run for it while you can.
>
> defun factorial (n)
> if (<= n 1)
> ^ 1
> * n
> factorial (- n 1)
>
> Still there?
Yes, trying to decide what kind of wine will go best with you. Looks
like we'll be dining on Bush later, hope you do not clash with that as
an appetizer.
> OK, good.
I would not be so sure.
> I'm looking for people who are interested in
> using a lisp/scheme with Python-style indentation for lists.
You might try comp.lang.python. (Duhhhhh!)
>
> The goal of the project is to provide this syntax as open source
> add-ons to Scheme and Lisps. I have a small collection of links and
> source code by people who have played with this idea in the past.
Have you noticed we killed them all?
>
> There is an open-source front-end for my tiny Lisp which converts
> indented syntax into the traditional. This is available on the web
> on-line for interactive play. Hence I also have running indented code
> (See below). So far it all seems to work as you would expect,
> code=data, macros etc.
>
> I would like to hook up with folk who have an open mind and can provide
> feedback, find issues, make comments, write code samples, provide tests
> or whatever.
Can your editor select an arbitrary subform with a double-click?
>
> Send an email to me (rot13 "ove...@gct.pbz.nh") and I'll forward the
> links to the project site.
Don't wait up late for me. :)
kenny (wondering where the hell he left the key to the kennel)
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ari Johnson
What do macros look like? Write up a few good macros here to
demonstrate the usefulness of your syntax.
JShr...@gmail.com
<Literally ROTFL!> Given the context, I have to say that this is by far
the funniest baker's dozen words I have ever read! (Come on, Kenny!
Admit it! You put this poor slob up to this troll just so that you
could use this fine line, right?! (I'll bet that it's not even a real
person, just a fake email that you gentemp'ed just for this well-timed
event!)) <Oh my god, my sides hurt; I think I'm going to barf!>
Kumar
I wrote a source code translator called "ez2scm" quite a while back in
dedication to the same cause.
Source - http://code.google.com/p/ez2scm
Description -
http://web.mac.com/srikumarks/iWeb/Site/programming/programming.html
LtU thread on the topic - http://lambda-the-ultimate.org/node/1646
Your factorial can be written in EzScheme like this -
define (factorial n)
if (n <= 1)
1
n * (factorial (n - 1))
I used right associative infix operators in addition to indentation.
-Kumar
Ken Tilton
JShr...@gmail.com wrote:
> (Come on, Kenny!
> Admit it! You put this poor slob up to this troll just so that you
> could use this fine line, right?!
Nonsense. The beauty of these idiots is that they need no invention. Did
he really say (from memory) "Keep an open mind?" One cannot write stuff
that good.
OK, who is going to head over to c.l.python and suggest parentheses
instead of whitespace? It could be a pretty funny post. "Hey, guys! I
was looking at Lisp, had this great idea...keep an open mind!"
kt
Kjetil S. Matheussen
Here's another one:
http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
The idea of the one above is actually not so bad. Its an invitation for
people to use common music with an interface that could be less scary for
people not used to paranthesis. And after a while, they may go
over to doing proper programming. (common music is a tool for
people that are firstmost musicians, not programmers)
Pascal Costanza
>
> Here's another one:
> http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
> The idea of the one above is actually not so bad. Its an invitation for
> people to use common music with an interface that could be less scary for
> people not used to paranthesis. And after a while, they may go over to
> doing proper programming. (common music is a tool for people that are
> firstmost musicians, not programmers)
Why would a notation without parentheses be more appropriate for
"non-programmers" than one with?
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/
Kjetil S. Matheussen
On Wed, 8 Nov 2006, Pascal Costanza wrote:
> Kjetil S. Matheussen wrote:
>>
>> Here's another one:
>> http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
>> The idea of the one above is actually not so bad. Its an invitation for
>> people to use common music with an interface that could be less scary for
>> people not used to paranthesis. And after a while, they may go over to
>> doing proper programming. (common music is a tool for people that are
>> firstmost musicians, not programmers)
>
> Why would a notation without parentheses be more appropriate for
> "non-programmers" than one with?
>
I didn't write that (and I certainly don't believe it). I just wrote that
it could be less scary. (And I didn't write "non-programmers" either,
please quote me correctly!)
Ken Tilton
Dammit, stop waffling! You post a link and then say "Don't quote me!"?
Bullsh*t! Less scary? What a frickin coward! Do you or do you not
understand the superiority of parens? If not, I will need an article of
your clothing so the hounds can pick up the scent. If so, then what on
Earth makes you think that a syntax good for you could be not good for
someone else? Especially a musician, who in my brief experience with the
LispNYC music SIG seem to be easily as smart and technical as
programmers?!!!!!!!!
Less scary?!!! You mean they will look at a syntax you know to have
extraordinary advantage and run out of the room screaming before you can
explain it to them????
OK, no, not possible. Clearly /you/ are the one who does not really
"get" parens. No problem, we see a lot of faint-hearted types like you
around here. Hell, even Franz refuses to mention Lisp (they sell
"dynamic objects") and even adopted ".cl" as an extension in a hilarious
attempt to fool potential potential customers.
We have seen the enemy, and they are us. - Pogo
Kjetil S. Matheussen
On Wed, 8 Nov 2006, Ken Tilton wrote:
>
>
> Kjetil S. Matheussen wrote:
>>
>>
>> On Wed, 8 Nov 2006, Pascal Costanza wrote:
>>
>> > Kjetil S. Matheussen wrote:
>> >
>> > >
>> > > Here's another one:
>> > > http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
>> > > The idea of the one above is actually not so bad. Its an invitation
>> > > for
>> > > people to use common music with an interface that could be less
>> > > scary for
>> > > people not used to paranthesis. And after a while, they may go over
>> > > to
>> > > doing proper programming. (common music is a tool for people that are
>> > > firstmost musicians, not programmers)
>> >
>> >
>> > Why would a notation without parentheses be more appropriate for
>> > "non-programmers" than one with?
>> >
>>
>> I didn't write that (and I certainly don't believe it). I just wrote that
>> it could be less scary. (And I didn't write "non-programmers" either,
>> please quote me correctly!)
>
> Dammit, stop waffling! You post a link and then say "Don't quote me!"?
I'm not sure whether you are serious or not. But I said something more
like this: don't quote me incorrectly!
> Bullsh*t! Less scary? What a frickin coward! Do you or do you not understand
> the superiority of parens? If not, I will need an article of your clothing so
> the hounds can pick up the scent. If so, then what on Earth makes you think
> that a syntax good for you could be not good for someone else? Especially a
> musician, who in my brief experience with the LispNYC music SIG seem to be
> easily as smart and technical as programmers?!!!!!!!!
>
> Less scary?!!! You mean they will look at a syntax you know to have
> extraordinary advantage and run out of the room screaming before you can
> explain it to them????
>
> OK, no, not possible. Clearly /you/ are the one who does not really "get"
> parens. No problem, we see a lot of faint-hearted types like you around here.
> Hell, even Franz refuses to mention Lisp (they sell "dynamic objects") and
> even adopted ".cl" as an extension in a hilarious attempt to fool potential
> potential customers.
>
> We have seen the enemy, and they are us. - Pogo
>
Nah, in my opinion, more paranthesis -> better programming -> better
music. I don't care about much else.
nall...@gmail.com
Ken Tilton wrote:
> bir...@tpg.com.au wrote:
> > Hi,
> >
> > Please keep an open mind whist reading this post.
>
> PWUAUAUUAAAHAHAHAHAHAHAAHAHAHAHHHOOHOHHHOHH Oh Christ I'm gonna pee
> PWUAHAHHAHAHHAAHHHAOHOHOHOO...nice try, tho.
lmao
Pascal Costanza
I guess the part about "non-programmers" is quoted correctly. You have
written "common music is a tool for people that are [...] not programmers)."
You're right about the "scary" vs. "more appropriate" part. Sorry for that.
So let me rephrase: Why would a notation without parentheses be less
scary for non-programmers than one with?
[If you really don't like the part about "non-programmers", replace it
with "less experienced programmers", or "part-time programmers", or
something. You get the idea (I hope).
I am also not necessarily asking you specifically. I am more wondering
where this notion comes from that parentheses are in any way "scary",
whatever that means. It rather seems to be a prejudice that,
interestingly, typically computer scientists have, not people from
outside the field.]
Pascal
Kjetil S. Matheussen
On Wed, 8 Nov 2006, Pascal Costanza wrote:
> Kjetil S. Matheussen wrote:
>>
>>
>> On Wed, 8 Nov 2006, Pascal Costanza wrote:
>>
>> > Kjetil S. Matheussen wrote:
>> > >
>> > > Here's another one:
>> > > http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
>> > > The idea of the one above is actually not so bad. Its an invitation
>> > > for
>> > > people to use common music with an interface that could be less
>> > > scary for
>> > > people not used to paranthesis. And after a while, they may go over
>> > > to
>> > > doing proper programming. (common music is a tool for people that are
>> > > firstmost musicians, not programmers)
>> >
>> > Why would a notation without parentheses be more appropriate for
>> > "non-programmers" than one with?
>> >
>>
>> I didn't write that (and I certainly don't believe it). I just wrote that
>> it could be less scary. (And I didn't write "non-programmers" either,
>> please quote me correctly!)
>
> I guess the part about "non-programmers" is quoted correctly. You have
> written "common music is a tool for people that are [...] not programmers)."
>
Oh, sorry. I see now that the sentence can be interpreted two ways. What I
ment was people that are firstmost being musicians, and firstmost not
being programmers, for example musicians that also now about programming.
I'm one of those.
So, your quote is wrong, but its understandable that you did so. I guess I
live in a world where its obvious that musicians also know how to
program...
> You're right about the "scary" vs. "more appropriate" part. Sorry for that.
>
> So let me rephrase: Why would a notation without parentheses be less scary
> for non-programmers than one with?
>
If they already know a c or python or something, and don't know lisp,
then the paranthesis can be scary. At least, thats what I hear.
Joel Wilsson
> So let me rephrase: Why would a notation without parentheses be less
> scary for non-programmers than one with?
>
> [If you really don't like the part about "non-programmers", replace it
> with "less experienced programmers", or "part-time programmers", or
> something. You get the idea (I hope).
For less experienced programmers, or part-time programmers, the syntax
is so different from what they're used to that some find it scary.
Those who aren't willing to spend a minimal amount of time to figure
out why it is the way it is, will either find it stupid or try to
change it.
For non-programmers, it would probably be very difficult to understand
the advantages of having such a simple syntax that you can easily
modify programmatically. If they see lisp code in an article or in a
book, they also won't have any way to easily find matching parens, and
then I imagine it would be very difficult to follow for someone new to
programming.
I think that the effort spent trying to find "easier" syntaxes would be
better spent on writing articles explaining S-expressions, trying to
educate people. I'm new to lisp, but it didn't take me long to figure
out why all the parens are necessary (and even good). It does require
you to not accept that this is a different world from C, but so does a
lot of other things in this language and culture. If people can't
accept a different kind of syntax, it's just a matter of time until
they run into something else they find unacceptable and wrong, like the
module system or the object system.
That's not to say everything is good and perfect and impossible to
improve, far from it. But there's a difference between looking at
something and saying "this is different from what I know, and thus it
must be bad and should be changed" and saying that "this is different
from what I know, but I understand why; however, it's bad because it
doesn't let me do X and makes Y much harder, so perhaps we could change
it into this and keep all the advantages and make this other stuff
easier".
Besides, history has already shown (over and over, it seems) that
changing the syntax is just not going to happen.
Rob Thorpe
> Kjetil S. Matheussen wrote:
> >
> > Here's another one:
> > http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
> > The idea of the one above is actually not so bad. Its an invitation for
> > people to use common music with an interface that could be less scary for
> > people not used to paranthesis. And after a while, they may go over to
> > doing proper programming. (common music is a tool for people that are
> > firstmost musicians, not programmers)
>
> Why would a notation without parentheses be more appropriate for
> "non-programmers" than one with?
The normal meaning of parentheses in the english language is to denote
a clause in a sentence that states something separate from the rest of
the sentence and less important. Lisp uses the parenthesis to mean
something altogether different and something all of it's own.
Parentheses still mean separation, but separation in a much more
rigourous way to normal parentheses and are a form of separation used
for almost every element of the language, not just a bit of it like
english. Plus what is inside them isn't necessarily less important.
So from the point of view of user friendliness it seems sensible. The
question is though: What is to replace it? Terminators like "end if"
are just as alien to human languages as parens are. Use of indentation
is also pretty uncommon.
I'd argue for indentation though, just because so many people have seen
and used presentations based on bullet-points.
Any way you do it isn't going to be easy for the user to figure out.
bir...@tpg.com.au
Ari Johnson wrote:
>
> What do macros look like? Write up a few good macros here to
> demonstrate the usefulness of your syntax.
A good question.
defmacro if (test success-result &optional failure-result)
backquote
cond
,test ,success-result
t ,failure-result
defmacro when (test &rest body)
backquote
cond
,test ,@body
A different symbol can be used for backquote to save typing
setq ! backquote
defmacro unless (test &rest rest)
!
cond
(not ,test) ,@rest
Details depend on which Lisp you're using.
bir...@tpg.com.au
> Hi,
>
> I wrote a source code translator called "ez2scm" quite a while back in
> dedication to the same cause.
>
> Source - http://code.google.com/p/ez2scm
> Description -
> http://web.mac.com/srikumarks/iWeb/Site/programming/programming.html
> LtU thread on the topic - http://lambda-the-ultimate.org/node/1646
>
> Your factorial can be written in EzScheme like this -
>
> define (factorial n)
> if (n <= 1)
> 1
> n * (factorial (n - 1))
>
> I used right associative infix operators in addition to indentation.
>
> >
Thanks I had a look at your site. I'll back-link when I get a round
Toit. You can also mention that indentation is how many people are
taught to write hierarchical lists, at least in English anyhow.
My view is that prefix is critical to the syntax, so I'm not interested
in infix. I think infix breaks macros but I can't be bothered to prove
it. The bottom line is that the parser has to be very dumb and very
consistent. As soon as you complicate the parse you will loose the code
== data duality. My pre-processor just adds another way to communicate
list structures with indentation.
bir...@tpg.com.au
Kjetil S. Matheussen wrote:
> Here's another one:
> http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
> The idea of the one above is actually not so bad. Its an invitation for
> people to use common music with an interface that could be less scary for
> people not used to paranthesis. And after a while, they may go
> over to doing proper programming. (common music is a tool for
> people that are firstmost musicians, not programmers)
>
>
>
infix. commas used in lists. It seems to have "end" to close blocks, so
I am not even sure it uses python-style indentations at all.
I guess my feature list is merely "list structures can be denoted by
indentation and parens, everything else is pretty much the same".
Charlton Wilbur
> So let me rephrase: Why would a notation without parentheses be less
> scary for non-programmers than one with?
>
> [If you really don't like the part about "non-programmers", replace it
> with "less experienced programmers", or "part-time programmers", or
> something. You get the idea (I hope).
>
> I am also not necessarily asking you specifically. I am more wondering
> where this notion comes from that parentheses are in any way "scary",
> whatever that means. It rather seems to be a prejudice that,
> interestingly, typically computer scientists have, not people from
> outside the field.]
It's an old prejudice. People who have mastered (at least some of)
the habits of thought required in programming seem to develop the
notion that syntax is intimidating, and learning syntax is hard. It
may be; but semantics, and the habits of thought required for good
programming, are much harder.
The impulse that leads people to "simplify" Lisp syntax is the same
impulse that led Grace Hopper to create COBOL so that business people
could program, that led Kemeny and Kurtz to create BASIC so that
"beginners" could program. (The impulse to simplify semantics, or at
least to reduce the possible topics, leads in another direction, to
PHP and Ruby on Rails.) I'm not surprised that novice programmers
with exposure to only one language should succumb to that impulse;
Hopper, Kemeny, and Kurtz certainly had more experience than that.
It's just that now we're 40 years down the line and those of us who
are paying attention have learned that syntax is, at least compared to
semantics, easy.
Charlton
Christopher Koppler
wrote:
> I'm not sure whether you are serious or not.
Kenny is (quite far) on the other side of not serious - like knurd is
on the other side of sober from drunk.
Bill Atkins
Christopher Koppler
> A different symbol can be used for backquote to save typing
>
> setq ! backquote
I fail to see the savetyping qualities of \#! considering there's \#`.
smal...@juno.com
>
> #### Eight Queens
> #### Taken from "Lisp" by Winston & Horn 2nd edition
> #### Problem 11-9
> ####
>
> DEFUN THREAT (I J A B)
> OR
> = I A
> = J B
> = (- I J) (- A B)
> = (+ I J) (+ A B)
>
>
>
Your syntax is inconsistent since you still have parenthesized
lists of arguments, and parenthesized terms in functions where
they really aren't needed. Perhaps you could use:
DEFUN THREAT
I
J
A
B
OR
= I A
= J B
=
-
I
J
-
A
B
=
+
I
J
+
A
B
There. That should keep you safe from all the parens.
--S
Nicolas Neuss
> I am also not necessarily asking you specifically. I am more wondering
> where this notion comes from that parentheses are in any way "scary",
> whatever that means. It rather seems to be a prejudice that,
> interestingly, typically computer scientists have, not people from
> outside the field.]
It's a big loss that Erik is not present anymore:
http://groups.google.com/group/comp.lang.lisp/msg/6f52a3ddc61d6028
Nicolas
Stefan Scholl
> Please keep an open mind whist reading this post. If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
Nope. First you should start to tell us about your background.
Many new Lisp users try to change the syntax. It's a kind of
running gag in the Lisp newsgroup.
Then you can acknowledge that you have read
http://www.gigamonkeys.com/book/syntax-and-semantics.html
"In other words, the people who have actually used Lisp
over the past 45 years have liked the syntax and have
found that it makes the language more powerful. In the
next few chapters, you'll begin to see why."
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
ana...@earthlink.net
> Pascal Costanza wrote:
> > Why would a notation without parentheses be more appropriate for
> > "non-programmers" than one with?
>
> The normal meaning of parentheses in the english language is to denote
> a clause in a sentence that states something separate from the rest of
> the sentence and less important. Lisp uses the parenthesis to mean
> something altogether different and something all of it's own.
> Parentheses still mean separation, but separation in a much more
> rigourous way to normal parentheses and are a form of separation used
> for almost every element of the language, not just a bit of it like
> english. Plus what is inside them isn't necessarily less important.
All programming languages that use parentheses for grouping work
that way.
The only difference is that other programming languages have other
grouping rules as well. Lisp just has parentheses.
Ari Johnson
> Ari Johnson wrote:
>
>>
>> What do macros look like? Write up a few good macros here to
>> demonstrate the usefulness of your syntax.
>
> A good question.
>
> defmacro if (test success-result &optional failure-result)
> backquote
> cond
> ,test ,success-result
> t ,failure-result
What's with all the parentheses?
> defmacro when (test &rest body)
> backquote
> cond
> ,test ,@body
Where did the commas come from? Why is what you wrote better than the
following?
(defmacro when (test &rest body)
`(cond (,test ,@body)))
> A different symbol can be used for backquote to save typing
>
> setq ! backquote
Why would you even call it backquote? The only reason to use that
word is because of the use of the actual backquote character by Common
Lisp for this purpose. Will your math operators all be given the name
of the symbol they replace?
> defmacro unless (test &rest rest)
> !
> cond
> (not ,test) ,@rest
>
> Details depend on which Lisp you're using.
There are way too many scary symbols in that. I suggest the following,
for the sake of consistency:
defmacro unless LEFT-PARENTHESIS test AMPERSAND-NO-SPACE rest rest RIGHT-PARENTHESIS
BACKQUOTE
cond
LEFT-PARENTHESIS not COMMA-NO-SPACE test RIGHT-PARENTHESIS COMMA-AT-NO-SPACE rest
Uh-oh. Now my lines are too wide for my editor. How do you deal with
that when whitespace has syntactic meaning?
Moreover, your example of unless has two pairs of parentheses. The
following code has four. How many parentheses does it take to become
scary?
(defmacro unless (test &body body)
`(cond (not ,test) ,@body))
Ken Tilton
Kjetil S. Matheussen wrote:
>
>
> On Wed, 8 Nov 2006, Ken Tilton wrote:
>
>>
>>
>> Kjetil S. Matheussen wrote:
>>
>>>
>>>
>>> On Wed, 8 Nov 2006, Pascal Costanza wrote:
>>>
>>> > Kjetil S. Matheussen wrote:
>>> > > > > > Here's another one:
>>> > >
>>> http://ccrma-mail.stanford.edu/pipermail/cmdist/2006-July/003334.html
>>> > > The idea of the one above is actually not so bad. Its an
>>> invitation > > for
>>> > > people to use common music with an interface that could be less
>>> > > scary for
>>> > > people not used to paranthesis. And after a while, they may go
>>> over > > to
>>> > > doing proper programming. (common music is a tool for people
>>> that are
>>> > > firstmost musicians, not programmers)
>>> > > > Why would a notation without parentheses be more appropriate
>>> for > "non-programmers" than one with?
>>> >
>>>
>>> I didn't write that (and I certainly don't believe it). I just wrote
>>> that
>>> it could be less scary. (And I didn't write "non-programmers" either,
>>> please quote me correctly!)
>>
>>
>> Dammit, stop waffling! You post a link and then say "Don't quote me!"?
>
>
> I'm not sure whether you are serious or not.
Rarely. :)
Ken Tilton
Christopher Koppler wrote:
> On Nov 8, 10:54 am, "Kjetil S. Matheussen" <k.s.matheus...@notam02.no>
> wrote:
>
>>I'm not sure whether you are serious or not.
>
>
> Kenny is (quite far) on the other side of not serious -
Cool, this reminds me of some of the activities I have in mind for
getting beginning Algebra students accustomed to adding and subtracting
negative numbers.
:)
Ken Tilton
Which does not require the shift key.
Ken Tilton
Charlton Wilbur wrote:
> The impulse that leads people to "simplify" Lisp syntax is the same
> impulse that led Grace Hopper to create COBOL so that business people
> could program,
I heard it was so auditors could detect fraud.
Rob Thorpe
Yes. Other languages use parentheses for something closer to their
mathematical use though. But it's confusing any way.
grackle
engineering types cream their pants, because it would create a
heirarchy of programmers, somewhat similar to Fred Brooks' roles but in
an even more corporate-friendly form. The peons would work by default
in the Python syntax, and if that prevents them from writing macros, so
much the better. They would be supported and directed by Lisp wizards
who customized the language for the application being developed.
I think this might end up happening some day if someone creates a
popular language like Python or Ruby on top of Lisp. As long as the
S-expressions are clearly optional and mostly kept out of sight, they
wouldn't be a barrier to adoption, but in the end everyone with any ego
or ambition would end up using them.
-David
Steve Schafer
There is already a Pascal/C-like syntax for Scheme/Lisp: Dylan. And
Dylan has macros, too. But that hasn't been enough to get very many
people interested.
Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
Pascal Costanza
This could be attributed to mere force of habit, and doesn't say
anything about Lisp itself. Whenever one learns a new language, syntax
can be a first stumbling, no matter what the language.
Pascal Costanza
> Pascal Costanza wrote:
>> So let me rephrase: Why would a notation without parentheses be less
>> scary for non-programmers than one with?
>>
>> [If you really don't like the part about "non-programmers", replace it
>> with "less experienced programmers", or "part-time programmers", or
>> something. You get the idea (I hope).
>
> For less experienced programmers, or part-time programmers, the syntax
> is so different from what they're used to that some find it scary.
> Those who aren't willing to spend a minimal amount of time to figure
> out why it is the way it is, will either find it stupid or try to
> change it.
>
> For non-programmers, it would probably be very difficult to understand
> the advantages of having such a simple syntax that you can easily
> modify programmatically. If they see lisp code in an article or in a
> book, they also won't have any way to easily find matching parens, and
> then I imagine it would be very difficult to follow for someone new to
> programming.
From what I hear, this seems to be incorrect. Those who haven't seen
any programming language yet seem to have much less problems with Lisp
syntax than those who have.
> Besides, history has already shown (over and over, it seems) that
> changing the syntax is just not going to happen.
I don't think so. I think there are languages that are based on Lisp,
changed the syntax and are (to various degrees) successful. They aren't
just Lisp anymore.
Pascal Costanza
> I think a Python-like syntax for Lisp would make make certain software
> engineering types cream their pants, because it would create a
> heirarchy of programmers, somewhat similar to Fred Brooks' roles but in
> an even more corporate-friendly form. The peons would work by default
> in the Python syntax, and if that prevents them from writing macros, so
> much the better. They would be supported and directed by Lisp wizards
> who customized the language for the application being developed.
a) The notion that preventing "lesser" programmers from writing macros
has benefits is the same as the idea that preventing them from writing
functions, classes, methods, variables, etc., has benefits. It's weird,
though, that no one seems to come up with, or defend, the latter.
b) As soon as you provide a new surface syntax for Lisp, you also have
to think about how to make it extensible, at least from the lower
levels. Otherwise you lose the extensibility provided by macros. In
other words, "expert" programmers wouldn't be able to provide new
language constructs to the surface syntax level anymore.
I think that's probably the essential reason why no mainstream surface
syntax seems to catch on in the Lisp world because the proposals
typically forget to discuss the extensibility aspect (except for Dylan
to a certain degree).
> I think this might end up happening some day if someone creates a
> popular language like Python or Ruby on top of Lisp. As long as the
> S-expressions are clearly optional and mostly kept out of sight, they
> wouldn't be a barrier to adoption, but in the end everyone with any ego
> or ambition would end up using them.
Popular languages have already been developed on top of Lisp / Common
Lisp several times. From the top of my head, at least Haskell, ML, Dylan
and Scheme.
grackle
> There is already a Pascal/C-like syntax for Scheme/Lisp: Dylan. And
> Dylan has macros, too. But that hasn't been enough to get very many
> people interested.
There have been many languages like Perl and Ruby that never caught on,
but a few did. There are many reasons languages flourish and die, and
most of them are accidental or superficial. Dylan suffered from the
worst handicap of all, being a language created by language gurus to
bring linguistic goodness to the masses. They even admitted early on
that they were using Lisp. Compare that to Java, which made many vague
Dilbertesque boasts of superiority over C++ yet managed to cultivate
the expectation among programmers that it was just a simplified and
cleaned-up version of C++.
For a language to take the route I described, the Lisp part would have
to remain pretty much secret, and if it were known, the language
inventor would have to say, "Bah, it was expedient and serves well
enough as a basis for the implementation, but the real story is that
FooLanguage is 5% simpler than Python, has 10% more hippie goodness
than Ruby, and is 25% more IT-geek-friendly than Perl!"
The parentheses come later, after FooLanguage is wildly popular and you
have many ambitious and ego-driven users vying to be FooMasters.
-David
Kjetil S. Matheussen
Well, it should be done. Its too bad that the programming world is in such
a state of craziness. Otherwise smart people appear to be 100% sure that
lisp is crap or worth ignoring, always without being able to explain why.
Sneeking lisp into the computing world by building super-good programming
languages on top of lisp is one way of slowly taking over the world.
And regarding macros, it is possible to provide macros for a python build
upon lisp, that are just as powerful as lisp macros, but only if those
macros are actually written in lisp. That should make some python
programmers see the light after a while...
But who knows, in time, perhaps someone discover a programming paradigm
even more powerful than lisp. And if we all have become totally lispified
in the way of thinking by that time, we might not be able to switch over
to or understand this new and more powerfull programming paradigm, and the
world will yet another time go into a state of craziness. A state that
might have been avoided if the humans hadn't fixed their thoughts on lisp
as the one true way of controlling the computer and everything else of
importance.
Jon Harrop
> Please keep an open mind whist reading this post. If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
>
> if (<= n 1)
> ^ 1
> * n
> factorial (- n 1)
Why not:
defun factorial n =
if n<=1 then 1 else n*factorial(n-1)
> Still there? OK, good. I'm looking for people who are interested in
> using a lisp/scheme with Python-style indentation for lists.
If you're going to add syntax to Lisp then I'd follow maths to start with:
infix operators, precedence and associativities.
If you want to do something really cool then I'd use typeset input with a
graphical editor.
> The goal of the project is to provide this syntax as open source
> add-ons to Scheme and Lisps. I have a small collection of links and
> source code by people who have played with this idea in the past.
I think this is a good idea because it will reduce the activation barrier
required to get started with Lisp.
> There is an open-source front-end for my tiny Lisp which converts
> indented syntax into the traditional. This is available on the web
> on-line for interactive play. Hence I also have running indented code
> (See below). So far it all seems to work as you would expect,
> code=data, macros etc.
You might like to take the syntax from an existing language and convert it
into s-exprs. For example, you could use the intermediate representation
generated by the OCaml compilers. This has the advantage that you get a
pattern match compiler for free but I'm not sure how feasible it is to rip
out the static type checker.
Best of luck with the project!
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
grackle
> a) The notion that preventing "lesser" programmers from writing macros
> has benefits is the same as the idea that preventing them from writing
> functions, classes, methods, variables, etc., has benefits. It's weird,
> though, that no one seems to come up with, or defend, the latter.
I would never defend the former point of view, just take advantage of
it :-)
> Popular languages have already been developed on top of Lisp / Common
> Lisp several times. From the top of my head, at least Haskell, ML, Dylan
> and Scheme.
I think I meant something else by "popular." Hiding the parentheses
means aiming to ensnare the masses into a Lisp (shh! don't say it!)
language so that more programmers get to use *cough* Isplay *cough* on
commercial projects. Right now, I couldn't in good conscience
recommend Lisp, Haskell, or ML for most of the projects I work on
because the language would lock out my colleagues, and the code would
get thrown away and rewritten in another language as soon as I moved on
to something else. If the bulk of the code were written in, or
translatable to, a language that looked like Python, there would be no
problem.
That's why I think a "stealth" Lisp would be a great thing. But like
you said, it would have to be designed from the beginning for its
ultimate role.
-David
Pascal Costanza
> Pascal Costanza wrote:
>> a) The notion that preventing "lesser" programmers from writing macros
>> has benefits is the same as the idea that preventing them from writing
>> functions, classes, methods, variables, etc., has benefits. It's weird,
>> though, that no one seems to come up with, or defend, the latter.
>
> I would never defend the former point of view, just take advantage of
> it :-)
:)
>> Popular languages have already been developed on top of Lisp / Common
>> Lisp several times. From the top of my head, at least Haskell, ML, Dylan
>> and Scheme.
>
> I think I meant something else by "popular." Hiding the parentheses
> means aiming to ensnare the masses into a Lisp (shh! don't say it!)
> language so that more programmers get to use *cough* Isplay *cough* on
> commercial projects. Right now, I couldn't in good conscience
> recommend Lisp, Haskell, or ML for most of the projects I work on
> because the language would lock out my colleagues, and the code would
> get thrown away and rewritten in another language as soon as I moved on
> to something else.
Using Lisp for prototypes to be thrown away and rewritten in other
languages once the domain is well understood is not the worst use case.
There are, of course, better ones (like keeping the Lisp version ;), but
at least you could use Lisp for its primary strength, that is, to
explore a domain that's not well-understood yet.
> If the bulk of the code were written in, or
> translatable to, a language that looked like Python, there would be no
> problem.
>
> That's why I think a "stealth" Lisp would be a great thing. But like
> you said, it would have to be designed from the beginning for its
> ultimate role.
The "ultimate role" will probably not be achieved because once it's
popular, users will probably (demand to) change the language in ways
that are not compatible with the original end-goal.
Tayssir John Gabbour
> I am more wondering
> where this notion comes from that parentheses are in any way "scary",
> whatever that means. It rather seems to be a prejudice that,
> interestingly, typically computer scientists have, not people from
> outside the field.]
And I'm curious about the hidden assumption that ordinary computer
users don't find mainstream programming to be scary. If language
designers are out to leverage people's happy childhood memories of math
class, given the constraints of plaintext... we're in trouble.
Maybe sprinkle around the occasional ;, @ and $...
() -- scary
<> -- exciting
Stallman commented on secretaries learning Lisp:
"They used a manual someone had written which showed how to extend
Emacs, but didn't say it was a programming. So the secretaries, who
believed they couldn't do programming, weren't scared off. They read
the manual, discovered they could do useful things and they learned to
program."
Tayssir
Lars Rune Nøstdal
> bir...@tpg.com.au wrote:
>> Please keep an open mind whist reading this post. If you're not
>> interested in new syntaxes for Lisp/Scheme, please read no further.
>>
>> defun factorial (n)
>> if (<= n 1)
>> ^ 1
>> * n
>> factorial (- n 1)
>
> Why not:
>
> defun factorial n =
> if n<=1 then 1 else n*factorial(n-1)
Or what about:
double factorial(double n)
{
if(n <= 1)
return 1;
else
return n * factorial(n - 1);
}
--
Lars Rune Nøstdal
http://lars.nostdal.org/
bir...@tpg.com.au
Stefan Scholl wrote:
> In comp.lang.lisp bir...@tpg.com.au wrote:
> > Please keep an open mind whist reading this post. If you're not
> > interested in new syntaxes for Lisp/Scheme, please read no further.
>
> Nope. First you should start to tell us about your background.
> Many new Lisp users try to change the syntax. It's a kind of
> running gag in the Lisp newsgroup.
>
don't remember the gag. Must something recent.
bir...@tpg.com.au
smal...@juno.com wrote:
If you wrote code like that on my project I would probably fire you.
But you have adequately demonstrated that indentation gives you choice
over layout.
bir...@tpg.com.au
Jon Harrop wrote:
>
> You might like to take the syntax from an existing language and convert it
> into s-exprs. For example, you could use the intermediate representation
> generated by the OCaml compilers. This has the advantage that you get a
> pattern match compiler for free but I'm not sure how feasible it is to rip
> out the static type checker.
>
> Best of luck with the project!
Thanks, but no. That idea breaks some important qualities of the Lisp
approach. Namely code and data have the same, and macros. I should
mention your idea has been done many times in the past, almost every
syntactic bolt-on looses these essential features.
bir...@tpg.com.au
Lars Rune Nøstdal wrote:
> Or what about:
>
> double factorial(double n)
> {
> if(n <= 1)
> return 1;
> else
> return n * factorial(n - 1);
> }
>
No actually. How would macros and custom languages fit with that
syntax? How does adding infix help? You don't appear have thought
through your post.
bir...@tpg.com.au
No actually backquote is a symbol which denotes the backquote macro.
The Lisp reader function replaces the backquote character with a call
to backquote. See
http://clisp.cvs.sourceforge.net/clisp/clisp/src/backquote.lisp?revision=2.23&view=markup
The backquote symbol is also historically correct.
>
> > defmacro unless (test &rest rest)
> > !
> > cond
> > (not ,test) ,@rest
> >
> > Details depend on which Lisp you're using.
>
> There are way too many scary symbols in that. I suggest the following,
> for the sake of consistency:
>
> defmacro unless LEFT-PARENTHESIS test AMPERSAND-NO-SPACE rest rest RIGHT-PARENTHESIS
> BACKQUOTE
> cond
> LEFT-PARENTHESIS not COMMA-NO-SPACE test RIGHT-PARENTHESIS COMMA-AT-NO-SPACE rest
>
> Uh-oh. Now my lines are too wide for my editor. How do you deal with
> that when whitespace has syntactic meaning?
Now you are being silly. But seriously if a line becomes too long, you
can either use more indentation or use the line continuation character.
>
> Moreover, your example of unless has two pairs of parentheses. The
> following code has four. How many parentheses does it take to become
> scary?
That is up to the reader. I just wish there were more developers who
are not scarred/scared by the Lisp syntax. (sigh) Then maybe I could be
working with Lisp guys not Java guys.
bir...@tpg.com.au
Pascal Costanza wrote:
...
>
> The "ultimate role" will probably not be achieved because once it's
> popular, users will probably (demand to) change the language in ways
> that are not compatible with the original end-goal.
>
this list alone ;-).
Perhaps if this indented syntax is available we could entice some
Python programmers to upgrade to Lisp. They would be thinking "Oh,
Lisp/Scheme is just like Python but I get macros and other cool stuff".
I also think that since most decent Comp Sci courses deliver Scheme
lessons we don't have to worry about marketing. There is at least one
educator who has thought about teaching it without parens:
http://pschombe.wordpress.com/2006/04/16/lisp-without-parentheses
Jon Harrop
Yes. The conventional solution is to use quotations in a language with
syntax.
However, I don't understand why you think:
defun factorial (n)
if (<= n 1)
^ 1
* n
factorial (- n 1)
is preferable to:
defun factorial n =
if n<=1 then 1 else n*factorial(n-1)
After all, both approaches are replacing superfluous parentheses with
syntax, keywords in my case and whitespace in your case. Given that the
latter is more concise, I'd have thought it preferable. Indeed, I thought
this was why consensus in modern language design is to use whitespace-
agnostic syntax.
Jon Harrop
> I also think that since most decent Comp Sci courses deliver Scheme
> lessons we don't have to worry about marketing.
We were taught SML and they now teach Java. I thought Lisp and Scheme were
only prevalent in the US...
Ken Tilton
No way. Ilias was a notable, years back. He named us The Savages of
Comp.lang.lisp. Felt we were not so bad after GvR Himself ripped him a
new one when he moved on to Python.
Ari Johnson
> If you wrote code like that on my project I would probably fire you.
> But you have adequately demonstrated that indentation gives you choice
> over layout.
Indentation gives you choice over layout? First off, indentation
isn't what gives it to you. S-expressions in no way hold you back
from laying out your code however you feel like. Second, and more
importantly, indentation *restricts* your layout. Once you make
indentation syntactically significant, you are limited in how you can
format and lay out your code. Try again.
bir...@tpg.com.au
> After all, both approaches are replacing superfluous parentheses with
> syntax, keywords in my case and whitespace in your case. Given that the
> latter is more concise, I'd have thought it preferable. Indeed, I thought
> this was why consensus in modern language design is to use whitespace-
> agnostic syntax.
>
I'm sorry you don't get it. The magic of Lisp is the simplicity of it's
prefix-based parser. Think of it as a more structured version of m4 or
GPM.
However if you want to be consise (aka cryptic) write:
defun factorial (n)
if (<= n 1) 1 (* n (factorial (- n 1))
if you like 'keywords' you can roll your own:
setq then progn
setq else progn
defun factorial (n)
if (<= n 1)
then 1
else
* n (factorial (- n 1)
Because this is Lisp, you define your own grammar.
In which forum was that consensus reached? It's a furphy, there is no
such consensus.
Ari Johnson
You are citing one implementation of CL as being authoritative. Show
me in the Common Lisp specification where the symbol BACKQUOTE is
specified. Also, what does "historically correct" mean? Do you have
anything to back up this claim or is it just a meaningless statement
meant to summarily dismiss a view contrary to your own?
>
>>
>> > defmacro unless (test &rest rest)
>> > !
>> > cond
>> > (not ,test) ,@rest
>> >
>> > Details depend on which Lisp you're using.
>>
>> There are way too many scary symbols in that. I suggest the following,
>> for the sake of consistency:
>>
>> defmacro unless LEFT-PARENTHESIS test AMPERSAND-NO-SPACE rest rest RIGHT-PARENTHESIS
>> BACKQUOTE
>> cond
>> LEFT-PARENTHESIS not COMMA-NO-SPACE test RIGHT-PARENTHESIS COMMA-AT-NO-SPACE rest
>>
>> Uh-oh. Now my lines are too wide for my editor. How do you deal with
>> that when whitespace has syntactic meaning?
>
> Now you are being silly. But seriously if a line becomes too long, you
> can either use more indentation or use the line continuation character.
No, I'm not being silly. I am asking you why some parentheses are
scary but others are not and other symbols are not. Also, the line
continuation character would be what? Another symbol? Why are you
afraid of parentheses and the backquote character but not other
symbols?
According to you:
Scary symbols: ( ) `
Safe symbols: & , ,@
Sometimes safe: ( )
>> Moreover, your example of unless has two pairs of parentheses. The
>> following code has four. How many parentheses does it take to become
>> scary?
>
> That is up to the reader. I just wish there were more developers who
> are not scarred/scared by the Lisp syntax. (sigh) Then maybe I could be
> working with Lisp guys not Java guys.
No, it's up to the language. Lisp as a language has traditionally and
continuously decided that no number of parentheses is scary when
compared with hard-to-remember precedence rules and other syntax that
would otherwise replace (some of) the parentheses.
bir...@tpg.com.au
On Nov 9, 1:41 pm, Ari Johnson <iamthe...@gmail.com> wrote:
> bir...@tpg.com.au writes:
> > If you wrote code like that on my project I would probably fire you.
> > But you have adequately demonstrated that indentation gives you choice
> > over layout
>.Indentation gives you choice over layout? First off, indentation
> isn't what gives it to you. S-expressions in no way hold you back
> from laying out your code however you feel like. Second, and more
> importantly, indentation *restricts* your layout. Once you make
> indentation syntactically significant, you are limited in how you can
> format and lay out your code. Try again.
OK.
I mean you can choose to either indent or use parens as you wish. Your
example uses indents to the extreme. The other extreme is
DEFUN THREAT (I J A B) (OR (= I A) (= J B) (= (- I J) (- A B)) (= (+ I
J) (+ A B)))
it's up to you how you want it to look.
grackle
> That is up to the reader. I just wish there were more developers who
> are not scarred/scared by the Lisp syntax. (sigh) Then maybe I could be
> working with Lisp guys not Java guys.
They are scared off by the unfamiliarity, and rightly so in most cases.
Lisp is deeply unfamiliar and alien to most experienced programmers on
the planet today, not only in its language but in its culture, tools,
and habits of work. Familiar tools do not have obvious analogues;
familiar modes of work are not obviously supported. People who are not
enticed by unfamiliarity will never make it through the slow and
frustrating process of learning Lisp. When people leave school and
enter industry, they enter a world where the ease and transparency of a
tool is a good indication of its quality. Ninety-nine percent of the
stuff that is confusing is confusing because it is crap. This
principle becomes an instinct. (Some people seem to be born with this
instinct, but that's another issue.) So learning Lisp, for them, would
be a long ordeal of pessimism and anger at being committed to a path
that feels deeply wrong.
To put it briefly, it is not necessarily a bad thing that people are
scared away by the parentheses, because those people would not have a
good experience with Lisp anyway. It only makes sense to get rid of
the parentheses if the underlying tools and culture are just as
familiar as the syntax.
-David
Jon Harrop
> I'm sorry you don't get it. The magic of Lisp is the simplicity of it's
> prefix-based parser.
I think this is the difference. I thought the magic of Lisp was in its lack
of syntax, including prefix operators. You're adding syntax by adding
meaning to whitespace. So how is that different from adding syntax by
adopting a whole syntax from another language?
Ari Johnson
> On Nov 9, 1:41 pm, Ari Johnson <iamthe...@gmail.com> wrote:
>> bir...@tpg.com.au writes:
>> > If you wrote code like that on my project I would probably fire you.
>> > But you have adequately demonstrated that indentation gives you choice
>> > over layout
>>.Indentation gives you choice over layout? First off, indentation
>> isn't what gives it to you. S-expressions in no way hold you back
>> from laying out your code however you feel like. Second, and more
>> importantly, indentation *restricts* your layout. Once you make
>> indentation syntactically significant, you are limited in how you can
>> format and lay out your code. Try again.
>
> OK.
>
> I mean you can choose to either indent or use parens as you wish. Your
> example uses indents to the extreme. The other extreme is
Whose example? I think you have me confused for someone else.
> DEFUN THREAT (I J A B) (OR (= I A) (= J B) (= (- I J) (- A B)) (= (+ I
> J) (+ A B)))
>
> it's up to you how you want it to look.
What's wrong with it looking like Lisp?
Lars Rune Nøstdal
..hehe.. ok, this then:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (1- n)))))
Pascal Bourguignon
1- using long long int would be better than using double.
2- in anycase, I write it as:
double factorial(double n)
{
if(n<=1){
return(1);
}else{
return(n*factorial(n-1));
}
}
because it let me ignore the fact that return is not a function (I
use the same syntax both for function calls and special operators
such as return, sizeof, etc.
I add parentheses around all operators too, because I have better
use of my neurons than remembering the 36 priority levels of C
operators.
And the additionnal braces ease the editing of the syntactic tree;
for example, I can add lines _mindlessly_, that is _flawlessly_, in
the branches:
double factorial(double n)
{
if(n<=1){
printf("Base case -> 1\n");
return(1);
}else{
printf("Complex case -> n=%g\n",n);
return(n*factorial(n-1));
}
}
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (1- n)))))
Conclusion: there are more parentheses in C than in lisp:
(){(){()}{(())}}
(()(()((()))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Victor Kryukov
> And the additionnal braces ease the editing of the syntactic tree;
> for example, I can add lines _mindlessly_, that is _flawlessly_, in
> the branches:
>
> double factorial(double n)
> {
> if(n<=1){
> printf("Base case -> 1\n");
> return(1);
> }else{
> printf("Complex case -> n=%g\n",n);
> return(n*factorial(n-1));
> }
> }
>
>
> (defun factorial (n)
> (if (<= n 1)
> 1
> (* n (factorial (1- n)))))
>
> Conclusion: there are more parentheses in C than in lisp:
>
> (){(){()}{(())}}
> (()(()((()))))
Hey, Pascal - is it fair? To be able "to add lines _mindlessly_,
that is _flawlessy_", in Lisp version, you should probably envelope each if
branch with progn, which would add 4 more parentheses for Lisp version
*sigh*. I agree that it looks ugly, and I would never use that in real
life (I would prefer either cond or if*[1]), but that makes your
direct comparison more accurate IMHO.
(defun factorial (n)
(if (<= n 1)
(progn
(format t "Base case -> 1~%") ; that line was added later
1
)
(progn
(* n (factorial (1- n)))
(format t "Complex case -> n=~A~%" n) ; that line was added later
)))
Regards,
Victor.
[1] I found if* a useful macro, and started using it in my
code. However, I have a feeling that c.l.l doesn't like it. Can
somebody please point me to a place summarizing pros and cons of if*?
I fail to see why it's worser then, say, loop, which also introduces
it's own internal syntax. BTW - I'm not going to start another flame.
Pascal Bourguignon
> Pascal Bourguignon <p...@informatimago.com> writes:
>> Conclusion: there are more parentheses in C than in lisp:
>>
>> (){(){()}{(())}}
>> (()(()((()))))
>
> Hey, Pascal - is it fair? To be able "to add lines _mindlessly_,
> that is _flawlessy_", in Lisp version, you should probably envelope each if
> branch with progn, which would add 4 more parentheses for Lisp version
> *sigh*.
Oops, you're right, I've been unfair on this point.
The syntax of Modula-2 is the best in this respect:
IF condition THEN
statement...
ELSE
statement...
END;
No parenthesis, and you can have any number of statements ;-)
> I agree that it looks ugly, and I would never use that in real
> life (I would prefer either cond or if*[1]), but that makes your
> direct comparison more accurate IMHO.
>
> (defun factorial (n)
> (if (<= n 1)
> (progn
> (format t "Base case -> 1~%") ; that line was added later
> 1
> )
> (progn
> (* n (factorial (1- n)))
> (format t "Complex case -> n=~A~%" n) ; that line was added later
> )))
>
> Regards,
> Victor.
>
> [1] I found if* a useful macro, and started using it in my
> code. However, I have a feeling that c.l.l doesn't like it. Can
> somebody please point me to a place summarizing pros and cons of if*?
> I fail to see why it's worser then, say, loop, which also introduces
> it's own internal syntax. BTW - I'm not going to start another flame.
Compared with a palette of IF WHEN UNLESS COND, vs. IF*, I find that
the code that use IF* is more verbose, uses more space than the
equivalent code using CL operators. And of course, it's easier to
implement editor support to manipulate parenthesized branches in IF or
COND than in IF*.
bir...@tpg.com.au
Lars Rune Nøstdal wrote:
>
> ..hehe.. ok, this then:
>
>
> (defun factorial (n)
> (if (<= n 1)
> 1
> (* n (factorial (1- n)))))
>
Phew! You really had me worried for a moment there.
Rob Warnock
+---------------
| I think this might end up happening some day if someone creates a
| popular language like Python or Ruby on top of Lisp. As long as the
| S-expressions are clearly optional and mostly kept out of sight, they
| wouldn't be a barrier to adoption, but in the end everyone with any ego
| or ambition would end up using them.
+---------------
That's essentially what happened with my P'Lite Scheme[1], which
had a syntax similar to Tcl (with a little ML flavor thrown in for
some constructs), and to a lesser extent with OPFR[2]. Both were
*great* for non-Lisper use at an interactive REPL (which the users
treated as a "command line" interface, much like Tcl), especially
when lots of application-specific functions were provided in the
running image so that few subexpressions needed to be typed. But
when doing serious *programming* the irregular syntax just got in
the way.
So I still sometimes use OPFR for programs that need REPLs\\\\\...
uh... command-line interfaces for canned functions while still
providing complex subexpressions [full Common Lisp!] for power
users. But I've pretty much given up on P'Lite Scheme [and never
even bothered with building a P'Lite Lisp].
-Rob
[1] See my previous postings on "Parentheses-Lite Scheme" (P'Lite):
plite> def fact = fn x in \
if x < 2 then 1 else x * [fact [1- x]];
plite> fact 5
120
plite>
[2] See my previous postings on "Outer-Parentheses-Free REPL" (OPFR):
opfr> defun fact (x) (if (< x 2) x (* x (fact (1- x))))
FACT
opfr> fact 5
120
opfr> expt 2 100
1267650600228229401496703205376
opfr> deflex foo 12
FOO
opfr> incf foo 5
17
opfr> foo
17
opfr>
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Victor Kryukov
> Victor Kryukov <victor.kr...@gmail.com> writes:
>
>> [1] I found if* a useful macro, and started using it in my
>> code. However, I have a feeling that c.l.l doesn't like it. Can
>> somebody please point me to a place summarizing pros and cons of if*?
>> I fail to see why it's worser then, say, loop, which also introduces
>> it's own internal syntax. BTW - I'm not going to start another flame.
>
> Compared with a palette of IF WHEN UNLESS COND, vs. IF*, I find that
> the code that use IF* is more verbose, uses more space than the
> equivalent code using CL operators. And of course, it's easier to
> implement editor support to manipulate parenthesized branches in IF or
> COND than in IF*.
Right, I see the point here. On the other hand, you can always easily
extend if* without need for progn or other grouping, exactly as in your
Modula-2 example. The other thing is that if your editor support
syntax highlighting (we're all using Emacs, right?) it's somewhat
easier to _visually_ distinguish clauses - they are separated by
'then' or 'else' or 'elseif', which could be highlighted.
Victor.
Duane Rettig
Perhaps it would be more understandable if you took "gag" as a verb
rather than as a noun.
One of the early lisps we "gagged" on was Dylan, whose stated goals
included the idea of bringing Lisp to the rest of the world by
changing its syntax. We all took a serious look at it; Franz even
considered buying it from Apple when they were divesting in mid-90s.
But at that time, they still had had no macros, and they had already
removed the sexpr reader from the language, rather than adding the new
syntax as an alternative. So we declined, because we felt that they
had thrown out the fundamental ability of Lisp to add syntax for
domain-specific problems, due to the addition of syntax that was
likely to get in the way of domain-specific problems. Thus, where
Lisp is a language-building language, Dylan was moving away from that.
I see nothing wrong with defining any kind of syntax you want. One of
my early projects in Lisp (it happened to be Franz Lisp) which I did
at a previous company was an English grammar parser. The syntax there
is completely different than any other programming langauage, and it
was gratifying to see how easy it was to add the necessary syntax
(most of it was contextual, but at least none of the programming
language's syntax got in the way of dealing with the English syntax).
"The student is not greater than his teacher", and the language is not
greater than its concept language. If you want to create a
domain-specific language that is greater than Lisp, then you must
ensure that it retains the ability that Lisp posesses, namely, the
ability to create new domain-specific languages, without its own
syntax getting in the way. Many people have come into the Lisp world
and have created their own language, based on Lisp, and they say "Here
it is! The language that is better than Lisp!" and Lispers look at
them and say "So what? You've created yet another domain-specific
language, which we've all been doing for years. But why should I use
your domain-specific language, when I can just use Lisp?"
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Rafal Strzalinski
> Hi,
>
> Please keep an open mind whist reading this post. If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
>
>
> using a lisp/scheme with Python-style indentation for lists.
If you don't like parentheses. It's possible to use other Unicode white
space charaters in place of parentheses :-). Code looks similar to
Yours, but parser is trivial.
defun factorial n
if <= n 1
1
* n
factorial - n 1
format t "fact(4) = ~A ~%" factorial 4
Full source code:
http://common-lisp.net/~rstrzalinski/whitespace.lisp
Tested under SBCL with UTF-8 locales enabled (LANG=pl_PL.UTF-8).
--
Best regards,
Rafal Strzalinski (nabla)
http://rafal.strzalinski.pl
JShr...@gmail.com
> with Python-style indentation for lists.
Apparently you're going to have to look elsewhere; one might farily say
that most of us love our parentheses, and with much good reason!
Perhaps you'd have more success looking for people on c.l.python who
are interested in using a python with prefix notation and
Lisp/scheme-style semantics. (Or maybe they already call that Ruby? :-)
Kumar
syntax.
However I was in a position to need to use the power of lisp in
an environment with people who will use it only occasionally
and are not programmers in the first place. (Lisp is great as a
general data format, btw) The EzScheme approach was an experiment
to see if they can be saved from the parentheses.
Strangely enough, because there are good editors available for it, such
as
DrScheme, they didn't want the alternative indentation based
syntax! They still get confused now and then, but get better and better
at it. For me, I've ceased to think about the syntax ... completely.
I know exactly what I'm doing and I'm perfectly happy with DrScheme's
wonderful editing facilities and syntax checker.
-Srikumar
Stefan Scholl wrote:
> In comp.lang.lisp bir...@tpg.com.au wrote:
> > Please keep an open mind whist reading this post. If you're not
> > interested in new syntaxes for Lisp/Scheme, please read no further.
>
> Nope. First you should start to tell us about your background.
> Many new Lisp users try to change the syntax. It's a kind of
> running gag in the Lisp newsgroup.
>
> Then you can acknowledge that you have read
> http://www.gigamonkeys.com/book/syntax-and-semantics.html
>
> "In other words, the people who have actually used Lisp
> over the past 45 years have liked the syntax and have
> found that it makes the language more powerful. In the
> next few chapters, you'll begin to see why."
>
>
> --
> Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
ana...@earthlink.net
> ana...@earthlink.net wrote:
> > Rob Thorpe wrote:
> > > Pascal Costanza wrote:
> > > > Why would a notation without parentheses be more appropriate for
> > > > "non-programmers" than one with?
> > >
> > > The normal meaning of parentheses in the english language is to denote
> > > a clause in a sentence that states something separate from the rest of
> > > the sentence and less important. Lisp uses the parenthesis to mean
> > > something altogether different and something all of it's own.
> > > Parentheses still mean separation, but separation in a much more
> > > rigourous way to normal parentheses and are a form of separation used
> > > for almost every element of the language, not just a bit of it like
> > > english. Plus what is inside them isn't necessarily less important.
> >
> > All programming languages that use parentheses for grouping work
> > that way.
> >
> > The only difference is that other programming languages have other
> > grouping rules as well. Lisp just has parentheses.
>
> Yes. Other languages use parentheses for something closer to their
> mathematical use though. But it's confusing any way.
How is it that other languages parentheses are not confusing and Lisp's
are confusing, even though both use parentheses in exactly the same
way?
Ken Tilton
Except that Lisp uses them in such a way as to eliminate almost all
other syntax.
Pascal Costanza
There are at least two more differences that seem to be confusing:
(f x y z) vs. f(x, y, z) or even f(x y z)
(+ 1 2) vs. (1 + 2) vs. 1 + 2
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/
dus...@gmail.com
bir...@tpg.com.au wrote:
> Hi,
>
> Please keep an open mind whist reading this post. If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
>
> if (<= n 1)
> ^ 1
> * n
> factorial (- n 1)
>
> using a lisp/scheme with Python-style indentation for lists.
>
> add-ons to Scheme and Lisps. I have a small collection of links and
> source code by people who have played with this idea in the past.
>
> There is an open-source front-end for my tiny Lisp which converts
> indented syntax into the traditional. This is available on the web
> on-line for interactive play. Hence I also have running indented code
> (See below). So far it all seems to work as you would expect,
> code=data, macros etc.
>
> I would like to hook up with folk who have an open mind and can provide
> feedback, find issues, make comments, write code samples, provide tests
> or whatever.
>
> Send an email to me (rot13 "ove...@gct.pbz.nh") and I'll forward the
> links to the project site.
>
> Cheers
> Bill Birch
>
> #### Eight Queens
> #### Taken from "Lisp" by Winston & Horn 2nd edition
> #### Problem 11-9
> ####
>
> DEFUN QUEEN (SIZE) (QUEEN-AUX NIL 0 SIZE)
>
> DEFUN QUEEN-AUX (BOARD N SIZE)
> COND
> (= N SIZE)
> BOARD-PRINT (REVERSE BOARD)
> else
> QUEEN-SUB BOARD N 0 SIZE
>
> DEFUN QUEEN-SUB (BOARD N M SIZE)
> COND
> (= M SIZE)
> else
> COND
> (CONFLICT N M BOARD)
> else
> QUEEN-AUX (CONS (LIST N M) BOARD) (+ N 1) SIZE
> QUEEN-SUB BOARD N (+ M 1) SIZE
>
> DEFUN CONFLICT (cN cM cBOARD)
> COND
> (NULL cBOARD) NIL
> (OR (THREAT cN cM (CAAR cBOARD) (CADAR cBOARD)) (CONFLICT cN cM
> (CDR cBOARD)))
>
> DEFUN THREAT (I J A B)
> = I A
> = J B
> = (- I J) (- A B)
>
>
> BOARD-PRINT-AUX BOARD (LENGTH BOARD)
>
> DEFUN BOARD-PRINT-AUX (BOARD SIZE)
> TERPRI
> COND
> (NULL BOARD)
> else
> BOARD-PRINT-SUB (CADAR BOARD) 0 SIZE
> BOARD-PRINT-AUX (CDR BOARD) SIZE
>
> DEFUN BOARD-PRINT-SUB (COLUMN N SIZE)
> COND
> (= N SIZE)
> else
> COND
> (= COLUMN N)
> PRINC "Q"
> else
> PRINC "."
> PRINC " "
> BOARD-PRINT-SUB COLUMN (+ N 1) SIZE
It appears that your intended purpose here is to help Lisp politically,
in order to make it easier for beginners to get over the "weird" syntax
and learn to love the language. After all, most seasoned lispers aren't
going to want to give up that which they love the most!
If this is indeed the case, might I recommend that you try to
supplement your implementation with some sort of tutorial or teaching
material, in order to fully encourage newbs to join the party. It would
definitely help push this customization upon those who might actually
benefit from it. And while you're doing so, I'd recommend you call it
something other than Lisp (Prefunc or something like that), both to
satisfy the purists, and to stop from frightening any potential
converts that may be scared away by the urban legends they've heard.
Bill Atkins
Harald Hanche-Olsen
| Please don't encourage this sort of thing.
Agreed.
But please improve your original-contents-to-quoted-text ratio.
This whole thing reminds me of an article in Dr. Dobb's Journal ages
ago (meaning sometime in the early 1980s): It was an introduction to C
for Pascal programmers, and tried to be helpful by encouraging people
to include a header file containing such stuff as
#define BEGIN {
#define END }
and so forth, and then write C as if it were Pascal.
I thought it was a pretty nifty idea myself, until I wrote a small
program this way and suddenly realized how mindbogglingly stupid it
really was. A little bit like English using German word order to
speak.
--
* 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
dus...@gmail.com
I hardly think that what I posted could be misconstrued as
encouragement. Besdies, what exactly is wrong with restricting the OP's
proposal to its proper place, and letting him figure out on his own
what's wrong it, and why it won't work. I've always found that self
teaching is a lot more effective than being berated with orders.
Entertaining as the latter may be.
JShr...@gmail.com
wrote:
> >>>>The normal meaning of parentheses in the english language is to denote
> >>>>a clause in a sentence that states something separate from the rest of
> >>>>the sentence and less important. Lisp uses the parenthesis to mean
> >>>>something altogether different and something all of it's own.
> >>>>Parentheses still mean separation, but separation in a much more
> >>>>rigourous way to normal parentheses and are a form of separation used
> >>>>for almost every element of the language, not just a bit of it like
> >>>>english. Plus what is inside them isn't necessarily less important.
> >>>
> >>>All programming languages that use parentheses for grouping work
> >>>that way.
> >>>
> >>>The only difference is that other programming languages have other
> >>>grouping rules as well. Lisp just has parentheses.
> >>
> >>Yes. Other languages use parentheses for something closer to their
> >>mathematical use though. But it's confusing any way.
> >
> > How is it that other languages parentheses are not confusing and Lisp's
> > are confusing, even though both use parentheses in exactly the same
> > way?
>
> Except that Lisp uses them in such a way as to eliminate almost all
> other syntax.
Just for the record, let me point out that Lisp uses parens in exactly
one consistent way, whereas all of these other notations are
inconsistent. English uses them to mean: This is a clause that you can
read-around (but which you might be interested in if you want the
details). But this is not a formal rule (as one might expect with a
human language in real use). One might naively expect math to be
better, but it's far worse. (It is, of course, also a human language in
real use, so this shouldn't be surprising either.)
Consider:
j(j+1) means: j^2 + j
whereas:
exp(j+1) means: e^(j+1), not: exp^2 +exp (which is meaningless unless
exp is a variable)
If you don't know all the mathematical functions (etc) already, you
can't read math. You can read Lisp w/o knowing all the functions of
functions. (Macros aside, which break this, but then that's their
explicit job!) I won't even get into the million other dumb
mathematical notations, some involving parens, many even dumbed
involving other stupid syntax. [Just wait until you see Quantum
Mechanics, I don't even know what-all competely wacko far flung
mathematical fields have their own wacko notations! :-]
Understand please that I'm not accusing math of being somehow wrong. It
works great for this who are inside it, and already know, for example,
that exp is a function, not a variable. But trying to blame Lisp being
wrong or bad or inconsistent on either English or Math being the gold
standard is just plain crazy. (I realize that you guys aren't
personally doing this. You're just discussing this theory, as am I.)
Jon Harrop
Kumar
a stroke of genius to think of function composition as a form of
"multiplication" and have that reflected in the notation. The
difference between the two cases you mention is that in stating that
j(j+1) is j^2+j, you are exercising the distributinve property of the
multiplication operator "j*". Of course, not all operators distribute
over addition and hence exp(j+1) is not exp(j)+exp(1). OTOH, it is
exp(j)*exp(1). In fact, functional languages were pretty much born out
of this "operator algebra" extended to generalized sets of objects.
The difference between lisp parentheses and normal parentheses in other
languages is the following - in most other languages, (x), ((x)),
(((x))) etc. mean the same thing whereas in lisp they are completely
different expressions worlds apart in meaning. i.e. Lisp breaks the
convention of using redundant parentheses for grouping.
Pascal Bourguignon
> The difference between lisp parentheses and normal parentheses in other
> languages is the following - in most other languages, (x), ((x)),
> (((x))) etc. mean the same thing whereas in lisp they are completely
> different expressions worlds apart in meaning. i.e. Lisp breaks the
> convention of using redundant parentheses for grouping.
But I fail to see a problem here. True, some newbies don't get it (I
assume they are inattentive), but this is something that's explained
in the first paragraphs of any lisp tutorial.
Well, perhaps we should write a "lisp for the dummies" tutorial that
would be even more explicit.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
grackle
> You can read Lisp w/o knowing all the functions of
> functions. (Macros aside, which break this, but then that's their
> explicit job!)
That's a big exception! Lisp code without macros would read like the
Principia Mathematica, unless you turned the control macros into
special forms. On the other hand, if you allow macros, then you *must*
recognize all the macros used, or you may draw wildly incorrect
conclusions about the code.
> I won't even get into the million other dumb
> mathematical notations, some involving parens, many even dumbed
> involving other stupid syntax. [Just wait until you see Quantum
> Mechanics, I don't even know what-all competely wacko far flung
> mathematical fields have their own wacko notations! :-]
Special-purpose mathematical notations are just like macros and are
used for the same purpose. It's only confusing if you can't find the
corresponding defmacro: "Let ... denote ...." or "We will use ... to
denote ...." Sometimes the macros are defined in a perfunctory manner
if they are assumed to be part of the reader's mathematical culture.
> But trying to blame Lisp being
> wrong or bad or inconsistent on either English or Math being the gold
> standard is just plain crazy.
Agreed. Neither English nor math has to face up to the basic problem
of computer programming, which is to be strong enough for a man, but pH
balanced for a woman. No, I mean,
1) expressive enough for humans
2) precise enough to direct the operation of a computer
3) able to be precisely understood by humans
Computer languages generally succeed at 1) and 3) in inverse
proportion. 3) has been basically abandoned as a goal for Joe Sixpack
software developer, who is supposed to consult a nearby language guru
when his fuzzy, intuitive understanding proves insufficient. That is
one reason why S-expressions are undervalued -- they contribute to a
precise understanding, while complex syntax helps with the fuzzy
pattern-matching that programmers tend to use instead.
-David
Anton van Straaten
> "Kumar" <sriku...@gmail.com> writes:
>
>>The difference between lisp parentheses and normal parentheses in other
>>languages is the following - in most other languages, (x), ((x)),
>>(((x))) etc. mean the same thing whereas in lisp they are completely
>>different expressions worlds apart in meaning. i.e. Lisp breaks the
>>convention of using redundant parentheses for grouping.
>
>
> But I fail to see a problem here. True, some newbies don't get it (I
> assume they are inattentive), but this is something that's explained
> in the first paragraphs of any lisp tutorial.
>
> Well, perhaps we should write a "lisp for the dummies" tutorial that
> would be even more explicit.
If only there were a "Public Relations for Dummies" book that was
equally explicit...
numeromancer
bir...@tpg.com.au wrote:
> Ari Johnson wrote:
>
> >
> > What do macros look like? Write up a few good macros here to
> > demonstrate the usefulness of your syntax.
>
> A good question.
>
> defmacro if (test success-result &optional failure-result)
> backquote
> cond
> ,test ,success-result
> t ,failure-result
>
>
> defmacro when (test &rest body)
> backquote
> cond
> ,test ,@body
>
> A different symbol can be used for backquote to save typing
>
> setq ! backquote
>
> defmacro unless (test &rest rest)
> !
> cond
> (not ,test) ,@rest
>
> Details depend on which Lisp you're using.
Why not
defmacro unless (test &rest rest)
> backquote
> > cond
> > > > not
> > > > > unquote
> > > > > > test
> > > > unquote-splicing
> > > > > rest
I have some bad old parenthetic lisp code which would make coding like
this as fun as drunken monkeys.
Tim S.
Michel Salim
grackle wrote:
> I think a Python-like syntax for Lisp would make make certain software
> engineering types cream their pants, because it would create a
> heirarchy of programmers, somewhat similar to Fred Brooks' roles but in
> an even more corporate-friendly form. The peons would work by default
> in the Python syntax, and if that prevents them from writing macros, so
> much the better. They would be supported and directed by Lisp wizards
> who customized the language for the application being developed.
>
> I think this might end up happening some day if someone creates a
> popular language like Python or Ruby on top of Lisp. As long as the
> S-expressions are clearly optional and mostly kept out of sight, they
> wouldn't be a barrier to adoption, but in the end everyone with any ego
> or ambition would end up using them.
>
Haskell has Python-like indentation rules too, for its let and do
constructs; indented expressions can be rewritten using semicolon as
the separator. Which makes me wonder why *Python* does not make
indentation optional. It would certainly be a quick fix to the
limitation of their lambda expression.
- Michel
JShr...@gmail.com
> > mathematical notations, some involving parens,
> Special-purpose mathematical notations are just like macros and are
> used for the same purpose. It's only confusing if you can't find the
> corresponding defmacro: "Let ... denote ...." or "We will use ... to
> denote ...."
I mostly agree, but it's not quite that simple. There are many
assumptions about the human reader's ability to understand what's
intended. (This was the point of my exp(j+1) example.) Also, the rules
of interpretation are often specific to the local context (sort of like
a macrolet). There are many examples of this that I find confusing
while trying to learn a new mathematical notion. One example that has
alway irked me is the >sometimes< leaving off of "(x)" in diffeqs, so
that you are expected to read y(x)=y'... as: y(x)=y'(x)... -- I never
understood why one would leave the "(x)" off >sometimes< within the
same equation. Another is the "invisible sums" notation (attributed to
Einstein) where a(i,j) is >in the appropriate context< read as
sum(i,sum(j,a(i,j))) Okay, so it saves writing a bunch of sum signs,
but man is it confusing when one means the sum and when one doesn't!
So, I agree that mathematical notation serves its purpose, but as a
student of somewhat advanced mathematics, I find it very confusing.
Now, of course, this is, in a sense, what we're talking about here. Of
course, "as a student" I would be expected not to fully understand it
yet, and be somewhat confused [and I'm okay with that in my math
readings even if it makes me grind my teeth on occasion], but this is
exactly the situation in which one needs to strive for simplicity,
clarity, and consistency ... and is, to my mind, where Lisp shines over
other languages: In Lisp (sans macros -- which, I agree with you, is a
major exception!) all you need to do is balance parens and know prefix
notation, and Bob's Your Uncle ... and there really are only a few
macros that you need to know in order to do some fairly rich stuff:
defun, quote, cond [which you could do with AND or OR if you wanted
to], um... that's about all you need to write nearly complete AI
applications! (Albeit somewhat clumsily.)
Erik Max Francis
> I mostly agree, but it's not quite that simple. There are many
> assumptions about the human reader's ability to understand what's
> intended. (This was the point of my exp(j+1) example.) Also, the rules
> of interpretation are often specific to the local context (sort of like
> a macrolet). There are many examples of this that I find confusing
> while trying to learn a new mathematical notion. One example that has
> alway irked me is the >sometimes< leaving off of "(x)" in diffeqs, so
> that you are expected to read y(x)=y'... as: y(x)=y'(x)... -- I never
> understood why one would leave the "(x)" off >sometimes< within the
> same equation.
Because usually it's implied. This is true throughout mathematics, not
just differential equations. You use the parentheses to establish or
emphasize that f(x) is a function, but f is still the name of the
function; leaving it off has no distinct meaning, so it's unambiguous.
What you're writing would be usually be written dy/dx = y or dy' = y,
with no (x) notation at all.
> Another is the "invisible sums" notation (attributed to
> Einstein) where a(i,j) is >in the appropriate context< read as
> sum(i,sum(j,a(i,j))) Okay, so it saves writing a bunch of sum signs,
> but man is it confusing when one means the sum and when one doesn't!
Well, what you wrote is confusing, but that's because you're not getting
the Einstein summation notation right :-). The convention is when a
product is mentioned with subscripts in common, then it's assumed there
is a summation on those common subscripts. A lone a_i,j wouldn't
qualify. But something like u_i v_i would; that implies sum_i (u_i v_i).
That still might also be confusing when used with other notations, but
that's why it's not -- if someone's using Einstein summation notation
they make it very clear up front. It's not mixed in and out with other
notations.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
Man is a hating rather than a loving animal.
-- Rebecca West
Kumar
paren syntax is that the tendency seems to be to go from hate/scared to
love instead of maybe dont-care to love.
As Jeff Raskin puts it, "intuitive equals familiar". Seen in that
light, when some lisp newbies declare that the paren syntax is
"unintuitive". This is what they exactly mean - "its unfamiliar". The
domain that establishes that familiarity in the first place is
mathematical notation.
Lars Brinkhoff
> Popular languages have already been developed on top of Lisp / Common
> Lisp several times. From the top of my head, at least Haskell, ML,
> Dylan and Scheme.
JavaScript?
John Thingstad
wrote:
Seems so.
http://lxr.mozilla.org/mozilla/source/js2/semantics/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
JShr...@gmail.com
> > Einstein) where a(i,j) is >in the appropriate context< read as
> > sum(i,sum(j,a(i,j))) Okay, so it saves writing a bunch of sum signs,
> > but man is it confusing when one means the sum and when one doesn't!
>
> Well, what you wrote is confusing, but that's because you're not getting
> the Einstein summation notation right :-). The convention is when a
> product is mentioned with subscripts in common, then it's assumed there
> is a summation on those common subscripts. A lone a_i,j wouldn't
> qualify. But something like u_i v_i would; that implies sum_i (u_i v_i).
Oops. Yes, you're right; Bad example on my part.
> That still might also be confusing when used with other notations, but
> that's why it's not -- if someone's using Einstein summation notation
> they make it very clear up front. It's not mixed in and out with other
> notations.
QED! (so to speak! ;-)
Ray Dillinger
> Hi,
>
> Please keep an open mind whist reading this post. If you're not
> interested in new syntaxes for Lisp/Scheme, please read no further.
>
> defun factorial (n)
> if (<= n 1)
> ^ 1
> * n
> factorial (- n 1)
>
> Still there? OK, good. I'm looking for people who are interested in
> using a lisp/scheme with Python-style indentation for lists.
>
http://srfi.schemers.org/srfi-49/mail-archive/msg00010.html
I don't feel like I need to repeat myself.
Bear
Ray Dillinger
> bir...@tpg.com.au wrote:
>> Stefan Scholl wrote:
>>> Nope. First you should start to tell us about your background.
>>> Many new Lisp users try to change the syntax. It's a kind of
>>> running gag in the Lisp newsgroup.
>> Funny, I've been using Lisp since 1986 and this list since 1989 and I
>> don't remember the gag. Must something recent.
> No way. Ilias was a notable, years back. He named us The Savages of
> Comp.lang.lisp. Felt we were not so bad after GvR Himself ripped him a
> new one when he moved on to Python.
On the Scheme side, it was SRFI-49: a misbegotten proposal to
add indentation-sensitive syntax to scheme. The discussion
was pointed. And in some cases pointy. But it's not *just*
SRFI-49; I remember at least four different proposals to do
this, if we include the current one. All from newbies, all
with no idea how to make macros work. In some cases
accompanied by the old infix-notation Bad Idea, which is even
worse.
Bear
Ray Dillinger
> If you don't like parentheses. It's possible to use other Unicode white
> space charaters in place of parentheses :-). Code looks similar to
> Yours, but parser is trivial.
<snip>
> Full source code:
> http://common-lisp.net/~rstrzalinski/whitespace.lisp
Now you're just being petty.
'S a good laugh though.
Bear
Rob Thorpe
> bir...@tpg.com.au wrote:
> > I'm sorry you don't get it. The magic of Lisp is the simplicity of it's
> > prefix-based parser.
>
> I think this is the difference. I thought the magic of Lisp was in its lack
> of syntax, including prefix operators. You're adding syntax by adding
> meaning to whitespace. So how is that different from adding syntax by
> adopting a whole syntax from another language?
Taking the first proposal, all that's happening is that whitespace is
being used as a synonym for parentheses. The code is still a simple
tree and still looks like one. This means that macros can be applied to
it the same way they can be in Lisp.
A more complex language with more difference between the visual form
and the underlying tree would make writing macros difficult.