From: Iban Hatchond
Subject: norme xj...
Date: 
Message-ID: <3A2E5704.BE850D00@emi.u-bordeaux.fr>
Hi,
I'm sure that somebody has already asked for it but does anybody know a
good (workink) link for reading the ainsi CL norme on-line ?
Because I've been looking for it since monday over the net but i only
found some 404 errors and some partial links but nothing about the
ehtire norme in HTML.
thanks

From: Kent M Pitman
Subject: Re: norme xj...
Date: 
Message-ID: <sfwpuj5v9i5.fsf@world.std.com>
Iban Hatchond <········@emi.u-bordeaux.fr> writes:

> I'm sure that somebody has already asked for it but does anybody know a
> good (workink) link for reading the ainsi CL norme on-line ?
> Because I've been looking for it since monday over the net but i only
> found some 404 errors and some partial links but nothing about the
> ehtire norme in HTML.

By norme, do you mean the specification ANSI CL?  The Common Lisp
HyperSpec (CLHS) from Harlequin/Xanalys is a derivative document of
that, and is customarily treated by the community as if it is itself
the standard (although very strictly speaking, this isn't so; the real
and true standard is technically available only in hardcopy, and only
from ANSI).  However, since CLHS was produced from the same sources
the difference is largely philosophical and legal, plus the slight
risk of some mechanical translation error in the homegrown software I
wrote to convert it to HTML for CLHS.

I don't find any obvious problem with the normal web links to CLHS.
Even the old link it was originally published under still works:
  http://www.harlequin.com/books/HyperSpec/FrontMatter/index.html
Though the proper modern link to that version (4) is:
  http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/index.html

- - - - 

In fact, there's a version 5 (published years ago) which is better
than version 4.  Not everyone knows about it, though I have made periodic
mention of it.  Perhaps this is a good time to repeat that mention.

First, it's not available for direct download from
Xanalys.  It comes as part of the LispWorks documentation (including
the documentation for their free Personal Edition) presently available
for download at Xanalys.
 http://www.xanalys.com/software_tools/downloads/index.html

The version number of CLHS is found in the first few lines of HTML
source of every page.  The differences are so minor that they are
largely not mentioned in the visible displayed part of the document.

Not everyone needs version 5, but some heavy users of CLHS may prefer it.
The main differences, as I recall, between version 4 and version 5 are:
 - the Java-based symbol lookup page went away.
   This was a controversial change for a few people, but I did it because
   Java was losing in lots of browsers at the time and I got tired of fielding
   bug reports.
 - the filenames/urls are dos 8.3 compatible (this saves a lot of disk space),
   and so probably work better on Macs since there were two filenames
   (out of 2300!) that were 32 characters instead of Mac maximum of 31
   which caused problems in versions 3 and 4 of CLHS.  Surprisingly, or
   perhaps not, this shortening of the url names in such a heavily 
   cross-referenced document also shortens download times and overall disk
   use by a noticeable amount!
 - the Master Index page contains important additional xrefs to 
   format ops and sharpsign macros, which are terribly hard to find in 
   older versions.
 - the background is white, not gray, in response to a request from someone
   who was dyslexic and told me, to my great surprise, that high contrast
   helps compensate for that problem and that it would be helpful if it were
   high-contrast by default.
From: Dr Nick Levine
Subject: Re: norme xj...
Date: 
Message-ID: <3A2E5A39.ED94AF25@anglia.ac.uk>
Iban Hatchond wrote:
> 
> Hi,
> I'm sure that somebody has already asked for it but does anybody know a
> good (workink) link for reading the ainsi CL norme on-line ?
> Because I've been looking for it since monday over the net but i only
> found some 404 errors and some partial links but nothing about the
> ehtire norme in HTML.
> thanks

Guessing that the French word "norme" might translate into English as
"standard"...

The standard itself, as published by ANSI, is not (afaik) available
online. Online representations which are close enough to the standard
for all intents and purposes, have been published by both Franz and
Xanalys. See for example
http://www.xanalys.com/software_tools/reference/HyperSpec/

I hope this answers your question.

- nick
From: Dr Nick Levine
Subject: Re: norme xj...
Date: 
Message-ID: <3A2E61F3.4EADFFB@anglia.ac.uk>
   Date: Wed, 06 Dec 2000 16:35:58 +0100
   From: Iban Hatchond <·············@emi.u-bordeaux.fr>
   
   Dr Nick Levine wrote:

   > Guessing that the French word "norme" might translate into English
as
   > "standard"...
   >

   Yes you're right but i forgot to ISPELL my post :')

   >
   > The standard itself, as published by ANSI, is not (afaik) available
   > online. Online representations which are close enough to the
standard
   > for all intents and purposes, have been published by both Franz and
   > Xanalys. See for example
   > http://www.xanalys.com/software_tools/reference/HyperSpec/
   >
   > I hope this answers your question.
   >
   > - nick

   Well it should but at least as part of a student project i have to
write a
   short paper on the most standard writting convention in common lisp
   like constant are always named +FOO+, global vars *BAR*, etc
   So the matter fact is that it is NOT easy to write such a paper
without the
   Ainsi Standard.
   If you have some advise you'll be welcome.

The standard won't help you, as conventions are not part of the
standard. 

Good books (eg "ANSI Common Lisp" by Paul Graham) will impart stylistic
and convention issues as they go, but you'll be lucky to find them in a
single part of the book. Other places to look would be online lecture
notes (a list was posted a few days ago) and also the ALU site
www.lisp.org if it's back up after yesterday's crash.

Searching through my own online lisp notes for the word "convention", I
found the following random collection, to which you are welcome. I
stress that it is not meant to be complete or even or whatever, it's
just stuff that occured to me while I was writing lisp lectures last
year.

All the best,

- nick
http://beta.csd.anglia.ac.uk/~nlevine/declarative/


* it is traditional for function definitions to be laid out [thus]
namely with defun, the function name and the argument list on one line,
and the body of the function starting on the next line 

* any lisp editor worth its salt will indent (the current line of) lisp
code correctly when you press the Tab key. Use it 

* if you have several parentheses together, keep them together, eg
))))))) or whatever. Do not separate them with spaces or newlines

* Note by the way the lisp coding convention that global variables have
a * at the beginning and end of their name. This makes them stand out in
your code. If the screen starts looking cluttered with all the asterisks
everywhere maybe you'll get the message and find another way of coding
it. 

* There is a convention that a :start argument to sequence functions
points to the first element in the subsequence and an :end argument
points to the element following the end of the subsequence. Brownie
points / smarties for telling me why.
 
* it quite often happens (when you have structures containing structures
containing ... etc.) that it all gets a bit much when it is printed out.
We will touch on this briefly later in the course, but for now note that
you can control how each type of structure prints. Just be aware that it
is possible to control this, and that by convention the output is
typically wrapped in #<  >. The reason for this is that the lisp reader
is programmed to signal an error whenever it sees #< and so you can
guarantee that once you've abandoned the baroque but re-readable #s
syntax, your output can never be inadvertently re-read into the image. 

* You may have noticed that a growing number of the macros we have met: 

     defun 
     defparameter 
     defconstant 
     defstruct 
     (and more to come)

have a something in common. They are known as defining macros (they
define global functions, global parameters, constants, structure types,
and so on) and by convention these macros - and no others - start with
the letters "def".
From: Joe Marshall
Subject: Re: norme xj...
Date: 
Message-ID: <aea77rq5.fsf@content-integrity.com>
Dr Nick Levine <········@anglia.ac.uk> writes:

> * There is a convention that a :start argument to sequence functions
> points to the first element in the subsequence and an :end argument
> points to the element following the end of the subsequence. Brownie
> points / smarties for telling me why.

So (- end start) = (length subsequence)

So that specifying a zero length subsequence has a natural form of
start = end.

So that the subsequent subsequence `starts' where the previous one
`ends'.

So that extending this notation into negative lengths has a natural
form. (This is not necessarily absurd: you could be doing arithmetic
on subsequence indices and have an intermediate result that has a
negative length or denormalized indices.)

Any other convention would require far more 1+ and 1- operations and
be more prone to fencepost errors.


Where are my brownies?





















-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Lieven Marchand
Subject: Re: norme xj...
Date: 
Message-ID: <m3r93ki29u.fsf@localhost.localdomain>
Dr Nick Levine <········@anglia.ac.uk> writes:

> * There is a convention that a :start argument to sequence functions
> points to the first element in the subsequence and an :end argument
> points to the element following the end of the subsequence. Brownie
> points / smarties for telling me why.

What did you expect as answer to this from your students? It is just a
convention that all sequence functions adhere to and the utility lies
in the uniformity that makes that you often can use the output of one
function as arguments to the start or end parameters of another. Other
conventions are possible and of equal value. The issue
RANGE-OF-START-AND-END-PARAMETERS seems to confirm that this
particular choice of convention was made because Symbolics already had
implemented it like that and no competing conventions were around.

-- 
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club