I'm getting a VERY weird result when runnig a block of code on my unix
system. I have Clisp running on both Windows and unix. On Windows, I get
sane behaviour, but on the unix system, I get wacky results. The piece
of code is:
(loop for pair in '((1 2) (3 4) (5 6))
do (let ((*d* (car pair))
(*h* (cadr pair)))
(format t "~A : ~A~%" *d* *h*)))
On Windows it prints:
--
1 : 2
3 : 4
5 : 6
--
But on the unix system it prints:
--
Display all 1679 possibilities? (y or n)
!
(... and then it prints a list of what looks like 1679 symbols, and then
prints...)
2 : 8
2 : 8
2 : 8
--
BTW, 2 and 8 were the inital values of *d* and *h* before the code was run.
Has anyone ever seen anything like this before? It seems like a bug in
Clisp to me, but I don't want to jump to conclusions.
Lowell
Lowell <······@cs.ubc.ca> writes:
> But on the unix system it prints:
> --
> Display all 1679 possibilities? (y or n)
that must be the shell responding - it is probably trying to expand *d*
for you, and your current directory has 1679 files with d in their name (?)
--
(espen)
Lowell <······@cs.ubc.ca> writes:
> But on the unix system it prints:
> --
> Display all 1679 possibilities? (y or n)
> !
> (... and then it prints a list of what looks like 1679 symbols, and
> then prints...)
My guess is that you cut-n-pasted the code at some stage, and you have
some TABs causing strange behaviour ... though quite how the UNIX
shell gets involved (for that is what the "Display all possibilities"
message looks like), is a complete mystery to me.
How _exactly_ are you running this code? As a script? interactively in
the Clisp "shell"? via Ilisp & Emacs?
If you did cut-n-paste it straight into the Clisp REPL, then you could
try typing the code in by hand (making sure to avoid hitting TAB).
Here's what happens if I mouse-copy-n-paste the code from your
article, followed by typing it by hand (directly into the Clisp
"shell"):
[1]> (loop for pair in '((1 2) (3 4) (5 6))
do (let ((*d* (car pair))
*** - POSITION: :START = 1 should not be greater than :END = 0
1. Break [2]>
[3]> (loop for pair in '((1 2) (3 4) (5 6))
do (let ((*d* (car pair))
(*h* (cadr pair)))
(format t "~a : ~a~%" *d* *h*)))
1 : 2
3 : 4
5 : 6
NIL
Now, if I fire up a fresh emacs, and run run Clisp in there, I can
copy-n-paste from your article without any problems
[2]> (loop for pair in '((1 2) (3 4) (5 6))
do (let ((*d* (car pair))
(*h* (cadr pair)))
(format t "~A : ~A~%" *d* *h*)))
1 : 2
3 : 4
5 : 6
NIL
This is Clisp 2.30
Now, if I try clisp 2.29 ...
I type "(loop for pair in '((1 2) (3 4) (5 6)) RET TAB"
and at that point I get "Display all 1250 possibilities? (y or n)".
Hmmmmm ....
Clisp 2.29, Mac OS X (BSD):
with-open-fi<TAB> --> expands to "with-open-file"
Trying the same on Clisp 2.30, Linux:
[1]> with-open-fiSegmentation fault
Is this a local problem, or do others experiencse this with Clisp 2.30
on UNIX-like systems ?
Hi Jacek Generowicz,
> Hmmmmm ....
>
> Clisp 2.29, Mac OS X (BSD):
>
> with-open-fi<TAB> --> expands to "with-open-file"
>
> Trying the same on Clisp 2.30, Linux:
>
> [1]> with-open-fiSegmentation fault
>
> Is this a local problem, or do others experiencse this with Clisp 2.30
> on UNIX-like systems ?
<http://bugs.debian.org/183796>
Lowell <······@cs.ubc.ca> writes:
> I'm getting a VERY weird result when runnig a block of code on my unix
> system.
[snip]
Repeat what you have done, but invoke good CLisp with the -I option
(which means 'be ilisp-friedly') or try to eliminate all tabs.
Clisp has tab-completion on symbols. So if you type
(do<tab>
you get a nice litle list with all symbols starting with
do. Unfortunately, if you hit a tab out of the blue, it... well,
completes '' and shows every available symbol in the current
package. Thus, when you paste code into a console with clisp, or if
ilisp transfers tabs to the "inferior"[1] clisp, it tends to do these
whacky things you have observed.
Hope it helps,
Mario.
[1] Shouldn't we ask the emacs/xemacs folks someday to stop being
silly?
Mario S. Mommer <········@yahoo.com> writes:
> [1] Shouldn't we ask the emacs/xemacs folks someday to stop being
> silly?
No. If there's a tab in my file and I copy it into another file, I
want it to remain a tab and not get magically turned into some other
kind of whitespace. Imagine the trouble you'd have cutting and
pasting bits of Makefile if that happened.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
On Tue, 26 Aug 2003 17:31:43 +0100, Daniel Barlow <···@telent.net> wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>
> > [1] Shouldn't we ask the emacs/xemacs folks someday to stop being
> > silly?
>
> No. If there's a tab in my file and I copy it into another file, I
> want it to remain a tab and not get magically turned into some other
> kind of whitespace. Imagine the trouble you'd have cutting and
> pasting bits of Makefile if that happened.
I think the footnote wasn't about the TAB issue but about the fact
that Emacs calls Common Lisp an "inferior" Lisp.
Edi.
Edi Weitz <···@agharta.de> writes:
> On Tue, 26 Aug 2003 17:31:43 +0100, Daniel Barlow <···@telent.net> wrote:
>
> > Mario S. Mommer <········@yahoo.com> writes:
> >
> > > [1] Shouldn't we ask the emacs/xemacs folks someday to stop being
> > > silly?
> >
> > No. If there's a tab in my file and I copy it into another file, I
> > want it to remain a tab and not get magically turned into some other
> > kind of whitespace. Imagine the trouble you'd have cutting and
> > pasting bits of Makefile if that happened.
>
> I think the footnote wasn't about the TAB issue but about the fact
> that Emacs calls Common Lisp an "inferior" Lisp.
Well, I always understood inferior to denote location, as well as
value.
Looking at webster, I see that the usage is the first one there:
1 : situated lower down : LOWER
which I suppose came to have social implications and so on. Kind of
like "gentleman" coming to mean a person of higher quality, rather
than just "landowner," which would render one of my favorite of
Chesterton's poems incomprehensible: "For the devil is a gentleman,
and doesn't keep his word." (The Aristocrat).
--
Fred Gilham ······@csl.sri.com
Is, then, the loving cup so often filled
that we may toss a draught aside?....
-Jeff Iverson
Fred Gilham wrote:
> Looking at webster, I see that the usage is the first one there:
>
> 1 : situated lower down : LOWER
>
> which I suppose came to have social implications and so on. Kind of
> like "gentleman" coming to mean a person of higher quality, rather
> than just "landowner," which would render one of my favorite of
> Chesterton's poems incomprehensible: "For the devil is a gentleman,
> and doesn't keep his word." (The Aristocrat).
It's surely precisely because the word "gentleman" had,
at least, overtones of person-of-higher-quality-ness
that Chesterton wrote that; his sarcasm would lose its
point if all he were saying were "For the devil is a
landowner, and doesn't keep his word". I suspect that
when GKC was writing, "gentleman" could be decently
paraphrased as "a member of the upper social classes,
with the concomitant social graces", and he was making
a point about the difference between the social
graces that *actually* accompany membership of the
privileged classes and those that are *supposed* to.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> It's surely precisely because the word "gentleman" had, at least,
> overtones of person-of-higher-quality-ness that Chesterton wrote
> that; his sarcasm would lose its point if all he were saying were
> "For the devil is a landowner, and doesn't keep his word". I suspect
> that when GKC was writing, "gentleman" could be decently paraphrased
> as "a member of the upper social classes, with the concomitant
> social graces", and he was making a point about the difference
> between the social graces that *actually* accompany membership of
> the privileged classes and those that are *supposed* to.
You're of course right.
I doubt I'm the one to be lecturing someone named Gareth McCaughan on
Chesterton, you're certainly closer to the situation than I am. :-)
Anyway I meant that the word started out meaning landowner, and wound
up meaning someone who acted a certain way. Similarly for inferior.
--
Fred Gilham ······@csl.sri.com
It's not when people notice you're there that they pay attention; it's
when they notice you're *still* there. --- Paul Graham
Fred Gilham wrote:
[apropos my pontifications on G K Chesterton]
> I doubt I'm the one to be lecturing someone named Gareth McCaughan on
> Chesterton, you're certainly closer to the situation than I am. :-)
Very kind of you to say so, but I'm not sure what my
name has to do with it... (Random guess: perhaps you're
mixing up Shaw and Chesterton? Shaw was Irish.)
> Anyway I meant that the word started out meaning landowner, and wound
> up meaning someone who acted a certain way. Similarly for inferior.
Yes. This sort of change of meaning (status --> behaviour, via
snobbery) is quite common. "Villain", "knave", "frank".
--
Gareth McCaughan
.sig under construc
Daniel Barlow <···@telent.net> writes:
> Mario S. Mommer <········@yahoo.com> writes:
>
> > [1] Shouldn't we ask the emacs/xemacs folks someday to stop being
> > silly?
>
> No. If there's a tab in my file and I copy it into another file, I
> want it to remain a tab and not get magically turned into some other
> kind of whitespace. Imagine the trouble you'd have cutting and
> pasting bits of Makefile if that happened.
Now try catting your Makwefile in an xterm and cut&paste from there.
You are suddenly unsure if what gets pasted is spaces or tabs.
//Ingvar (the results this has for python-the-language is...)
--
(defun m (f)
(let ((db (make-hash-table :key #'equal)))
#'(lambda (&rest a)
(or (gethash a db) (setf (gethash a db) (apply f a))))))
From: ·············@comcast.net
Subject: Re: VERY strange behaviour with Clisp
Date:
Message-ID: <he43z067.fsf@comcast.net>
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Daniel Barlow <···@telent.net> writes:
>
>> Mario S. Mommer <········@yahoo.com> writes:
>>
>> > [1] Shouldn't we ask the emacs/xemacs folks someday to stop being
>> > silly?
>>
>> No. If there's a tab in my file and I copy it into another file, I
>> want it to remain a tab and not get magically turned into some other
>> kind of whitespace. Imagine the trouble you'd have cutting and
>> pasting bits of Makefile if that happened.
>
> Now try catting your Makefile in an xterm and cut&paste from there.
> You are suddenly unsure if what gets pasted is spaces or tabs.
That's part of the charm of using Make, though!
Hi Lowell,
> I'm getting a VERY weird result when runnig a block of code on my unix
> system. I have Clisp running on both Windows and unix. On Windows, I get
> sane behaviour, but on the unix system, I get wacky results. The piece
> of code is:
>
> (loop for pair in '((1 2) (3 4) (5 6))
> do (let ((*d* (car pair))
> (*h* (cadr pair)))
> (format t "~A : ~A~%" *d* *h*)))
Try this instead:
(loop for pair in '((1 2) (3 4) (5 6))
do (let ((*d* (car pair))
(*h* (cadr pair)))
(format t "~A : ~A~%" *d* *h*)))
You can't paste in TAB characters (they interact with readline). If you
are using Emacs select the code and M-x untabify it first.
Regards,
Adam
Hi Lowell,
... (let ((*d* (car pair))
(*h* (cadr pair))) ...
BTW, *d* and *h* are lexical variables. According to Lisp style they
should not be surrounded by *...* unless they are dynamic (global) in
nature.
Improving your original code:
(loop for (a b) in '((1 2) (3 4) (5 6))
do (format t "~A : ~A~%" a b))
(I was a little surprised it worked!)
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Hi Lowell,
>
> ... (let ((*d* (car pair))
> (*h* (cadr pair))) ...
>
> BTW, *d* and *h* are lexical variables.
How do you know that they are lexical variables?
Lowell seems to be giving you a big hint that they are special.
* (defvar *x* 1)
*X*
* (let ((*x* 2))
*x*)
2
* *x*
1
Anything wrong with the "style" of the above ?
Jacek Generowicz <················@cern.ch> writes:
> > BTW, *d* and *h* are lexical variables.
>
> How do you know that they are lexical variables?
>
> Lowell seems to be giving you a big hint that they are special.
>
>
> * (defvar *x* 1)
> *X*
> * (let ((*x* 2))
> *x*)
> 2
> * *x*
> 1
>
> Anything wrong with the "style" of the above ?
Maybe the following, is a bit more illuminating:
* (defun foo () (print *x*))
FOO
* (defvar *x* 1)
*X*
* (let ((*x* 2)) (foo))
2
2
* *x*
1
Hi Jacek Generowicz,
> Adam Warner <······@consulting.net.nz> writes:
>
>> Hi Lowell,
>>
>> ... (let ((*d* (car pair))
>> (*h* (cadr pair))) ...
>>
>> BTW, *d* and *h* are lexical variables.
>
> How do you know that they are lexical variables?
>
> Lowell seems to be giving you a big hint that they are special.
Perhaps. Lowell is a new Lisper and was creating bindings within a local
context. Within this context the use of single letters to denote the
elements of the list was clear and concise. Nondescript single letters
that denoted variables with global significance was not (e.g. what is the
significance of a variable named *d*? Within the local context *d* is
understood as the first element of a list. We couldn't even begin to guess
at its global significance, unlike special variables with descriptive
names such as *default-float-format*).
Thank you for correcting my misstatement. Clearly without whole program
analysis it is not possible to state with any certainly that any code
snippet uses lexical variables.
Regards,
Adam
Just to make things clear: *d* and *h* are intended to be special
variables. I did not put the stars there by accident. The code snippet I
originally posted might be a little misleading because I'm using special
variables for no apparent purpose. My "real" code is actually more
complicated than what I posted, but I simplified it as much as possible
to keep my post simple.
Thanks for all the elp guys,
Lowell
Adam Warner wrote:
> Hi Jacek Generowicz,
>
>
>>Adam Warner <······@consulting.net.nz> writes:
>>
>>
>>>Hi Lowell,
>>>
>>>... (let ((*d* (car pair))
>>> (*h* (cadr pair))) ...
>>>
>>>BTW, *d* and *h* are lexical variables.
>>
>>How do you know that they are lexical variables?
>>
>>Lowell seems to be giving you a big hint that they are special.
>
>
> Perhaps. Lowell is a new Lisper and was creating bindings within a local
> context. Within this context the use of single letters to denote the
> elements of the list was clear and concise. Nondescript single letters
> that denoted variables with global significance was not (e.g. what is the
> significance of a variable named *d*? Within the local context *d* is
> understood as the first element of a list. We couldn't even begin to guess
> at its global significance, unlike special variables with descriptive
> names such as *default-float-format*).
>
> Thank you for correcting my misstatement. Clearly without whole program
> analysis it is not possible to state with any certainly that any code
> snippet uses lexical variables.
>
> Regards,
> Adam
From: Jacek Generowicz
Subject: Special variable namespace [Was: VERY strange behaviour with Clisp]
Date:
Message-ID: <tyfoeyc7cym.fsf_-_@pcepsft001.cern.ch>
Adam Warner <······@consulting.net.nz> writes:
> Clearly without whole program analysis it is not possible to state
> with any certainly that any code snippet uses lexical variables.
Indeed. And in order to help, we have the "stars notation", which
amounts to creating a separate namespace for special variables, by
convention.
This makes me wonder whether a special variable namespace has ever
been considered, perhaps even by X3J13, how it might work, and what
issues would arise. Or maybe some other means of linguistically
separating lexical and special variables.
I guess elisp has this to some extent, with its lexical-let.
Jacek Generowicz wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
> > Clearly without whole program analysis it is not possible to state
> > with any certainly that any code snippet uses lexical variables.
>
> Indeed. And in order to help, we have the "stars notation", which
> amounts to creating a separate namespace for special variables, by
> convention.
>
> This makes me wonder whether a special variable namespace has ever
> been considered, perhaps even by X3J13, how it might work, and what
> issues would arise.
The first issue that would arise is how you would distinguish those names
from names in other namespaces. It's rather different from the Lisp2
function/value issue. Surely every reference to such a name would need to
be identified as such? I suppose it could be done indirectly, like this:
> I guess elisp has this to some extent, with its lexical-let.
But I would have thought it's better to identify the variable directly,
rather than require different special forms for different types of variable.
This then leads to replacing *x* with something like a qualified or compound
name that the compiler recognizes, rather than a simple human convention.
That may not be a bad idea, but isn't the logical conclusion of it simply
having N namespaces, perhaps supporting a hierarchical organization, which
would support qualified names of the form n.x, with appropriate defaulting
mechanisms so that the namespace qualifier can be omitted in certain
circumstances? That way you wouldn't be limited to a single namespace for
special variables, or for any other variables, whatever their color or
creed.
Anton
From: Jacek Generowicz
Subject: Re: Special variable namespace [Was: VERY strange behaviour with Clisp]
Date:
Message-ID: <tyfk78y2gxg.fsf@pcepsft001.cern.ch>
"Anton van Straaten" <·····@appsolutions.com> writes:
> The first issue that would arise is how you would distinguish those names
> from names in other namespaces. It's rather different from the Lisp2
> function/value issue.
Indeed.
> Surely every reference to such a name would need to be identified as
> such?
Yes, which is what the astrerisk convention is trying to achieve. I'm
wondering whether/how one could promote this from being a mere
convention to a language-supported distinction.
With the asterisks in place, the following looks normal:
* (defun make-adder (*x*)
(lambda (n) (+ *x* n)))
MAKE-ADDER
* (funcall (make-adder 3) 4)
5
Without the asterisks, the behaviour would be _very_ puzzling, though
legal. Are there any other instances (in CL) where different semantics
are indicated only by a convention ?
> I suppose it could be done indirectly, like this:
>
> > I guess elisp has this to some extent, with its lexical-let.
>
> But I would have thought it's better to identify the variable directly,
> rather than require different special forms for different types of variable.
>
> This then leads to replacing *x* with something like a qualified or compound
> name that the compiler recognizes, rather than a simple human convention.
Paul Foley has pointed out, off-list, that Islisp has a dynamic-let
for binding, and a (dynamic foo) for accessing, and that the asterisk
convention is still used, apparently.
> That may not be a bad idea, but isn't the logical conclusion of it simply
> having N namespaces, perhaps supporting a hierarchical organization, which
> would support qualified names of the form n.x, with appropriate defaulting
> mechanisms so that the namespace qualifier can be omitted in certain
> circumstances? That way you wouldn't be limited to a single namespace for
> special variables, or for any other variables, whatever their color or
> creed.
Are you suggesting that one place dynamic variables in a dynamic
variable namespace, by convention, or that the language make all
variables in a given namespace be dynamic ?
Jacek Generowicz <················@cern.ch> writes:
> With the asterisks in place, the following looks normal:
>
> * (defun make-adder (*x*)
> (lambda (n) (+ *x* n)))
> MAKE-ADDER
> * (funcall (make-adder 3) 4)
> 5
>
> Without the asterisks, the behaviour would be _very_ puzzling, though
> legal. Are there any other instances (in CL) where different semantics
> are indicated only by a convention ?
Sure, `WITH-' forms are invariably macros.
Jacek Generowicz wrote:
> Paul Foley has pointed out, off-list, that Islisp has a dynamic-let
> for binding, and a (dynamic foo) for accessing, and that the asterisk
> convention is still used, apparently.
That's what I would expect, because there are still reasons to identify the
variables themselves.
> > That may not be a bad idea, but isn't the logical conclusion of it
simply
> > having N namespaces, perhaps supporting a hierarchical organization,
which
> > would support qualified names of the form n.x, with appropriate
defaulting
> > mechanisms so that the namespace qualifier can be omitted in certain
> > circumstances? That way you wouldn't be limited to a single namespace
for
> > special variables, or for any other variables, whatever their color or
> > creed.
>
> Are you suggesting that one place dynamic variables in a dynamic
> variable namespace, by convention, or that the language make all
> variables in a given namespace be dynamic ?
I think either approach might work, and there may also be other
alternatives, including being able to tag a namespace as being dynamic or
otherwise. My main point is that if you're going to identify certain kinds
of variables with some kind of "language-supported distinction", then there
may be other kinds of variables which also would benefit from being
identified in this way. Further, some of this identification might be
application-specific. A suitably designed namespace system could support
all of this. I think it would be better to provide a general system that
can support the desired identification, than to come up with a solution
which applies only to a particular kind of variable.
Anton
From: Jacek Generowicz
Subject: Re: Special variable namespace [Was: VERY strange behaviour with Clisp]
Date:
Message-ID: <tyf65kg3k85.fsf@pcepsft001.cern.ch>
"Anton van Straaten" <·····@appsolutions.com> writes:
> My main point is that if you're going to identify certain kinds of
> variables with some kind of "language-supported distinction", then
> there may be other kinds of variables which also would benefit from
> being identified in this way. Further, some of this identification
> might be application-specific. A suitably designed namespace system
> could support all of this. I think it would be better to provide a
> general system that can support the desired identification, than to
> come up with a solution which applies only to a particular kind of
> variable.
And a good point it is. Thanks for making it. Should I infer from the
relative silence on this point, that such a mechanism has not been
considered much, in the history of Lisp?
Jacek Generowicz <················@cern.ch> writes:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>> My main point is that if you're going to identify certain kinds of
>> variables with some kind of "language-supported distinction", then
>> there may be other kinds of variables which also would benefit from
>> being identified in this way.
>
> And a good point it is. Thanks for making it. Should I infer from
> the relative silence on this point, that such a mechanism has not
> been considered much, in the history of Lisp?
No, it gets kicked around from time to time. The real reason behind
the silence is that a proposed mechanism would `solve' something that
doesn't really need a solution. Accidentally binding a special
variable lexically only happens once: then you learn to put stars on
the specials and it never happens again. (And if you can't learn
*that* lesson, you surely can't learn a new piece of syntax).
Putting %% in front of a `unsafe' function is common, too, but it
hardly needs to be enforced mechanistically.
Any mechanism that you come up with would have to be more convenient
than adding a special character to a symbol, and that's pretty
convenient.
I can imagine a lisp system that looked for asterisks, though:
(defvar foobar nil)
; Warning: special variable FOOBAR doesn't have asterisks.
Joe Marshall <···@ccs.neu.edu> writes:
> I can imagine a lisp system that looked for asterisks, though:
>
> (defvar foobar nil)
>
> ; Warning: special variable FOOBAR doesn't have asterisks.
Note to any lisp implementor considering this - a full warning would
be pretty objectionable as it would cause compile-file to return
failure. This is what style-warnings are for
* (let ((*foo* 1)) (list *foo*))
; in: LAMBDA NIL
; (LET ((*FOO* 1))
; (LIST *FOO*))
;
; caught STYLE-WARNING:
; using the lexical binding of the symbol *FOO*, not the
; dynamic binding, even though the symbol name follows the usual naming
; convention (names like *FOO*) for special variables
; compilation unit finished
; caught 1 STYLE-WARNING condition
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Sam Steingold
Subject: Re: VERY strange behaviour with Clisp
Date:
Message-ID: <ufzjivoxr.fsf@gnu.org>
> * In message <············@mughi.cs.ubc.ca>
> * On the subject of "VERY strange behaviour with Clisp"
> * Sent on Tue, 26 Aug 2003 02:27:33 -0700
> * Honorable Lowell <······@cs.ubc.ca> writes:
>
> Display all 1679 possibilities? (y or n)
<http://clisp.cons.org/faq.html#rl-tab>
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Please wait, MS Windows are preparing the blue screen of death.