Python syntax in Lisp and Scheme

[Andrew Dalke]

Doug Tolton:
> 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.

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!  :)

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

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 "programmers 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 at dalkescientific.com