Python syntax in Lisp and Scheme

[Pascal Costanza]

Andrew Dalke wrote:

>>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.

So what's the result of ("one" - "two") then? ;)

> 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.

It's a myth that bytes are restricted to 8 bits. See 
http://www.wikipedia.org/wiki/Byte

> 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?

No, not yet. ANSI CL was finalized in 1994.

> 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?

Again, not part of ANSI CL. Don't judge a standardized language with the 
measures of a single-vendor language - that's a different subject. 
(Apart from that, Jython also doesn't provide everything that Python 
provides, right?)

Pick the one Common Lisp implementation that provides the stuff you 
need. If no Common Lisp implementation provides all the stuff you need, 
write your own libraries or pick a different language. It's as simple as 
that.

> 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.

You can ask these things in comp.lang.lisp or in one of the various 
mailing lists. Common Lispniks are generally very helpful.


Pascal

-- 
Pascal Costanza               University of Bonn
mailto:costanza at web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)