Python syntax in Lisp and Scheme

[Karl A. Krueger]

Re: Python syntax in Lisp and Scheme

In comp.lang.lisp Dave Benjamin <dave@3dex.co m> wrote:[color=blue]
> Karl A. Krueger wrote:[color=green]
>> This seems like a good juncture to post my list of common myths and
>> misconceptions about popular programming languages. Contributions are
>> welcome; flames only if they're funny. Anyone who needs to see :) on
>> things to know they're meant in jest should stop reading now.[/color]
>
> Haha... that's really funny... except the last one. Not that I'm a
> Python purist (a big fan, yes, but not a purist), but I rarely complain
> about its slowness. Java is too easy of a target for that one... =)[/color]

*laugh* I use Python more often in my job than I use Lisp, Perl, or any
other language, except possibly the Unix shell. It really is not among
the speedier ones for a lot of tasks. (Neither is Java, but I have
thankfully avoided having to do any real work in Java.) Python's
strength, for the kind of projects I work on in it, is its regularity
and the extensive standard library for things like talking to network
applications.

I moved to Python for such things from Perl, after realizing that I
really did not want to implement a database-backed application in a
language that required messy explicit dereferencing when dealing with
complex data structures. I'd much rather deal with a list of lists of
tuples than a list of references to lists of references to tuples,
getting back things like "ARRAY<#fhqwhga ds>" when I missed a dereference
character.

But you're taking my list of myths too seriously. Not all C programs
are riddled with security bugs either. :)

Incidentally, I regard objections to "the whitespace thing" in Python
and objections to "the parenthesis thing" in Lisp as more or less the
same. People who raise these objections are usually just saying "Ick!
This looks so unfamiliar to me!" in the language of rationalization s.
I guess a philosopher would say that I am an emotivist about notation
criticisms.

--
Karl A. Krueger <kkrueger@examp le.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews

[Mike Rovner]

Re: Code block literals

Dave Benjamin wrote:[color=blue]
> Mike Rovner wrote:[color=green]
>> Unnamed code blocks considered evil :), use named instead
>> (functions).[/color]
>
> Why are they evil? Does being anonymous automatically make you evil?
>
> For instance, I always thought this was a cooler alternative to the
> try/finally block to ensure that a file gets closed (I'll try not to
> mess up this time... ;) :
>
> open('input.txt ', { |f|
> do_something_wi th(f)
> do_something_el se_with(f)
> })
>
> Rather than:
>
> f = open('input.txt ')
> try:
> do_something_wi th(f)
> do_something_el se_with(f)
> finally:
> f.close()[/color]

"Explicit is better than implicit"

Even your example clearly shows that try block is much more readable and
understandable.
That's why it's being considered evil by majority of python developers.
[color=blue]
> But the anonymous version still looks more concise to me.[/color]

Python prioritize things diferently than other languages.
It's not an APL. "Readabilit y counts"
[color=blue]
> Yeah, wasn't something like that up on ASPN? That's an interesting
> trick... are you sure it's not supposed to be "property(*apro p())"
> though? (who's being pedantic now? =)[/color]

Yeah, right. Thanks for pointing out.

Mike

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> He provides more information at http://www.paulgraham.com/icad.html[/color]

The page I referenced (http://www.paulgraham.com/power.html)
appears to be a refinement of some ideas on that page.

It's somewhat funny that on the page I mentioned he says:

So any language comparison where you have to meet a predefined
spec is testing slightly the wrong thing.

while on the page you reference he gives a comparison between various
languages based on a predefined spec. And he uses as his test case
something I've not needed. By comparison, following Kenny Tilton's
lead, the Bagley Shootout Page suggests that in an aggregate of small
but non-trivial problems, OCaml is the most succinct language, with
Python roughly comparable to Lisp/Scheme.

I have run across his pages before, and have a hard time
symphathizing with his view of things. For example, the start of
the icad essay mentions that Lisp is already "kind of unusual"
compared to C because it includes a full interpreter. But
effectively all Python programs shipped include a full interpreter
as well, and many give access to that interpreter, so I don't
see what's unusual about it. Ditto for Tcl apps. Even some of
my command-line perl apps included a way to pass in perl
code on the command line, as for a search filter.

The phrase "they had hard-headed engineering reasons for
making the syntax look so strange." reminds me of the statement
"better first rate salespeople and second rate engineers than
second rate salespeople and first rate engineers" (and better
first rate both). That's saying *nothing* about the languages;
it's saying that his viewpoint seems to exclude the idea that
there are hard-headed non-engineering reasons for doing things."

Consider one of those "hard-headed engineering reasons", at

http://www.paulgraham.com/popular.html

It has sometimes been said that Lisp should use first and
rest instead of car and cdr, because it would make programs
easier to read. Maybe for the first couple hours. But a hacker
can learn quickly enough that car means the first element
of a list and cdr means the rest. Using first and rest means
50% more typing. And they are also different lengths, meaning
that the arguments won't line up when they're called,

That to me is a solid case of post hoc ergo proper. The
words "1st" and "rst" are equally as short and easier to
memorize. And if terseness were very important, then
what about using "." for car and ">" for cdr? No, the reason
is that that's the way it started and it will stay that way
because of network effects -- is that a solid engineering
reason? Well, it depends, but my guess is that he wouldn't
weight strongly the impact of social behaviours as part of
good engineering. I do.

And entirely off the topic of programming, his essay at

http://www.paulgraham.com/nerds.html

has little resonance with my memory of high school.

Andrew
dalke@dalkescie ntific.com

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Thu, 9 Oct 2003, Andrew Dalke wrote:[color=blue]
> Consider one of those "hard-headed engineering reasons", at
> http://www.paulgraham.com/popular.html
>
> It has sometimes been said that Lisp should use first and
> rest instead of car and cdr, because it would make programs
> easier to read. Maybe for the first couple hours. But a hacker
> can learn quickly enough that car means the first element
> of a list and cdr means the rest. Using first and rest means
> 50% more typing. And they are also different lengths, meaning
> that the arguments won't line up when they're called,
>
> That to me is a solid case of post hoc ergo proper. The
> words "1st" and "rst" are equally as short and easier to
> memorize. And if terseness were very important, then
> what about using "." for car and ">" for cdr? No, the reason
> is that that's the way it started and it will stay that way
> because of network effects -- is that a solid engineering
> reason? Well, it depends, but my guess is that he wouldn't
> weight strongly the impact of social behaviours as part of
> good engineering. I do.[/color]

It hasn't stayed that way for me:

(define first car)
(define rest cdr)

:)

- Daniel

[Dave Benjamin]

Re: Code block literals

Mike Rovner wrote:
[color=blue]
> Dave Benjamin wrote:
>[color=green]
>>For instance, I always thought this was a cooler alternative to the
>>try/finally block to ensure that a file gets closed (I'll try not to
>>mess up this time... ;) :
>>
>>open('input.t xt', { |f|
>> do_something_wi th(f)
>> do_something_el se_with(f)
>>})
>>
>>Rather than:
>>
>>f = open('input.txt ')
>>try:
>> do_something_wi th(f)
>> do_something_el se_with(f)
>>finally:
>> f.close()[/color]
>
> "Explicit is better than implicit"[/color]

In that case, why do we eschew code blocks, yet have no problem with the
implicit invocation of an iterator, as in:

for line in file('input.txt '):
do_something_wi th(line)

This is not to say that I dislike that behavior; in fact, I find it
*beneficial* that the manner of looping is *implicit* because you can
substitute a generator for a sequence without changing the usage. But
there's little readability difference, IMHO, between that and:

file('input.txt ').each_line({ |line|
do_something_wi th(line)
})

Plus, the first example is only obvious because I called my iteration
variable "line", and because this behavior is already widely known. What
if I wrote:

for byte in file('input.dat '):
do_something_wi th(byte)

That would be a bit misleading, no? But the mistake isn't obvious. OTOH,
in the more explicit (in this case) Ruby language, it would look silly:

open('input.txt ').each_line { |byte|
# huh? why a byte? we said each_line!
}

I think this is important to point out, because the implicit/explicit
rule comes up all the time, yet Python is implicit about lots of things!
To name a few:

- for loops and iterators
- types of variables
- dispatching via subclass polymorphism
- coercion (int->float, int->long...)
- exceptions (in contrast with Java's checked exceptions)
- __magic_methods __
- metaclasses
- nested scopes (compared to yesteryear's lambda x, y=y, z=z: ...)
- list comprehensions

In all of the above cases (with a bit of hesitation toward the voodoo of
metaclasses) I think Python is a better language for it. On the other
hand, Perl's implicit $_ variable is a good example of the hazards of
implicitness; that can be downright confusing. So, it's not cut and dry
by any means.

If all you're saying is that naming something is better than not naming
something because explicit is better than implicit, I'd have to ask why:

a = 5
b = 6
c = 7
d = a + b
e = c / 2
result = d + e
return result

Is any better than:

....
return (a + b) + (c / 2)

To me, it's the same issue. Why should I have to name something that I'm
just going to return in the next statement, or pass as a parameter, and
then be done with it? Does that really increase either readability or
understandabili ty? Why should I name something that I'm not going to ask
for later?
[color=blue]
> Even your example clearly shows that try block is much more readable and
> understandable.
> That's why it's being considered evil by majority of python developers.[/color]

Readability is a moving target. I think that the code block syntax
strikes a nice balance between readability and expressiveness. As far as
what the majority of Python developers consider evil, I don't think
we've got the stats back on that one.
[color=blue][color=green]
>>But the anonymous version still looks more concise to me.[/color]
>
> Python prioritize things diferently than other languages.
> It's not an APL. "Readabilit y counts"[/color]

This is nothing like APL... if anything, it's like Smalltalk, a language
designed to be readable by children! I realize that APL sacrificed
readability for expressiveness to an uncomfortable extreme, but I really
think you're comparing apples and oranges here. List comprehensions are
closer to APL than code blocks.

Dave

[Dave Benjamin]

Re: Code block literals

In article <mailman.106565 6361.21143.pyth on-list@python.org >, Lulu of the Lotus-Eaters wrote:[color=blue]
> Dave Benjamin <dave@3dex.co m> wrote previously:
>|return { |x, y|
>| print x
>| print y
>|}
>|It's unambiguous because no dictionary literal would ever start with
>|'{|', it looks almost identical to a certain other language <g>
>
> Btw. I think Dave is thinking of Ruby as that "certain other language."
> But Clipper/xBase used the same syntax for the same thing before Ruby
> was a glimmer in Matz' eye. I'm not sure if that's where he got it
> though... it might be from somewhere older I don't know about.[/color]

Busted. =) I could be wrong, but I thought Ruby got its code blocks from
Smalltalk, since both languages support them, and both have collections that
support "collect", "select", and "invoke", aka "map", "filter", and
"reduce", using code blocks. The syntax isn't exactly the same, but it's
very similar.

My coworker used to be a Clipper programmer, and he gets a sparkle in his
eye when he reminisces about the code blocks of old.

Dave

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:[color=blue]
> prunesquallor@c omcast.net:
>[color=green]
>>So either the syntax doesn't make a whole hell of a lot of difference
>>in readability, or readability doesn't make a whole hell of a lot of
>>difference in utility.[/color]
>
>
> Or the people who prefer the awesome power that is Lisp and
> Scheme don't find the limited syntax to be a problem.[/color]

OK, here you are saying that only a certain subset of programmers have
the genetic makeup necessary to prefer the unlimited syntax. Unlikely.

It is nice that you also say this strongly correlates with those who
like their programming languages to be powerful. But my guess is that
that genetic thing won't hold up: if everyone who tries Lisp for more
than two weeks gets used to the parens, and then after two months would
not want to edit any other way, then what makes me think anyone who
likes programming (even the ones in your imagination who do not want
powerful languages) would love the syntax.

({function | macro | special-form} arguments*) => values*

Roughly speaking (I'm no BNFer) but... hellasweet! You can chant
"simplicity " as much as you like, but /that/ is simple.

In C i put "int x;" at the top level and I have a global. In Lisp I am
at first astonished to see I have to type (defparameter x) or defvar or
defconstant. Wordy! Wordy! Wordy! But eventually I realize. Oh, why is
the C "x" a global? There is no difference between that declaration and
the one in:

void zzzz () {
int x;
.....}

Oh, well, you see, it is at the top level. ie, Weird things like a form
being at the top level have huge unspoken implications. But with Lisp
there is a great honking special form (macro?) such as "defparamet er"
that grabs you by the lapels and screams "GLOBAL!!!" . But most of all,
it manages to get the job done with The One True Syntax, using a
dedicated macro instead of a special syntax (top-levelness) to establish
the semantics.

You call that "limited"? Yer just flaming.

Anyway, the point is: fuggedaboutit. Lisp syntax is unlike all the other
languages you have ever used, so it seems bizarre to the unitiated. But
go to c.l.l. and flame the syntax and you will discover it is something
Lispniks love. Including those who have used and excelled at all the
other languages. And, as you concede, these are people who groove on the
power of Lisp. Doesn't that make folks think they better go check out
for themselves what these folks have discovered?

http://alu.cliki.net/The%20RtLS%20by%20Road

Don't forget your Lisp-aware editor.


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Michael Geary]

Re: Python syntax in Lisp and Scheme

Andrew Dalke:[color=blue]
> The phrase "they had hard-headed engineering reasons for
> making the syntax look so strange." reminds me of the statement
> "better first rate salespeople and second rate engineers than
> second rate salespeople and first rate engineers" (and better
> first rate both). That's saying *nothing* about the languages;
> it's saying that his viewpoint seems to exclude the idea that
> there are hard-headed non-engineering reasons for doing things."
>
> Consider one of those "hard-headed engineering reasons", at
> http://www.paulgraham.com/popular.html
>
> It has sometimes been said that Lisp should use first and
> rest instead of car and cdr, because it would make programs
> easier to read. Maybe for the first couple hours. But a hacker
> can learn quickly enough that car means the first element
> of a list and cdr means the rest. Using first and rest means
> 50% more typing. And they are also different lengths, meaning
> that the arguments won't line up when they're called,
>
> That to me is a solid case of post hoc ergo proper. The
> words "1st" and "rst" are equally as short and easier to
> memorize. And if terseness were very important, then
> what about using "." for car and ">" for cdr? No, the reason
> is that that's the way it started and it will stay that way
> because of network effects -- is that a solid engineering
> reason? Well, it depends, but my guess is that he wouldn't
> weight strongly the impact of social behaviours as part of
> good engineering. I do.[/color]

It's pretty funny when you consider that car and cdr were named after the
Contents of Address Register and Contents of Decrement Register on the IBM
704. Now that's a solid engineering reason!

(I'm not knocking Lisp; in fact, this discussion has whetted my appetite to
explore it.)

-Mike

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Michael Geary wrote:[color=blue]
> Andrew Dalke:
>[color=green]
>>The phrase "they had hard-headed engineering reasons for
>>making the syntax look so strange." reminds me of the statement
>>"better first rate salespeople and second rate engineers than
>>second rate salespeople and first rate engineers" (and better
>>first rate both). That's saying *nothing* about the languages;
>>it's saying that his viewpoint seems to exclude the idea that
>>there are hard-headed non-engineering reasons for doing things."
>>
>>Consider one of those "hard-headed engineering reasons", at
>>http://www.paulgraham.com/popular.html
>>
>> It has sometimes been said that Lisp should use first and
>> rest instead of car and cdr, because it would make programs
>> easier to read. Maybe for the first couple hours. But a hacker
>> can learn quickly enough that car means the first element
>> of a list and cdr means the rest. Using first and rest means
>> 50% more typing. And they are also different lengths, meaning
>> that the arguments won't line up when they're called,
>>
>>That to me is a solid case of post hoc ergo proper. The
>>words "1st" and "rst" are equally as short and easier to
>>memorize. And if terseness were very important, then
>>what about using "." for car and ">" for cdr? No, the reason
>>is that that's the way it started and it will stay that way
>>because of network effects -- is that a solid engineering
>>reason? Well, it depends, but my guess is that he wouldn't
>>weight strongly the impact of social behaviours as part of
>>good engineering. I do.[/color]
>
>
> It's pretty funny when you consider that car and cdr were named after the
> Contents of Address Register and Contents of Decrement Register on the IBM
> 704. Now that's a solid engineering reason!
>
> (I'm not knocking Lisp; in fact, this discussion has whetted my appetite to
> explore it.)
>
> -Mike
>
>[/color]
Graham does admit in that the reasons for the choice were mostly
historical. However, he uses them because he likes the fact that they
are shorter than first and rest.

If you read his design goals for Arc you will note that he is a big fan
of very terse operators.



--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Me:[color=blue][color=green]
> > Or the people who prefer the awesome power that is Lisp and
> > Scheme don't find the limited syntax to be a problem.[/color][/color]

Kenny Tilton:[color=blue]
> OK, here you are saying that only a certain subset of programmers have
> the genetic makeup necessary to prefer the unlimited syntax. Unlikely.[/color]

Yes, it is very unlikely that I would say that...

Oh wait. I didn't.

I prefer speaking in English even if Navajo might be a better language
for expressing certain concepts. That doesn't mean that preference
is part of my genetic makeup.

I prefer the mambo basic over the salsa basic when dancing.
Doesn't mean that's part of my genetic makeup.
[color=blue]
> ({function | macro | special-form} arguments*) => values*
>
> Roughly speaking (I'm no BNFer) but... hellasweet! You can chant
> "simplicity " as much as you like, but /that/ is simple.[/color]

Actually, you could have a more minimal language with

(name arguments*) => values*

but Lispers must have decided that *some* syntax makes
things easier.

And you can get still more minimal with FORTH where the
syntax is

WORD *
[color=blue]
> But with Lisp
> there is a great honking special form (macro?) such as "defparamet er"
> that grabs you by the lapels and screams "GLOBAL!!!" .[/color]

The word "global" would scream "GLOBAL!!!" a bit more.
[color=blue]
> But most of all,
> it manages to get the job done with The One True Syntax, using a[/color]

TOTS? If there was no need for backwards compatibility, I'll
argue that swapping [] and () would be better, since I don't need
to use shift to use the [ or ] characters. (On a US keyboard. And
yes, I know I could swap the keyboard layout.) Assuming there
was no other code in the world and no other Lisp programmers,
wouldn't that be a better syntax?
[color=blue]
> You call that "limited"? Yer just flaming.[/color]

Yes, I'm calling it limited. I didn't say limiting, which appears to
be what you read.

No, I'm not flaming.
[color=blue]
> But go to c.l.l. and flame the syntax and you will discover it is[/color]
something[color=blue]
> Lispniks love.[/color]

In case you hadn't noticed, this is cross posted on c.l.l.

I am fully aware of M-expressions for Lisp. I know about
Dylan and it's Lispishness in a infix language. I know that
Lispers enjoy their syntax. I know it's the source of the ability
to support macros and other on-the-fly code manipulation.

I am not asking any of them -- nary a soul -- to abandon Lisp.
Nor am I flaming the syntax.

What I said was that Python is *not* an application of
Greespun's Tenth Rule of programming because 1) it isn't
bug-ridden, and 2) because Python explores ideas which
which had no influence on Lisp's development -- user
studies of non-professional programmers.

Where are the user studies which suggested () over [], or that
"car" is better than "first"/"1st" or that "cdr" is better than
"rest"/"rst"?

Yes, I know that the early teletypes might not have had
[ or ], and that car and cdr come from register names on
the machine Lisp was first implemented on. If that's
indeed the justification then there may be a Lisp-ish language
which is equally as powerful, equally as elegant, etc *and*
which is slightly easier to learn and type. But it wasn't chosen,
and it won't be used because of good social reasons: a huge
existing code base and people who now have Lisp "in their
fingers" and don't want to retrain for the slight advantage
that others might get.

"The One True Syntax" indeed.

(Okay, I admit it. That one line was flaming *you*, but not
c.l.l'ers as a class.)
[color=blue]
> And, as you concede, these are people who groove on the
> power of Lisp. Doesn't that make folks think they better go check out
> for themselves what these folks have discovered?[/color]

Sure. More power to them. For me, it looks like my
next really different language to learn might be OCaml. ("really
different" because I needed to learn some Javascript recently,
and I don't find it different enough to give a different view of
the world.)

Andrew
dalke@dalkescie ntific.com

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:[color=blue]
> [...]
> What I said was that Python is *not* an application of
> Greespun's Tenth Rule of programming because 1) it isn't
> bug-ridden, and 2) because Python explores ideas which
> which had no influence on Lisp's development -- user
> studies of non-professional programmers.[/color]

Do you know where I can find those studies? I'm very intested in their
findings :)

By the way, what's a non-professional programmer?
[color=blue]
> Where are the user studies which suggested () over [], or that
> "car" is better than "first"/"1st" or that "cdr" is better than
> "rest"/"rst"?
>
> Yes, I know that the early teletypes might not have had
> [ or ], and that car and cdr come from register names on
> the machine Lisp was first implemented on. If that's
> indeed the justification then there may be a Lisp-ish language
> which is equally as powerful, equally as elegant, etc *and*
> which is slightly easier to learn and type. But it wasn't chosen,
> and it won't be used because of good social reasons: a huge
> existing code base and people who now have Lisp "in their
> fingers" and don't want to retrain for the slight advantage
> that others might get.[/color]

Well, if you count scheme as a lisp...

Welcome to DrScheme, version 205.3-cvs1oct2003.
Language: Pretty Big (includes MrEd and Advanced).[color=blue]
> [first[list 1 2 3 '[4 5]]][/color]
1

- Daniel

[Vis Mike]

Re: Python syntax in Lisp and Scheme

"Erann Gat" <my-first-name.my-last-name@jpl.nasa.g ov> wrote in message
news:my-first-name.my-last-name-081003120141000 1@k-137-79-50-101.jpl.nasa.go
v...[color=blue]
> In article <xcvfzi3r2ge.fs f@famine.OCF.Be rkeley.EDU>,
> tfb@famine.OCF. Berkeley.EDU (Thomas F. Burdick) wrote:
>[color=green][color=darkred]
> > > method overloading,[/color]
> >
> > How could you have both noncongruent argument lists, and multiple
> > dispatch?[/color]
>
> C++ seems to manage it somehow.
>
> #include <stdio.h>
>
> void foo(int x, int y) { printf("1\n"); }
> void foo(double x, int y) { printf("2\n"); }
> void foo(char* x) { printf("3\n"); }
>
> main() {
> foo(1,2);
> foo(1.2,2);
> foo("foo");
> }
>
> compiles and runs without complaint.
>
> E.[/color]

Ahh, but overloading only works at compile time:

void foo( SomeBaseObject* object );
void foo( SomeDerivedObje ct* object );

doesn't work if you're using a base class pointer for all your derived
classes.

Mike

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Doug Tolton:[color=blue]
> Graham does admit in that the reasons for the choice were mostly
> historical. However, he uses them because he likes the fact that they
> are shorter than first and rest.[/color]

Not in that essay I referenced. And I deliberately mentioned
"1st" and "rst" as alternatives to "car" and "cdr" which are exactly
the same length and are easier to remember. The fact that "first"
and "rest" are longer doesn't immediately mean that there are
no other viable alternatives.

BTW, paulgraham.com/arcfaq.html says that car/cdr remain
because they are composable, as in "cadr". Is that the same
as 2nd?

Ahh, the FAQ also says that [ and ] are "less directional"
than ( and ), which I can understand. I don't understand
the objection with < and > ; they "lose because they don't
wrap around enough to enclose expressions long than tokens."
That makes no sense to me. Is is that they aren't tall enough?

Couldn't a good development environment depict the delimiters
as, say Unicode characters 27E8 and 27E9?

http://www.unicode.org/charts/PDF/U27C0.pdf

Those look like large "<" and ">"

Or is there a requirement that it be constrained to display
systems which can only show ASCII? (Just like a good
Lisp editor almost requires the ability to reposition a
cursor to blink on matching open parens. Granted, that
technology is a few decades old now while Unicode isn't,
but why restrict a new language to the display systems
of the past instead of the present?)

Heh-heh. "Why not build Arc on top of Java/Parrot/.NET?"
"We're trying to make something for the long term in Arc,
something that will be useful to people in, say, 100 years."

Then build it on MMIX! :)
[color=blue]
> If you read his design goals for Arc you will note that he is a big fan
> of very terse operators.[/color]

Indeed. It looks easier to understand to my untrained eye.
I disagree that "+" shouldn't work on strings because that
operation isn't commutative -- commutativity isn't a feature
of + it's a feature of + on a certain type of set.

He says that "programmer s will be able to declare that
strings should be represented as traditional sequences of bytes."
which leads me to wonder about its Unicode support.

What's unicode support like in general for Lisp? Found an
answer in http://www.cliki.net/Unicode%20Support Digging
some more, it looks like CLisp uses .. UCS-4 and Unicode 3.2
(from clisp.cons.org) . But do regexps work on unicode strings?
How portable are unicode strings? I figure they must be in
order to handle XML well. ... "ACL does not support 4 byte
Unicode scalar values" says franz.com. www.cl-xml.org says
"The processor passes 1749 of the 1812 tests .. when the base
implementation supports sixteen-bit charactrs." and that
MCL, LispWorks and the Allegro 5.0.1 international version
support 16-bit Unicode while Allegro ascii only supports 8bit.
So some have UCS-2 and some UCS-4.

Is there consensus on the Unicode API?

On the XML path, I found cl-xml. Looking at the bugs section in

http://pws.prserv.net/James.Anderson/XML/documentation/cl-xml.html

It says "the implementation form for HTTP support is determined
at compilation time." Is it really true that even HTTP handling is
different on the different implementations ?

And the section under "porting" is .. strange. It looks like to
use the XML API for a given Lisp I need to know enough
about the given implementation to configure various settings,
so if I wanted to learn Lisp by writing, say, a simple XML-RPC
client then I have to learn first what it means "to complete
definitions in the following files" and the details of "defsystem" ,
"package", "STREAM-READER / -WRITER", etc.

That reminds me of my confusion testing a biolisp package.
I needed to edit the file before it worked; something to do
with commenting/uncommenting the right way to handle
packages. I prefer to start with working code.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Daniel P. M. Silva:[color=blue]
> Do you know where I can find those studies? I'm very intested in their
> findings :)[/color]

Sure. The research was done for ABC. ABC's home page is

http://homepages.cwi.nl/~steven/abc/

ABC is an interactive programming language and environment for
personal computing, originally intended as a good replacement for
BASIC. It was designed by first doing a task analysis of the
programming task.

There's a publication list at

http://homepages.cwi.nl/~steven/abc/publications.html

Guido, the author of Python, was involved in that project. For his
commentary on ABC's influence on Python see:

http://www.python.org/doc/essays/foreword.html

[color=blue]
> By the way, what's a non-professional programmer?[/color]

The people I generally work for. Research scientists,
usually computational chemists and computational biologists,
who need to write code but don't consider themselves to be
software developers and haven't had more than a semester
or two of formal training and would rather do more science
then spend time reading books on language practice or
theory, even if by doing so it made them more productive
in the long run.
[color=blue]
> Welcome to DrScheme, version 205.3-cvs1oct2003.
> Language: Pretty Big (includes MrEd and Advanced).[color=green]
> > [first[list 1 2 3 '[4 5]]][/color]
> 1[/color]

Indeed? Well I just found a mention on Paul Graham's site
that he excluded [] over () because it didn't provide enough
directionality.

Again, where's the studies? :)

Andrew
dalke@dalkescie ntific.com

[Dave Benjamin]

Re: Python syntax in Lisp and Scheme

In article <kx8hb.3998$dn6 .3349@newsread4 .news.pas.earth link.net>, Andrew Dalke wrote:[color=blue]
> Daniel P. M. Silva:[color=green]
>> Do you know where I can find those studies? I'm very intested in their
>> findings :)[/color]
>
> Sure. The research was done for ABC. ABC's home page is
> http://homepages.cwi.nl/~steven/abc/
> ABC is an interactive programming language and environment for
> personal computing, originally intended as a good replacement for
> BASIC. It was designed by first doing a task analysis of the
> programming task.[/color]

Interestingly enough:

"The language is strongly-typed, but without declarations. Types are
determined from context."
- http://ftp.cwi.nl/abc/abc.intro

Sounds like type inference to me.

Also:

"There is no GOTO statement in ABC, and expressions do not have
side-effects."
- http://homepages.cwi.nl/~steven/abc/teaching.html

Hints both at the statement/expression dichotomy of Python and the issue
that side-effects make it difficult to reason about a program, one of the
most important assertions made by functional proponents (IMHO).

Dave

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :