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.
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 ·······@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
······@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 ·······@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
> Yes, trying to decide what kind of wine will go best with you.
<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!>
········@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
--
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
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.
-Kumar
······@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.
>
> 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.
>
Kumar wrote:
> 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.
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)
On Wed, 7 Nov 2006, Kumar wrote:
> 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.
>
> -Kumar
>
> ······@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.
>>
>> 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.
>>
>
>
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)
>
>
>
Thanks, this looks very similar to ezcheme. It has the same issues ie
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".
From: Pascal Costanza
Subject: Re: Lisp and Scheme with fewer parentheses
Date:
Message-ID: <4551A0CE.3080907@p-cos.net>
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?
Pascal
> On Wed, 7 Nov 2006, Kumar wrote:
>
>> 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.
>>
>> -Kumar
>>
>> ······@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.
>>>
>>> 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.
>>>
>>
>>
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
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?
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.
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.
······@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.
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.
-David
On 8 Nov 2006 10:35:36 -0800, "grackle" <···········@gmail.com> 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.
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/
Steve Schafer wrote:
> 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
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.
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.
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/
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. 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
grackle wrote:
> 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.
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/
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.
>
My goal with this work is not popularity. I think I achieved that on
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
······@tpg.com.au wrote:
> 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...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Pascal Costanza <··@p-cos.net> writes:
> 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?
On Mon, 13 Nov 2006 16:08:05 +0100, Lars Brinkhoff <·········@nocrew.org>
wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> 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?
Seems so.
http://lxr.mozilla.org/mozilla/source/js2/semantics/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Wed, 8 Nov 2006, 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.
>
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.
grackle <···········@gmail.com> wrote:
+---------------
| 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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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
Rob Thorpe wrote:
> ······@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?
······@earthlink.net wrote:
> Rob Thorpe wrote:
>
>>······@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?
>
Except that Lisp uses them in such a way as to eliminate almost all
other syntax.
kt
--
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
Ken Tilton wrote:
>
>
> ······@earthlink.net wrote:
>> Rob Thorpe wrote:
>>
>>> ······@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?
>
> Except that Lisp uses them in such a way as to eliminate almost all
> other syntax.
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/
Some long combination of Ken Tilton Rob Thorpe and Pascal Costanza
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.)
Mathematical notation *is* entirely consistent I think. In fact, it is
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.
········@gmail.com wrote:
> Some long combination of Ken Tilton Rob Thorpe and Pascal Costanza
> 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.)
"Kumar" <··········@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.
--
__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."
Pascal Bourguignon wrote:
> "Kumar" <··········@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...
Its not a problem. Its just different. That's all. The thing with the
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.
Pascal Bourguignon wrote:
> "Kumar" <··········@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.
>
>
> --
> __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."
········@gmail.com wrote:
> 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
> > I won't even get into the million other dumb
> > 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.)
········@gmail.com wrote:
> 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 && ···@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
> > 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).
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! ;-)
From: Giorgos Keramidas
Subject: Re: Lisp and Scheme with fewer parentheses
Date:
Message-ID: <8764dik1if.fsf@kobe.laptop>
On 8 Nov 2006 03:22:16 -0800, "Rob Thorpe" <·······@realworldtech.com> wrote:
>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?
>
> 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.
If by the above you are saying that Lisp's use of parentheses confuses
people because it's quite different from the "canonical" use of
parentheses in English text, then I'm very interested to know what you
think of all the 'fancy' keywords like "class", and "interface" of Java,
the use of the '{' and '}' grouping and most especially the funny '#'
character in C... for starters. Then I may want to learn more :-)
It's unrealistic to expect the 'syntax' of a programming language to
look like the "normal", "every-day" language people use. At least, it's
unrealistic with the languages we have today.
> 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.
Exactly :)
Giorgos Keramidas wrote:
> On 8 Nov 2006 03:22:16 -0800, "Rob Thorpe" <·······@realworldtech.com> wrote:
> >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?
> >
> > 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.
>
> If by the above you are saying that Lisp's use of parentheses confuses
> people because it's quite different from the "canonical" use of
> parentheses in English text, then I'm very interested to know what you
> think of all the 'fancy' keywords like "class", and "interface" of Java,
One of the meanings of "class" is similar to type. As in "I got a 2:1
class degree" or the division of organisms into classes. The problem
with using this word is the number of other meanings it has.
Similar "interface" follows one of the meanings of interface.
> the use of the '{' and '}' grouping and most especially the funny '#'
> character in C... for starters. Then I may want to learn more :-)
Yes, they are not nice. There again {} are not seen often in english,
so creating new definitions for them does not really clash with any
expected definition.
> It's unrealistic to expect the 'syntax' of a programming language to
> look like the "normal", "every-day" language people use.
No, but it could have less gotchas than most programming languages
today have.
> At least, it's
> unrealistic with the languages we have today.
Certainly.
> > 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.
>
> Exactly :)
Computer languages go beyond human ones into another dimension, doing
this will always be difficult.
On 2006-11-08 06:22:16 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
> 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.
This is certainly true. However, discussions with well educated
non-programmers suggests to me that the reason newbies find the parens
so off-putting is that newbies make the unwarranted assumption that
they need to parse them. They are initially unaware that lisp
programmers use editors and pretty-printing (i.e., the structure of
indentation) to parse the parens for them.
In addition, remembering paren levels *is* something that lisp
programmers must do to a limited extent. For example in a (do ... form,
one has to remember which of the sub-forms come where and how many
levels of parens enclose each. Mind you, I'm not saying that this is,
*objectively* particularly difficult - on the contrary, I think it is
easier than remembering the various non-uniform syntax markers for
iteration forms in other languages. To a newbie however, the fact that
one must remember *some* of the parens contributes to the
misapprehension that a lisp programmer must parse *all* the parens. The
prospect of having to do this is so off-putting that many newbies never
get past this initial misconception and dismiss lisp out of hand.
Raffael Cavallaro wrote:
> On 2006-11-08 06:22:16 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
>
> > 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.
>
> This is certainly true. However, discussions with well educated
> non-programmers suggests to me that the reason newbies find the parens
> so off-putting is that newbies make the unwarranted assumption that
> they need to parse them. They are initially unaware that lisp
> programmers use editors and pretty-printing (i.e., the structure of
> indentation) to parse the parens for them.
>
> In addition, remembering paren levels *is* something that lisp
> programmers must do to a limited extent. For example in a (do ... form,
> one has to remember which of the sub-forms come where and how many
> levels of parens enclose each. Mind you, I'm not saying that this is,
> *objectively* particularly difficult - on the contrary, I think it is
> easier than remembering the various non-uniform syntax markers for
> iteration forms in other languages. To a newbie however, the fact that
> one must remember *some* of the parens contributes to the
> misapprehension that a lisp programmer must parse *all* the parens. The
> prospect of having to do this is so off-putting that many newbies never
> get past this initial misconception and dismiss lisp out of hand.
I think your right. I can't remember if I had to be told to use
indentation as a guide before I did, but I suspect so.
I occasionally mix myself up with parens if I write a single line with
a lot on it. That's normally a sign to break things up further though.
In general there are always problems with something where there is one
bad way to learn something and that bad way is simple. Counting parens
to understand lisp is only an example. Using many C features in C++
code would be another.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-11-08 06:22:16 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
>
>> 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.
>
> This is certainly true. However, discussions with well educated
> non-programmers suggests to me that the reason newbies find the parens
> so off-putting is that newbies make the unwarranted assumption that
> they need to parse them. They are initially unaware that lisp
> programmers use editors and pretty-printing (i.e., the structure of
> indentation) to parse the parens for them.
>
> In addition, remembering paren levels *is* something that lisp
> programmers must do to a limited extent. For example in a (do
> ... form, one has to remember which of the sub-forms come where and
> how many levels of parens enclose each.
Well that's the point, we don't count parentheses, we just know at
what level in the tree we are. Speaking of parentheses in lisp is as
silly as speaking of parentheses in your family tree!
Do you count parentheses around you and our brothers? And around your
parents and your uncles? You just need to know that you have parents
and uncles and brother, and that your parents can add a brother, etc.
Perhaps we really need to "patch" emacs to display the parse trees
more "graphically"...
> Mind you, I'm not saying that
> this is, *objectively* particularly difficult - on the contrary, I
> think it is easier than remembering the various non-uniform syntax
> markers for iteration forms in other languages. To a newbie however,
> the fact that one must remember *some* of the parens contributes to
> the misapprehension that a lisp programmer must parse *all* the
> parens. The prospect of having to do this is so off-putting that many
> newbies never get past this initial misconception and dismiss lisp out
> of hand.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
On 2006-11-15 17:11:02 -0500, Pascal Bourguignon <···@informatimago.com> said:
> Perhaps we really need to "patch" emacs to display the parse trees
> more "graphically"...
Go for it - judging by your ascii-art posts I'm sure you're up to the task.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-11-15 17:11:02 -0500, Pascal Bourguignon <···@informatimago.com> said:
>
>> Perhaps we really need to "patch" emacs to display the parse trees
>> more "graphically"...
>
> Go for it - judging by your ascii-art posts I'm sure you're up to the task.
Well, right now I won't have time to do it, so this interesting hack
is free for the taking! :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
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!)
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!"?
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
kt
--
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
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.
On Nov 8, 10:54 am, "Kjetil S. Matheussen" <··············@notam02.no>
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.
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. :)
kt
--
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
Christopher Koppler wrote:
> On Nov 8, 10:54 am, "Kjetil S. Matheussen" <··············@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.
:)
kt
--
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
From: Pascal Costanza
Subject: Re: Lisp and Scheme with fewer parentheses
Date:
Message-ID: <4551AFAF.3070505@p-cos.net>
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)."
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
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
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.
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.
Joel Wilsson wrote:
> 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
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> 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
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.
kt
--
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
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.
Kjetil S. Matheussen wrote:
>
> On Wed, 8 Nov 2006, Pascal Costanza wrote:
>
>> 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.
>
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
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> 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
Pascal Costanza <··@p-cos.net> writes:
> 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
······@tpg.com.au writes:
> 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.
>
> 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 ·······@gct.pbz.nh") and I'll forward the
> links to the project site.
>
> Cheers
> Bill Birch
What do macros look like? Write up a few good macros here to
demonstrate the usefulness of your syntax.
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.
On Nov 8, 12:42 pm, ······@tpg.com.au wrote:
> A different symbol can be used for backquote to save typing
>
> setq ! backquote
I fail to see the savetyping qualities of \#! considering there's \#`.
From: Ken Tilton
Subject: Re: Lisp and Scheme with fewer parentheses
Date:
Message-ID: <Kno4h.17$Yc2.6@newsfe11.lga>
Christopher Koppler wrote:
> On Nov 8, 12:42 pm, ······@tpg.com.au wrote:
>
>>A different symbol can be used for backquote to save typing
>>
>> setq ! backquote
>
>
> I fail to see the savetyping qualities of \#! considering there's \#`.
Which does not require the shift key.
kt
--
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
······@tpg.com.au writes:
> 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.
Sweet! This is excellent.
Lisp community! Everyone! LET'S USE THIS!
······@tpg.com.au writes:
> 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))
Ari Johnson wrote:
> ······@tpg.com.au writes:
>
> > 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?
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.
······@tpg.com.au wrote:
> 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
······@tpg.com.au writes:
> Ari Johnson wrote:
>> ······@tpg.com.au writes:
>>
>> > 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?
>
> 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.
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.
······@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.
······@tpg.com.au writes:
[...]
> 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?
[...]
······@tpg.com.au wrote:
>
> #### 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
·········@juno.com wrote:
> 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
>
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.
······@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.
On Nov 9, 1:41 pm, Ari Johnson <·········@gmail.com> wrote:
> ······@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.
······@tpg.com.au writes:
> On Nov 9, 1:41 pm, Ari Johnson <·········@gmail.com> wrote:
>> ······@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?
In comp.lang.lisp ······@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/
Stefan Scholl wrote:
> In comp.lang.lisp ······@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.
>
Funny, I've been using Lisp since 1986 and this list since 1989 and I
don't remember the gag. Must something recent.
······@tpg.com.au wrote:
> Stefan Scholl wrote:
>
>>In comp.lang.lisp ······@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.
>>
>
> 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.
kt
--
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
Ken Tilton wrote:
> ······@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
······@tpg.com.au writes:
> Stefan Scholl wrote:
>> In comp.lang.lisp ······@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.
>>
> Funny, I've been using Lisp since 1986 and this list since 1989 and I
> don't remember the gag. Must something recent.
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 ·····@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
You're right. I for one, love the consistency of the parentheses
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 ······@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/
······@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)
> 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
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.
······@tpg.com.au wrote:
> 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.
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
On Nov 9, 12:04 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> 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.
······@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?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop wrote:
> ······@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.
> 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.
Let's be clear here: Whitespace can't (without mysterious rules of
invisible interpretation) be a synonym for parentheses, for two
reasons: (1) Whitespace doesn't have a distinct open and close. Those
mysterious rules include things like: Indenting whitespace is an open
paren whereas extenting is a close, except where you're on the same
line, in which case the line turn is always a close, or something like
that. (2) Whitespace is (by definition) invisible whereas parens are
visible. These two simple principles combine to make parens THE ONE AND
ONLY CORRECT way to do syntax. Every other method is overkill or
requires mysteriousity, or is simply wrong. (Yes, I *am* god! :-)
········@gmail.com wrote:
> > 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.
>
> Let's be clear here: Whitespace can't (without mysterious rules of
> invisible interpretation) be a synonym for parentheses, for two
> reasons: (1) Whitespace doesn't have a distinct open and close. Those
> mysterious rules include things like: Indenting whitespace is an open
> paren whereas extenting is a close, except where you're on the same
> line, in which case the line turn is always a close, or something like
> that. (2) Whitespace is (by definition) invisible whereas parens are
> visible. These two simple principles combine to make parens THE ONE AND
> ONLY CORRECT way to do syntax. Every other method is overkill or
> requires mysteriousity, or is simply wrong. (Yes, I *am* god! :-)
Yes. I was thinking about SRFI-49 style use of indentation to mean
parens
It's not that mysterious, when I first saw it I found it OK to
understand.
It makes reformatting code difficult though. When you find you can put
something on one line you have to go back and reintroduce the paren -
and get it right. Similarly if you break over a line when you didn't
expect too you have to remove earlier parens.
> Yes. I was thinking about SRFI-49 style use of indentation to mean
> parens
>...
> It makes reformatting code difficult though. When you find you can put
> something on one line you have to go back and reintroduce the paren -
> and get it right. Similarly if you break over a line when you didn't
> expect too you have to remove earlier parens.
QED (again! :-)
Rob Thorpe wrote:
> 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.
Macros are certainly harder to write in OCaml because of syntax but
Mathematica seems to cope.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop wrote:
> Rob Thorpe wrote:
> > 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.
>
> Macros are certainly harder to write in OCaml because of syntax but
> Mathematica seems to cope.
What does it look like in Mathematica?
Rob Thorpe wrote:
> Jon Harrop wrote:
>> Rob Thorpe wrote:
>> > 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.
>>
>> Macros are certainly harder to write in OCaml because of syntax but
>> Mathematica seems to cope.
>
> What does it look like in Mathematica?
Everything in Mathematica is a "macro" because it is a rewrite system so
all "functions" are actually rewrite rules that map exprs to exprs whereas
functions in normal languages map values to values.
Take computing the symbolic derivative for example:
d[x_, x_] := 1
d[_Symbol | _?NumericQ, x_] := 0
d[f_ + g_, x_] := d[f, x] + d[g, x]
d[f_ g_, x_] := f d[g, x] + g d[f, x]
That doesn't seem too "hard to write". It uses infix operators in both
patterns and expressions. Perhaps symbolic maths is a special case where
syntax helps but I can't think why that would be.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop wrote:
> Rob Thorpe wrote:
> > Jon Harrop wrote:
> >> Rob Thorpe wrote:
> >> > 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.
> >>
> >> Macros are certainly harder to write in OCaml because of syntax but
> >> Mathematica seems to cope.
> >
> > What does it look like in Mathematica?
>
> Everything in Mathematica is a "macro" because it is a rewrite system so
> all "functions" are actually rewrite rules that map exprs to exprs whereas
> functions in normal languages map values to values.
>
> Take computing the symbolic derivative for example:
>
> d[x_, x_] := 1
> d[_Symbol | _?NumericQ, x_] := 0
> d[f_ + g_, x_] := d[f, x] + d[g, x]
> d[f_ g_, x_] := f d[g, x] + g d[f, x]
>
> That doesn't seem too "hard to write". It uses infix operators in both
> patterns and expressions. Perhaps symbolic maths is a special case where
> syntax helps but I can't think why that would be.
No. Can't say I understand it totally though. What does the line:-
d[_Symbol | _?NumericQ, x_] := 0
Mean?
> Perhaps symbolic maths is a special case where
> syntax helps but I can't think why that would be.
Something that only deals with the expansion side can have any syntax
you like. The above functional expansion in Mathematica can be done
with the C macro preprocessor for example (or, with difficulty, in any
language with lambdas). The problem occurs when the information given
to the macro to use is complex, for many useful macros it is. Look at
it from the other perspective, if you have the code:-
"d[f_ + g_, x_] := d[f, x] + d[g, x]
d[f_ g_, x_] := f d[g, x] + g d[f, x]"
How can you extract the information from that code to find out what it
means?
Rob Thorpe wrote:
>> d[x_, x_] := 1
>> d[_Symbol | _?NumericQ, x_] := 0
>> d[f_ + g_, x_] := d[f, x] + d[g, x]
>> d[f_ g_, x_] := f d[g, x] + g d[f, x]
>>
>> That doesn't seem too "hard to write". It uses infix operators in both
>> patterns and expressions. Perhaps symbolic maths is a special case where
>> syntax helps but I can't think why that would be.
>
> No. Can't say I understand it totally though. What does the line:-
> d[_Symbol | _?NumericQ, x_] := 0
> Mean?
Replace expressions "d[f, x]" with "0" when f is either any symbol or any
expression for which "NumericQ[f]" evaluates to "True".
The notation "pat1 | pat2" is called an or-pattern and is also found in
OCaml, F# and other languages.
The equivalent in OCaml would be:
let d f x = match f with
| Sym _ -> 0
| f when is_numeric f -> 0
...
>> Perhaps symbolic maths is a special case where
>> syntax helps but I can't think why that would be.
>
> Something that only deals with the expansion side can have any syntax
> you like. The above functional expansion in Mathematica can be done
> with the C macro preprocessor for example (or, with difficulty, in any
> language with lambdas).
The use of pattern matching has hidden the fact that my example does
decompose and reconstruct expressions.
How would you write a C macro to compute the symbolic derivative of a C
expression?
> The problem occurs when the information given
> to the macro to use is complex, for many useful macros it is. Look at
> it from the other perspective, if you have the code:-
>
> "d[f_ + g_, x_] := d[f, x] + d[g, x]
> d[f_ g_, x_] := f d[g, x] + g d[f, x]"
>
> How can you extract the information from that code to find out what it
> means?
You want the s-expr of those two rewrite rules? That is Mathematica specific
but you just do:
In[3]:= DownValues[d]
Out[3]= {HoldPattern[d[(f_) + (g_), x_]] :> d[f, x] + d[g, x],
> HoldPattern[d[(f_) (g_), x_]] :> f d[g, x] + g d[f, x]}
Note that Mathematica has pretty printed the output expressions using infix
syntax as well. You can ask it to use prefix form if you like:
In[4]:= DownValues[d] // FullForm
Out[4]//FullForm=
> List[RuleDelayed[HoldPattern[d[Plus[Pattern[f, Blank[]],
> Pattern[g, Blank[]]], Pattern[x, Blank[]]]], Plus[d[f, x], d[g,
x]]]\
> , RuleDelayed[HoldPattern[d[Times[Pattern[f, Blank[]],
> Pattern[g, Blank[]]], Pattern[x, Blank[]]]],
> Plus[Times[f, d[g, x]], Times[g, d[f, x]]]]]
Such introspection conflicts with static typing, of course.
I've just been reading some articles on how you can exploit Mathematica's
internals to get at fast data structures (particularly hash tables). I've
also been writing about how "+" can be overloaded in F# to compose exprs
and how pretty printers can be installed to print them.
It is early days yet, but with optional static typing, active patterns and
introspection, F# is an ideal language to build symbolic tools in. Maybe a
future Mathematica will be written in F#...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
From: Richard J. Fateman
Subject: Re: Lisp and Scheme with fewer parentheses / Mathematica??
Date:
Message-ID: <455A1FDF.8070901@eecs.berkeley.edu>
Jon Harrop wrote:
>
>
> Everything in Mathematica is a "macro" because it is a rewrite system so
> all "functions" are actually rewrite rules that map exprs to exprs whereas
> functions in normal languages map values to values.
1. Rule-based transformation systems such as Mathematica are not doing
macro-expansions. Macro expansions typically map "templates for
programs" into "programs". Mathematica programmers typically define
rules (though they think of them as conventional functions for the most
part). There are lots of rule-based systems. Prolog is perhaps most
prominent today, but there were lots of expert system tools designed
over the last 20 years, and before that there were languages like SNOBOL.
2. I don't know what distinction you mean to make by referring to
"normal" languages, but in Lisp as well as in Mathematica, a value can
be an arbitrary symbolic expression. Lisp is better at issues involving
scope, binding, functions, but not so much so that a typical
physicist/programmer would necessarilyu notice.
>
> Take computing the symbolic derivative for example:
>
> d[x_, x_] := 1
> d[_Symbol | _?NumericQ, x_] := 0
> d[f_ + g_, x_] := d[f, x] + d[g, x]
> d[f_ g_, x_] := f d[g, x] + g d[f, x]
>
> That doesn't seem too "hard to write". It uses infix operators in both
> patterns and expressions. Perhaps symbolic maths is a special case where
> syntax helps but I can't think why that would be.
>
3. Computer-assisted symbolic math is a special case for infix because
so many people use infix notation for non-computer-assisted symbolic
math. Unfortunately, the full scope of math notation as input syntax is
substantially missing from Mathematica, C, Python ... Compare any of
these languages to TeX. (Mathematica tries to provide for typesetting,
but mostly as output. So do other computer algebra systems like Maple,
Macsyma/Maxima, ...)
The substantial failure of infix notation outside of the realm of simple
arithmetic is often unnoticed by people who use programming languages
primarily for simple arithmetic! Pick up a symbolic logic textbook and
open it up in the middle, and see if you can figure out the syntax. It
is pretty hard because typically the infix operator " " (that is, a
space) or concatenation (that is, no space), has several meanings. In
fact, in conventional algebra, concatenation is overloaded. consider
a(b+c) vs. f(b+c) vs cos(b+c). What operation is implicit just to
the left of the (? How many meanings are there for "." in your
favorite infix language?...
My belief is that an excess of infix notation is a crutch. It certainly
helps if you are weak, but hinders you if you are pushing the limits.
On Wed, 08 Nov 2006 19:29:18 +0000, Jon Harrop wrote:
> ······@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/
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.
On Wed, 08 Nov 2006 15:12:34 -0800, birchb wrote:
>
> 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.
..hehe.. ok, this then:
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (1- n)))))
--
Lars Rune Nøstdal
http://lars.nostdal.org/
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.
······@tpg.com.au wrote:
> 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.
I think the use of "1- n" to denote "n-1" is particularly elegant. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Lars Rune N�stdal <···········@gmail.com> writes:
> On Wed, 08 Nov 2006 19:29:18 +0000, Jon Harrop wrote:
>
>> ······@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);
> }
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?
Pascal Bourguignon <···@informatimago.com> writes:
> 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.
Victor Kryukov <···················@gmail.com> writes:
> Pascal Bourguignon <···@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*.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Pascal Bourguignon <···@informatimago.com> writes:
> Victor Kryukov <···················@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.
> I'm looking for people who are interested in using a lisp/scheme
> 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? :-)
······@tpg.com.au napisał(a):
> 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.
>
>
> 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 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
Rafal Strzalinski wrote:
> 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
······@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.
>
> 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 ·······@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
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.
·······@gmail.com writes:
> ······@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.
>>
>> 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 ·······@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
>
> 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.
Please don't encourage this sort of thing.
Bill Atkins wrote:
> ·······@gmail.com writes:
>
> > ······@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.
> >>
> >> 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 ·······@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
> >
> > 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.
>
> Please don't encourage this sort of thing.
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.
+ Bill Atkins <······@rpi.edu>:
| 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
······@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.
>
> 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
"I'll just take it as a warning that there are idiots out there who
would do this, and implementation of it as a sign from God that the
implementor has in fact gone insane..."
Well said!
······@tpg.com.au writes:
> 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)
There's no parenthesis in lisp. Parentheses are but editor commands,
to move along the syntactic tree. For example, when we start from an
empty form, typing an open parenthesis creates a syntactic tree node
and places the cursor at the "car" position. Closing parentheses make
the cursor move up in the parse tree, and spaces make the cursor move
to the next node. In the following trace, the keyboard commands typed
so far are indicated in the lisp comment, and the resulting parse tree
below, with the caret (^) representing the cursor position. In such
an editor, typing a space before or after any parenthesis, or just
closing parentheses at the end of the form is just a useless cursor
movement and could be replaced by mouse clicks or the user could just
enter directly the next command.
;; (
+---- ^
|
NIL
;; (defun
+---- defun^
|
NIL
;; (defun SPC
+---- defun
|
NIL^
;; (defun fact SPC
+---- defun
|
+---- fact
|
NIL^
;; (defun fact (
+---- defun
|
+---- fact
|
+----+---- ^
| |
NIL NIL
;; (defun fact (x
+---- defun
|
+---- fact
|
+----+---- x^
| |
NIL NIL
;; (defun fact (x)
+---- defun
|
+---- fact
|
+----+---- x
| |
NIL^ NIL
;; (defun fact (x) (
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- ^
| |
NIL NIL
;; (defun fact (x) (if SPC
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL NIL^
;; (defun fact (x) (if (
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+----^
| |
NIL NIL
;; (defun fact (x) (if (< x 1
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
NIL +---- x
|
+---- 1^
|
NIL
;; (defun fact (x) (if (< x 1)
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
NIL^ +---- x
|
+---- 1
|
NIL
;; (defun fact (x) (if (< x 1) 1
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
| +---- x
| |
| +---- 1
| |
| NIL
|
+---- 1
|
NIL
;; (defun fact (x) (if (< x 1) 1 (* x
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
| +---- x
| |
| +---- 1
| |
| NIL
|
+---- 1
|
+----+---- *
| |
NIL +---- x^
|
NIL
;; (defun fact (x) (if (< x 1) 1 (* x (
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
| +---- x
| |
| +---- 1
| |
| NIL
|
+---- 1
|
+----+---- *
| |
NIL +---- x
|
+----+---- ^
| |
NIL NIL
;; (defun fact (x) (if (< x 1) 1 (* x (fact (1- x))
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL +----+---- <
| |
| +---- x
| |
| +---- 1
| |
| NIL
|
+---- 1
|
+----+---- *
| |
NIL +---- x
|
+----+---- fact
| |
NIL^ +----+---- 1-
| |
NIL +---- x
|
NIL
;; (defun fact (x) (if (< x 1) 1 (* x (fact (1- x)))))
+---- defun
|
+---- fact
|
+----+---- x
| |
| NIL
|
+----+---- if
| |
NIL^ +----+---- <
| |
| +---- x
| |
| +---- 1
| |
| NIL
|
+---- 1
|
+----+---- *
| |
NIL +---- x
|
+----+---- fact
| |
NIL +----+---- 1-
| |
NIL +---- x
|
NIL
Would it be useful to write an emacs/climacs mode to represent forms
this way and allow their editing with this representation?
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.