From: Mark Tarver
Subject: Lambda Associates is restored
Date: 
Message-ID: <1171632613.656473.158610@a75g2000cwd.googlegroups.com>
Some of you may have noticed that Lambda Associates went down on the
8th February.   This was due to a problem with a Fasthosts
registration account which contained some defunct information. Tracing
the problem and correcting it from India took some time. However the
site is up again and there should be no further problems.

bw


Mark

From: Lars Rune Nøstdal
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <pan.2007.02.16.16.00.34.175187@gmail.com>
On Fri, 16 Feb 2007 05:30:13 -0800, Mark Tarver wrote:

> Some of you may have noticed that Lambda Associates went down on the
> 8th February.   This was due to a problem with a Fasthosts
> registration account which contained some defunct information. Tracing
> the problem and correcting it from India took some time. However the
> site is up again and there should be no further problems.

Just noticed something at http://www.lambdassociates.org/qilisp.htm

..in the section `Abstractions' wouldn't..

  ((lambda (x) x) 7)

..be less verbose than..

  (funcall (function (lambda (x) x)) 7)

..?


Same below..

  (DEFUN *n (N L)
    (MAPCAR (FUNCTION (LAMBDA (X) (* N X))) L))

..could be..

  (defun *n (n list)
    (mapcar (lambda (x) (* n x)) list))

..without the `function'-thing.


-- 
Lars Rune Nøstdal
http://nostdal.org/
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <er5oa2$mdq$1@registered.motzarella.org>
Lars Rune Nøstdal schrieb:
 > On Fri, 16 Feb 2007 05:30:13 -0800, Mark Tarver wrote:
 >
 >> Some of you may have noticed that Lambda Associates went down on the
 >> 8th February.   This was due to a problem with a Fasthosts
 >> registration account which contained some defunct information. Tracing
 >> the problem and correcting it from India took some time. However the
 >> site is up again and there should be no further problems.
 >
 > Just noticed something at http://www.lambdassociates.org/qilisp.htm
 >
 > ..in the section `Abstractions' wouldn't..
 >
 >   ((lambda (x) x) 7)
 >
 > ..be less verbose than..
 >
 >   (funcall (function (lambda (x) x)) 7)
 >
 > ..?

Yes right.
And the section "Functions" says:
"Unlike Lisp, Qi is case-sensitive, so b and B are not treated as the same."
This should be corrected into something like:
"Unlike Lisp, Qi is not case-translating, [...]".


 > Same below..
 >
 >   (DEFUN *n (N L)
 >     (MAPCAR (FUNCTION (LAMBDA (X) (* N X))) L))
 >
 > ..could be..
 >
 >   (defun *n (n list)
 >     (mapcar (lambda (x) (* n x)) list))
 >
 > ..without the `function'-thing.



While you are at it - this is how it is done in Qi which looks even nicer:

(define *n
   N L -> (map (/. X (* N X)) L))


But shouldn't that be the same as:

(define *n
   N L -> (map (* N) L))  ; curried X away



André
-- 
From: Ken Tilton
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <6lxBh.226$2U7.80@newsfe10.lga>
André Thieme wrote:
> Lars Rune Nøstdal schrieb:

> This should be corrected into something like:
> "Unlike Lisp, Qi is not case-translating, [...]".

This should be translated into something like:
"Like modern Lisp, Qi is not case-translating..."

:)

kxo

-- 
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
                                   -- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
                                   -- Elwood's Mom
From: Mark Tarver
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <1171704771.560568.258170@h3g2000cwc.googlegroups.com>
> While you are at it - this is how it is done in Qi which looks even nicer:
>
> (define *n
>    N L -> (map (/. X (* N X)) L))
>
> But shouldn't that be the same as:
>
> (define *n
>    N L -> (map (* N) L))  ; curried X away
>
> André
> --

Yes; either will work in Qi.

By stating that unlike Lisp, Qi is case sensitive; I was cleaving to
the older standards in which
(EQ 'a 'A) returned T by default.  Lisp is not of course
constitutionally case insensitive, rather that it was normal until
recently for the default setting to be that case was to be ignored. It
seems that this is ceasing to be normal practice.  Clisp 2004
certainly is case insensitive.  From memory
I think Allegro is not.

http://www.cl.cam.ac.uk/ailanguages/allegro5/case.htm contains a
discussion of the issue.
From: ··@codeartist.org
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <1171714382.818923.12390@m58g2000cwm.googlegroups.com>
On 17 Feb., 10:32, "Mark Tarver" <··········@ukonline.co.uk> wrote:
> By stating that unlike Lisp, Qi is case sensitive; I was cleaving to
> the older standards in which
> (EQ 'a 'A) returned T by default.  Lisp is not of course
> constitutionally case insensitive, rather that it was normal until
> recently for the default setting to be that case was to be ignored. It
> seems that this is ceasing to be normal practice.  Clisp 2004
> certainly is case insensitive.  From memory
> I think Allegro is not.

Thats not quite true. ANSI Common Lisp was never case insensitive, but
as others noted it was (by default) case translating (READTABLE-
CASE :UPCASE). Case sensitive ANSI Common Lisp Code was always
possible by setting READTABLE-CASE of a readtable to :PRESERVE.

The issue which "modern Lisp" try to solve is not to provide case
sensitivity, but to make the standard Common Lisp symbols available in
downcased variants. Allegro CLs modern mode is motivated by using it
in situations like interfacing foreign languages. When interfacing
foreign languages like Java or C one often had to use strings (or ||-
escaped symbols), because this languages have case sensitive
identifiers. Common Lisp, being case translating by default, loses
case information and makes using normal symbols to denote foreign
identifiers more difficult.

Current CLISP versions (I don't know about CLISP from 2004) provide
case sensitive packages, which is IMHO a much better solution than
AllegroCLs case sensitive non-ANSI images.

What I would want is not a case sensitive mode, but a case preserving
mode where I can reference symbols from the Common Lisp package in any
case I want (but they are printed in lower case). I think choosing
things like this per package would be the right thing to do.

ciao,
Jochen
From: ······@corporate-world.lisp.de
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <1171715580.400034.307940@h3g2000cwc.googlegroups.com>
On 17 Feb., 13:13, ·····@codeartist.org" <····@codeartist.org> wrote:
> On 17 Feb., 10:32, "Mark Tarver" <··········@ukonline.co.uk> wrote:
>
> > By stating that unlike Lisp, Qi is case sensitive; I was cleaving to
> > the older standards in which
> > (EQ 'a 'A) returned T by default.  Lisp is not of course
> > constitutionally case insensitive, rather that it was normal until
> > recently for the default setting to be that case was to be ignored. It
> > seems that this is ceasing to be normal practice.  Clisp 2004
> > certainly is case insensitive.  From memory
> > I think Allegro is not.
>
> Thats not quite true. ANSI Common Lisp was never case insensitive, but
> as others noted it was (by default) case translating (READTABLE-
> CASE :UPCASE). Case sensitive ANSI Common Lisp Code was always
> possible by setting READTABLE-CASE of a readtable to :PRESERVE.
>
> The issue which "modern Lisp" try to solve is not to provide case
> sensitivity, but to make the standard Common Lisp symbols available in
> downcased variants. Allegro CLs modern mode is motivated by using it
> in situations like interfacing foreign languages. When interfacing
> foreign languages like Java or C one often had to use strings (or ||-
> escaped symbols),

Or read macros (like in MCL or OpenMCL) or translation rules
(examples: "foo-bar"
translates to "FooBar").

> because this languages have case sensitive
> identifiers. Common Lisp, being case translating by default, loses
> case information and makes using normal symbols to denote foreign
> identifiers more difficult.
>
> Current CLISP versions (I don't know about CLISP from 2004) provide
> case sensitive packages, which is IMHO a much better solution than
> AllegroCLs case sensitive non-ANSI images.
>
> What I would want is not a case sensitive mode, but a case preserving
> mode where I can reference symbols from the Common Lisp package in any
> case I want (but they are printed in lower case). I think choosing
> things like this per package would be the right thing to do.
>
> ciao,
> Jochen
From: Rob Warnock
Subject: Re: Lambda Associates is restored
Date: 
Message-ID: <ebWdnZ56OriXekrYnZ2dnUVZ_oqmnZ2d@speakeasy.net>
··@codeartist.org <··@codeartist.org> wrote:
+---------------
| Thats not quite true. ANSI Common Lisp was never case insensitive,
| but as others noted it was (by default) case translating (READTABLE-
| CASE :UPCASE). Case sensitive ANSI Common Lisp Code was always
| possible by setting READTABLE-CASE of a readtable to :PRESERVE.
+---------------

But awkward, since you then hae to SHOUT all the symbols in the
COMMON-LISP package. Many people find that readtable-case :INVERT
is much nicer [especially given the default interaction with the
printer]:

    > :hello

    :HELLO
    > (setf (readtable-case *readtable*) :invert)

    :invert
    > :hello

    :hello
    > (eq 'cl:car 'car)

    t
    > '(hello Hello HELLO)

    (hello Hello HELLO)
    > (cadr *)

    Hello
    > (mapcar 'symbol-name **)

    ("HELLO" "Hello" "hello")
    > 

Pretty much everything still "just works", especially if
you're careful to use keywords or uninterned symbols as
string or package designators instead of all-caps strings.


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607