Hello,
Slightly related to the this newsgroup. Someone has written an
article about PLT Scheme. From the introduction:
When I tell programmers that my favorite programming language is
Scheme, they tend to react as though I'd told them my favorite
snack were packing styrofoam or my favorite music were junior
high orchestra recordings: those who can even bring themselves to
believe me mostly wonder what on Earth I could be thinking. Some
wonder if I've ever programmed in a real language like C or C++
(I have), if I'm one of those academic nuts who cares more about
proving theorems about programs than actually using them for real
work (I'm not), or if all those parentheses have rotted my brain
(probably). So what could make me like this weird language with
no for loop and so many parentheses it makes you crosseyed?
http://www.kuro5hin.org/story/2004/3/17/93442/8657
Mostly preaching to the choir here, but thought people might be
interested.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
"David Magda" <··················@ee.ryerson.ca> wrote in message
···················@number6.magda.ca...
> Hello,
>
> Slightly related to the this newsgroup. Someone has written an
> article about PLT Scheme. From the introduction:
>
> When I tell programmers that my favorite programming language is
> Scheme, they tend to react as though I'd told them my favorite
> snack were packing styrofoam or my favorite music were junior
> high orchestra recordings: those who can even bring themselves to
> believe me mostly wonder what on Earth I could be thinking. Some
> wonder if I've ever programmed in a real language like C or C++
> (I have), if I'm one of those academic nuts who cares more about
> proving theorems about programs than actually using them for real
> work (I'm not), or if all those parentheses have rotted my brain
> (probably). So what could make me like this weird language with
> no for loop and so many parentheses it makes you crosseyed?
>
> http://www.kuro5hin.org/story/2004/3/17/93442/8657
I've been seeing fragments like this for a while now, but I'm curious if
someone could enlighten me.
In the article was this code fragment:
(define (range low high)
(cond
[(> low high) null]
[else (cons low (range (+ low 1) high))]))
Can someone tell me what the difference between the [] and the () are here?
Is this simply an extension in the Scheme implementation? It it required or
could the [] simply be changed to ()? Or is it a syntax hack where the []
and () are identical semantically, as long as they're matched properly.
Back In The Day when they had Lisp on our Cyber 730, they used ] and a
character that simply "terminates all open parenthesis".
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> In the article was this code fragment:
>
> (define (range low high)
> (cond
> [(> low high) null]
> [else (cons low (range (+ low 1) high))]))
>
> Can someone tell me what the difference between the [] and the ()
> are here?
No difference, it's used for style (indicating some places where it's
not obvious that there's no function application).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Ray Dillinger
Subject: Re: K5 article: "Why I Like PLT Scheme"
Date:
Message-ID: <405AA50E.CA39AD44@sonic.net>
Will Hartung wrote:
>
> I've been seeing fragments like this for a while now, but I'm curious if
> someone could enlighten me.
>
> In the article was this code fragment:
>
> (define (range low high)
> (cond
> [(> low high) null]
> [else (cons low (range (+ low 1) high))]))
>
> Can someone tell me what the difference between the [] and the () are here?
> Is this simply an extension in the Scheme implementation? It it required or
> could the [] simply be changed to ()? Or is it a syntax hack where the []
> and () are identical semantically, as long as they're matched properly.
It's a syntactic extension made by several schemes. They could be replaced
with parens without altering the meaning of the code at all. The basic idea
was that [] are closer to the return key and don't require capitalization
so they're easier to type than (). (this ignores the fact that lots of
schemers, like me, had already remapped the keys on their keyboards).
Among schemers who use it, its primary purpose seems to be to delineate
which forms are calls and which are macros. Macros get [] and calls get ().
But it's not done all the time, and none of the systems that supports it
cares which case it gets used in.
Bear
Ray Dillinger <····@sonic.net> writes:
> Will Hartung wrote:
> >
> > Can someone tell me what the difference between the [] and the ()
> > are here? Is this simply an extension in the Scheme
> > implementation? It it required or could the [] simply be changed
> > to ()? Or is it a syntax hack where the [] and () are identical
> > semantically, as long as they're matched properly.
>
> It's a syntactic extension made by several schemes. They could be
> replaced with parens without altering the meaning of the code at
> all. The basic idea was that [] are closer to the return key and
> don't require capitalization so they're easier to type than
> (). (this ignores the fact that lots of schemers, like me, had
> already remapped the keys on their keyboards).
>
> Among schemers who use it, its primary purpose seems to be to
> delineate which forms are calls and which are macros. Macros get []
> and calls get (). But it's not done all the time, and none of the
> systems that supports it cares which case it gets used in.
In the context of PLT (where the question originated), both of these
are wrong.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
"Ray Dillinger" <····@sonic.net> wrote in message
······················@sonic.net...
> Will Hartung wrote:
> >
> > I've been seeing fragments like this for a while now, but I'm curious if
> > someone could enlighten me.
> >
> > In the article was this code fragment:
> >
> > (define (range low high)
> > (cond
> > [(> low high) null]
> > [else (cons low (range (+ low 1) high))]))
> It's a syntactic extension made by several schemes. They could be replaced
> with parens without altering the meaning of the code at all. The basic
idea
> was that [] are closer to the return key and don't require capitalization
> so they're easier to type than (). (this ignores the fact that lots of
> schemers, like me, had already remapped the keys on their keyboards).
>
> Among schemers who use it, its primary purpose seems to be to delineate
> which forms are calls and which are macros. Macros get [] and calls get
().
> But it's not done all the time, and none of the systems that supports it
> cares which case it gets used in.
I liked the other explanation, where it delineates forms where the first
element is not a function. But, either way.
Does the scheme reader know about these distinctions?
I mean if I read: (+ [* 2 3] 5) and print the list, do I get back (+ [* 2 3]
5) or (+ (* 2 3) 5)?
I guess my only real problem with it is that we have for years in the
community been essentially defending and promoting the S-Expr format, and
claiming that parens aren't a big deal, you get used to them, they vanish
with time, indention clarifies intent, etc.
And now we see this ()[] mapping, which to me says "You know that paren
stuff we've been debating about? Yea..well, just kidding. We can't figure it
out either...".
If you want to map all of your () to [] for typing, then the premise is the
same, if not the implementation (I have no problems with () and shift keys
but I'm sure it's a matter of taste, and I've never had the other way).
[it's [just that] [we [use [brackets instead] "()"]]] (Wow...that's looks
very Angry. Lots of sharp corners. Interesting).
But when you mix and match the symbols to note context, that basically
smashes the "parens are no big deal" argument, IMHO, to smithereenees (to
quote Yosemite Sam).
I guess now there's no reason to defend ()'s anymore. The proper response
now is "You're right, they're weak, but we deal with it and like them
anyway, next topic."
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> > Among schemers who use it, its primary purpose seems to be to delineate
> > which forms are calls and which are macros. Macros get [] and calls get
> ().
> > But it's not done all the time, and none of the systems that supports it
> > cares which case it gets used in.
>
> I liked the other explanation, where it delineates forms where the first
> element is not a function. But, either way.
I think the other explanation was more accurate. However, it's true that
it's not done everywhere. The most common usage is in forms like LET where
you get multiple open parens in a row. Brackets really help in clarifying
that, particularly if your editor helps enforce matching of [] vs. (), i.e.
if the editor can flag incorrect nesting of the two types.
> Does the scheme reader know about these distinctions?
>
> I mean if I read: (+ [* 2 3] 5) and print the list, do I get back (+ [* 2
3]
> 5) or (+ (* 2 3) 5)?
The latter. The brackets are aliases for parenthesis, which only have
meaning in source code and to editors.
> I guess my only real problem with it is that we have for years in the
> community been essentially defending and promoting the S-Expr format,
> and claiming that parens aren't a big deal, you get used to them, they
> vanish with time, indention clarifies intent, etc.
>
> And now we see this ()[] mapping, which to me says "You know that paren
> stuff we've been debating about? Yea..well, just kidding. We can't figure
it
> out either...".
The problem is that there's truth to the latter. I'd rather acknowledge
that. Claiming the emperor's clothes are just fine is not much good if
everyone can see his ass peeking out.
In any case, Lisp is full of constructs that violate pure S-exp structure:
the shorthand for quote, quasiquote, unquote, reader macros, etc. Brackets
compromise S-exp structure less than any of these things.
> If you want to map all of your () to [] for typing, then the premise is
the
> same, if not the implementation (I have no problems with () and shift keys
> but I'm sure it's a matter of taste, and I've never had the other way).
> [it's [just that] [we [use [brackets instead] "()"]]] (Wow...that's looks
> very Angry. Lots of sharp corners. Interesting).
No-one writes code like that. I've never seen two brackets in a row, and it
would somewhat defeat the purpose of their use.
> But when you mix and match the symbols to note context, that basically
> smashes the "parens are no big deal" argument, IMHO, to smithereenees
> (to quote Yosemite Sam).
I'd say the occasional pair of brackets for clarity is no big deal. They're
still s-expressions in every meaningful way.
> I guess now there's no reason to defend ()'s anymore. The proper
> response now is "You're right, they're weak, but we deal with it and
> like them anyway, next topic."
That's an overreaction. It's not a binary issue - parens good or parens
bad. Parens are good and no problem most of the time, but there are cases
where a bit of additional clarity can be helpful. Brackets can be useful in
those cases, but they don't affect the structure or nature of s-expressions,
except in the most superficial way.
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message
·····················@newsread2.news.atl.earthlink.net...
> Will Hartung wrote:
> > I guess now there's no reason to defend ()'s anymore. The proper
> > response now is "You're right, they're weak, but we deal with it and
> > like them anyway, next topic."
>
> That's an overreaction. It's not a binary issue - parens good or parens
> bad. Parens are good and no problem most of the time, but there are cases
> where a bit of additional clarity can be helpful. Brackets can be useful
in
> those cases, but they don't affect the structure or nature of
s-expressions,
> except in the most superficial way.
Well, it's just interesting that it seems to me to be a fairly new idiom, in
a language and community that in many ways is quick to adapt "good idioms",
yet has a very long history.
It's clearly been thought about before, but in the case of the Cybers Lisp
it was more a syntax sugar in that I'm guessing was motivated by either a)
the crappy line editors of the time or b) (horrors) using Lisp on punched
cards (see a). That is, simply to make the language more palatable in a low
bandwidth environment.
So, the real question is why is this idiom appearing now when it may well
have been tried and discarded before?
It could be just my lack of exposure, but I used to hang around c.l.s a lot
several years ago, and never even saw remote references to it come up.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> It could be just my lack of exposure, but I used to hang around c.l.s a lot
> several years ago, and never even saw remote references to it come up.
I know Chez Scheme did this at least as early as 1996.
--
Alan Shutko <···@acm.org> - I am the rocks.
I'm only happy when I worry about stuff.
"Will Hartung" <·····@msoft.com> writes:
> So, the real question is why is this idiom appearing now when it may
> well have been tried and discarded before?
This distinction is very useful for beginners: those people in their
first two weeks of writing parenthesized code, and have no clue why
this:
(define (length l)
(cond (null(l) 0)
(else (length (cdr l)))))
doesn't work. Since DrScheme is aimed at such people, it has some
functionality specific for these cases, and there is also the []
idiom.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> wrote:
> "Will Hartung" <·····@msoft.com> writes:
>
> > So, the real question is why is this idiom appearing now when it may
> > well have been tried and discarded before?
>
> This distinction is very useful for beginners: those people in their
> first two weeks of writing parenthesized code, and have no clue why
> this:
>
> (define (length l)
> (cond (null(l) 0)
> (else (length (cdr l)))))
>
> doesn't work. Since DrScheme is aimed at such people, it has some
> functionality specific for these cases, and there is also the []
> idiom.
>
As to the functionality specific to newbies... What about using diferent colors for parentheses at different nesting levels? Maybe not that hard to add this to Emacs? Making this an option, of course. Or DrScheme.
---
~rv
Vasile Rotaru <·······@seznam.cz> writes:
> Eli Barzilay <···@barzilay.org> wrote:
>
> > "Will Hartung" <·····@msoft.com> writes:
> >
> > > So, the real question is why is this idiom appearing now when it may
> > > well have been tried and discarded before?
> >
> > This distinction is very useful for beginners: those people in their
> > first two weeks of writing parenthesized code, and have no clue why
> > this:
> >
> > (define (length l)
> > (cond (null(l) 0)
> > (else (length (cdr l)))))
> >
> > doesn't work. Since DrScheme is aimed at such people, it has some
> > functionality specific for these cases, and there is also the []
> > idiom.
> >
>
> As to the functionality specific to newbies... What about using
> diferent colors for parentheses at different nesting levels? Maybe
> not that hard to add this to Emacs? Making this an option, of
> course. Or DrScheme.
But this won't help newbies... The main confusion that you're getting
over is the fact that you tell them that the syntax is very simple --
every time you see parens, you either look at the first symbol and
identify a special form, or you have a function application. Square
brackets are used in places where this is not true -- and coloring
parens according to their depth would help making this better.
(Besides, it is easy to write code that has more paren levels than you
could distinguish, ending up in code that looks "happy" but is
unreadable otherwise.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Will Hartung wrote:
> Well, it's just interesting that it seems to me to be a fairly new idiom,
in
> a language and community that in many ways is quick to adapt "good
idioms",
> yet has a very long history.
A quick google turned up this 1988 message:
http://groups.google.com/groups?selm=16934%40shemp.CS.UCLA.EDU
...which mentions the brackets in Chez Scheme. 16 years is about 35% of the
history of Lisp.
> So, the real question is why is this idiom appearing now when it may well
> have been tried and discarded before?
I agree with Eli that the teaching benefits are probably a big factor, and I
have the impression that Scheme is taught to more students now than ever
before. However, the brackets make sense outside the educational context,
too.
> It could be just my lack of exposure, but I used to hang around c.l.s a
lot
> several years ago, and never even saw remote references to it come up.
It's a purely optional feature, and it hasn't been particularly
controversial, or the subject of much discussion that I've seen. The only
issue I recall having been raised is that it's not portable amongst all
Scheme implementations, and that perhaps there should be a SRFI for it, to
help correct that.
Anton
In article <···············@id-197644.news.uni-berlin.de>,
"Will Hartung" <·····@msoft.com> writes:
> So, the real question is why is this idiom appearing now when it may well
> have been tried and discarded before?
PLT clearly seems to be intended as a teaching tool, among other
things for beginners, i.e. peole who haven't graduated to not seeing
parenthese anymore
hs
--
Patriotism is the last refuge of the scoundrel
Samuel Johnson
Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw
From: Grzegorz =?UTF-8?B?Q2hydXBhxYJh?=
Subject: Re: K5 article: "Why I Like PLT Scheme"
Date:
Message-ID: <c3fhtu$afu$1@news.ya.com>
Anton van Straaten wrote:
...
> Brackets really help in clarifying
> that, particularly if your editor helps enforce matching of [] vs. (),
> i.e. if the editor can flag incorrect nesting of the two types.
>
...
> The brackets are aliases for parenthesis, which only have
> meaning in source code and to editors.
>
That is not exactly correct, at least in Gauche and Mzscheme. The reader in
those implementations distinguishes brackets from parens and will complain
about mismatches:
> (let [(a 40) (b 2)] (+ a b))
42
> (let [(a 40) (b 2]) (+ a b))
STDIN::142: read: missing ')' to close preceding '(', found instead ']'
Cheers,
--
Grzegorz Chrupała | http://pithekos.net | ·········@jabber.org
A scholar is just a library's way of making another library.
-- Daniel Dennett, Consciousness Explained
Grzegorz Chrupa�a <········@pithekos.net> writes:
> That is not exactly correct, at least in Gauche and Mzscheme. The reader in
> those implementations distinguishes brackets from parens and will complain
> about mismatches:
>
> > (let [(a 40) (b 2)] (+ a b))
> 42
> > (let [(a 40) (b 2]) (+ a b))
> STDIN::142: read: missing ')' to close preceding '(', found instead ']'
I was afraid of that. It means that you have much more work to do to
read and to write mixes of brackets and parenthesis.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon wrote:
> Grzegorz Chrupa�a <········@pithekos.net> writes:
> > That is not exactly correct, at least in Gauche and Mzscheme. The reader
in
> > those implementations distinguishes brackets from parens and will
complain
> > about mismatches:
> >
> > > (let [(a 40) (b 2)] (+ a b))
> > 42
> > > (let [(a 40) (b 2]) (+ a b))
> > STDIN::142: read: missing ')' to close preceding '(', found instead ']'
>
> I was afraid of that. It means that you have much more work to do to
> read and to write mixes of brackets and parenthesis.
If you're going to use the feature at all, then you want to ensure that they
match properly, otherwise there'd be no point in using the brackets.
I had forgotten about the errors which the reader gives on mismatches like
this, but I've actually found those errors to be nothing but helpful, since
it allows the location of a paren mismatch to be dramatically narrowed down.
Anton
Anton van Straaten wrote:
> Pascal Bourguignon wrote:
>>Grzegorz Chrupa�a <········@pithekos.net> writes:
>>>That is not exactly correct, at least in Gauche and Mzscheme. The reader
>>> in those implementations distinguishes brackets from parens and will
>>> complain about mismatches:
>>>>(let [(a 40) (b 2)] (+ a b))
>>>
>>>42
>>>
>>>>(let [(a 40) (b 2]) (+ a b))
>>>
>>>STDIN::142: read: missing ')' to close preceding '(', found instead ']'
>>
>>I was afraid of that. It means that you have much more work to do to
>>read and to write mixes of brackets and parenthesis.
> If you're going to use the feature at all, then you want to ensure that they
> match properly, otherwise there'd be no point in using the brackets.
About Grzegorz' worry about hard work. Suppose I have written ([( and
press ) three times, my editor will insert )]) and not ))).
> I had forgotten about the errors which the reader gives on mismatches like
> this, but I've actually found those errors to be nothing but helpful, since
> it allows the location of a paren mismatch to be dramatically narrowed down.
That's my experience too.
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Anton van Straaten wrote:
> > Pascal Bourguignon wrote:
<snip>
> >>I was afraid of that. It means that you have much more work to do to
> >>read and to write mixes of brackets and parenthesis.
>
> > If you're going to use the feature at all, then you want to ensure that
they
> > match properly, otherwise there'd be no point in using the brackets.
>
> About Grzegorz' worry about hard work.
Just for the record, that was Pascal's worry, not Grzegorz'. The quoting in
my post was hard to read.
Anton
"Will Hartung" <·····@msoft.com> writes:
> But when you mix and match the symbols to note context, that basically
> smashes the "parens are no big deal" argument, IMHO, to smithereenees (to
> quote Yosemite Sam).
The only problem I have with ([]) is that it works only two levels deep.
I'd propose to schemers to use instead this notation:
(1 (2 (3 (4 ... (42 ... 42) ... 4) 3) 2) 1)
It's much clearer this way:
(1 define (2 fct x 2)
(2 cond
(3 (4 = x 1 4) 1 3)
(3 otherwise (4 * x (5 fct (6 - x 1 6) 5) 4) 3) 2) 1)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Joe Marshall
Subject: Re: K5 article: "Why I Like PLT Scheme"
Date:
Message-ID: <7jxgfz4w.fsf@ccs.neu.edu>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> "Will Hartung" <·····@msoft.com> writes:
>> But when you mix and match the symbols to note context, that basically
>> smashes the "parens are no big deal" argument, IMHO, to smithereenees (to
>> quote Yosemite Sam).
>
> The only problem I have with ([]) is that it works only two levels deep.
> I'd propose to schemers to use instead this notation:
>
> (1 (2 (3 (4 ... (42 ... 42) ... 4) 3) 2) 1)
>
> It's much clearer this way:
>
> (1 define (2 fct x 2)
> (2 cond
> (3 (4 = x 1 4) 1 3)
> (3 otherwise (4 * x (5 fct (6 - x 1 6) 5) 4) 3) 2) 1)
Rather than digits, let's represent the depth by a count of whitespace
characters....
From: Duane Rettig
Subject: Re: K5 article: "Why I Like PLT Scheme"
Date:
Message-ID: <4ad2cl8x3.fsf@franz.com>
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > "Will Hartung" <·····@msoft.com> writes:
> >> But when you mix and match the symbols to note context, that basically
> >> smashes the "parens are no big deal" argument, IMHO, to smithereenees (to
> >> quote Yosemite Sam).
> >
> > The only problem I have with ([]) is that it works only two levels deep.
> > I'd propose to schemers to use instead this notation:
> >
> > (1 (2 (3 (4 ... (42 ... 42) ... 4) 3) 2) 1)
> >
> > It's much clearer this way:
> >
> > (1 define (2 fct x 2)
> > (2 cond
> > (3 (4 = x 1 4) 1 3)
> > (3 otherwise (4 * x (5 fct (6 - x 1 6) 5) 4) 3) 2) 1)
>
> Rather than digits, let's represent the depth by a count of whitespace
> characters....
Then we could change )( pairs to newlines and ( and ) to optional
newlines, and join all of the other indentation-based languages.
I would put a smiley here, but I'm following my new rule. One
question, though: how many levels of depth is the paren in
a smiley? As deep as the humor? In that case, perhaps zero spaces
for mine:
--
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
Joe Marshall <···@ccs.neu.edu> wrote:
> > It's much clearer this way:
> >
> > (1 define (2 fct x 2)
> > (2 cond
> > (3 (4 = x 1 4) 1 3)
> > (3 otherwise (4 * x (5 fct (6 - x 1 6) 5) 4) 3) 2) 1)
>
> Rather than digits, let's represent the depth by a count of whitespace
> characters....
And if the programmer gets the count wrong, then the compiler
should refuse to run the program until that typing error is
fixed.
Will
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> "Will Hartung" <·····@msoft.com> writes:
> > But when you mix and match the symbols to note context, that basically
> > smashes the "parens are no big deal" argument, IMHO, to smithereenees (to
> > quote Yosemite Sam).
>
> The only problem I have with ([]) is that it works only two levels deep.
> I'd propose to schemers to use instead this notation:
>
> (1 (2 (3 (4 ... (42 ... 42) ... 4) 3) 2) 1)
>
> It's much clearer this way:
>
> (1 define (2 fct x 2)
> (2 cond
> (3 (4 = x 1 4) 1 3)
> (3 otherwise (4 * x (5 fct (6 - x 1 6) 5) 4) 3) 2) 1)
>
or
(* define (** fct x **)
(** cond (*** (**** = x 1 ****) 1 ***)
(*** else (**** * x (***** fct (****** - x 1 ******) *****) ****) ****) ***) **) *)
or maybe
(define (* fact x 2 *)
(* cond (| ($ = x 1 $) 1 |)
(| else (. * x (, fact (; - x 1 ;) ,) .) |) *))
The benefit of this notation is that is also a syntactically correct Pascal program...
---
~rv
On Thu, 18 Mar 2004 09:56:14 -0800, Will Hartung wrote:
> Back In The Day when they had Lisp on our Cyber 730, they used ] and a
> character that simply "terminates all open parenthesis".
Actually, it was more useful than that. It terminated all open parens up
to the preceding "[" and defaulted to the entire input if there was no
preceding "[". I'm not sure if this actually helped produce readable
code when used in files, but it sure helped interactive input :-).
The Lisp was UT-Lisp wasn't it? This was a really interesting lisp where a
cons cell actually had 3 pointers (the machine word was 60 bits, and a
pointer was 18 bits), the CAR, CDR and CXR. I actually took my first Lisp
course on this system. So I guess you can put the blame for my cussedness
on Texans...
faa