Python syntax in Lisp and Scheme

[james anderson]

i realize that this thread is hopelessly amorphous, but this post did
introduce some concrete issues which bear concrete responses...

Andrew Dalke wrote:
> 
> ...
> 
> 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?

there are several problems with a "uniform" unicode implementation. if you
look through the info-mcl archives you will find a thread where i tried to
achieve some clarity as to what was necessary. 

i got only as far as the realization that, in order to be of any use, unicode
data management has to support the eventual primitive string operations. which
introduces the problem that, in many cases, these primitive operations
eventually devolve to the respective os api. which, if one compares apple and
unix apis are anything but uniform. it is simply not possible to provide them
with the same data and do anything worthwhile. if it is possible to give some
concrete pointers to how other languages provide for this i would be grateful.

given this situation. i posted several suggestions as to how they might
represent unicode and effect encoding and decoding such that variations were
at least managed in a uniform manner. i received one (1) answer, to the effect
that "that sound's ok to me." so i left the implementation the way it was, to
signal an error upon discovering surrogate pairs. i've yet to have anyone
suggest that that impedes processing. to be quite honest, that surprises me
and i have no idea what people do with surrogate pairs. 

this is effectively the same level of support as java, and i have to admit, i
don't understand what people really do with them in java either. the string
representation is effectively utf-16, so anything outside of the base plane is
not a first-class object. in which environment the "consensus" above should
actually be better spelled "chimera". 

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

yes, there are several available common-lisp implementations for http clients
and servers. they offer significant trade-offs in api complexity,
functionality, resource requirements and performance. you do need to pick one
according to your application needs and declare which one you have chosen. for
a default implementation of client functionality, cl-xml, as any other lisp
application, must take into acount that some necesary stream and
network-related functions are available through implementation-specific
libraries only. again, as for other common-lisp libraries, for the
implementation to which it has been ported, it does this automatically.

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

if one needs to _port_ it to a new lisp, yes. perhaps you skipped over the
list of lisps to which it has been ported. if you look at the #+/-
conditionalization, you may observe that the differences are not significant.

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

it is refreshing, that you describe it as "your" confusion. there was one
correspondent who, at the outset, judging from their initial enquiries, was
looking at their first '(' ever, but wrote in short order about processing
12MB files. should one have problems using a given common lisp library,
concrete questions and illustrations of points which are unclear are always
more productive than vague chacterizations.

...