Hi there!
Darcs marks conflicts in a file with
************
^ ^ ^
v v v
but sbcl compiles such a file without warning. Is it ok?
E.g. lispworks warn that "variable assumed special"
In fact, it seem to be a bug, as
v
would lead to evaluation of v at load time, wouldn't it?
And v is an unbound variable.
With best regards, budden
On 16 oct, 12:59, budden <········@mtu-net.ru> wrote:
> Hi there!
> Darcs marks conflicts in a file with
> ************
> ^ ^ ^
> v v v
>
> but sbcl compiles such a file without warning. Is it ok?
>
> E.g. lispworks warn that "variable assumed special"
>
> In fact, it seem to be a bug, as
>
> v
>
> would lead to evaluation of v at load time, wouldn't it?
> And v is an unbound variable.
What is around that conflict marker? I'm guessing it's inside a string
or a comment, perhaps?
Certainly if you were to put the junk above in a file and compile it,
you would get warnings and compile-file would return T, T.
> What is around that conflict marker? I'm guessing it's inside a string
> or a comment, perhaps?
No. It is just verbatim:
v v v v v v
(code-1)
************
(code-2)
^ ^ ^ ^ ^ ^
In article
<····································@17g2000hsk.googlegroups.com>,
budden <········@mtu-net.ru> wrote:
> Hi there!
> Darcs marks conflicts in a file with
> ************
> ^ ^ ^
> v v v
>
> but sbcl compiles such a file without warning. Is it ok?
>
> E.g. lispworks warn that "variable assumed special"
>
> In fact, it seem to be a bug, as
>
> v
>
> would lead to evaluation of v at load time, wouldn't it?
> And v is an unbound variable.
>
> With best regards, budden
Since toplevel variable references do "do" anything, the compiler
probably just optimizes them away.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
> Since toplevel variable references do "do" anything, the compiler
> probably just optimizes them away.
Maybe, but warning would be useful anyway. It is not good that
compiler ignores a junk in a file. And it is especially inconvinient
with darcs.
From: Pascal J. Bourguignon
Subject: Re: Sbcl feature - symbol occuring at toplevel is not reported with warning
Date:
Message-ID: <7chc7ctzuj.fsf@pbourguignon.anevia.com>
budden <········@mtu-net.ru> writes:
>> Since toplevel variable references do "do" anything, the compiler
>> probably just optimizes them away.
> Maybe, but warning would be useful anyway. It is not good that
> compiler ignores a junk in a file. And it is especially inconvinient
> with darcs.
On the other hand, LOAD should signal errors on ^ and v...
And I'm not sure COMPILE-FILE is really entitled to remove errors...
If ^ and v were defined (in the file), then ok, COMPILE-FILE could
remove them.
But when they're not defined, evaluating them has some side effects,
so removing them is not semantically neutral.
--
__Pascal Bourguignon__
From: Thomas A. Russ
Subject: Re: Sbcl feature - symbol occuring at toplevel is not reported with warning
Date:
Message-ID: <ymid4i0fng9.fsf@blackcat.isi.edu>
budden <········@mtu-net.ru> writes:
> Hi there!
> Darcs marks conflicts in a file with
> ************
> ^ ^ ^
> v v v
>
> but sbcl compiles such a file without warning. Is it ok?
>
> E.g. lispworks warn that "variable assumed special"
>
> In fact, it seem to be a bug, as
>
> v
>
> would lead to evaluation of v at load time, wouldn't it?
> And v is an unbound variable.
Well, how can the compiler know that the variable would be unbound at
the time you load the file? Same thing for the variables ********* and
^, by the way. It is conceivable, even though unlikely, that you would
do something like:
(setq v "Hi!" *********** 3 ^ nil)
(load "my-file.fasl")
and then the (assumed) special variables would be bound. This is the
natural consequence of Lisp allowing the use of undeclared variables.
But in any case, most Lisp systems should print a warning or perhaps
note about assuming that the variables are special. I would expect sbcl
to do that, although if you are doing multiple such compiles in a
session, the first time those "variable" names were encountered, SBCL
would have globally proclaimed them special, thus making future
references to them no longer trigger any warnings.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Ari Johnson
Subject: Re: Sbcl feature - symbol occuring at toplevel is not reported with warning
Date:
Message-ID: <m2prlzn9n5.fsf@hermes.theari.com>
budden <········@mtu-net.ru> writes:
> Hi there!
> Darcs marks conflicts in a file with
> ************
> ^ ^ ^
> v v v
>
> but sbcl compiles such a file without warning. Is it ok?
>
> E.g. lispworks warn that "variable assumed special"
>
> In fact, it seem to be a bug, as
>
> v
>
> would lead to evaluation of v at load time, wouldn't it?
> And v is an unbound variable.
$ cat > test.lisp
v v v v v
(princ :one)
*********
(princ :two)
^ ^ ^ ^ ^
$ sbcl
* (compile-file "test")
; loading system definition from
; compiling file "/home/ari/test.lisp" (written 17 OCT 2008 12:08:28 AM):
; compiling V
; compiling V
; compiling V
; compiling V
; compiling V
; compiling (PRINC :ONE)
; compiling *********
; compiling (PRINC :TWO)
; compiling ^
; compiling ^
; compiling ^
; compiling ^
; compiling ^
; file: /home/ari/test.lisp
; in:
; *********
;
; caught WARNING:
; undefined variable: *********
; V
;
; caught WARNING:
; undefined variable: V
;
; caught WARNING:
; undefined variable: V
;
; caught WARNING:
; undefined variable: V
;
; caught WARNING:
; 2 more uses of undefined variable V
; file: /home/ari/test.lisp
; in:
; ^
;
; caught WARNING:
; undefined variable: ^
;
; caught WARNING:
; undefined variable: ^
;
; caught WARNING:
; undefined variable: ^
;
; caught WARNING:
; 2 more uses of undefined variable ^
;
; caught WARNING:
; These variables are undefined:
; ********* V ^
;
; compilation unit finished
; caught 10 WARNING conditions
; /home/ari/test.fasl written
; compilation finished in 0:00:00
#P"/home/ari/test.fasl"
T
T
*
Ten warnings is not quite "without warning." Interestingly, though,
the resulting test.fasl loads just fine, although loading test.lisp
directly hits an error on the first v.
Hmm, I need to take look at it again when I get home. Loaded it with C-
c C-k in SLIME.
This command compiles and loads file. Result was "0 errors, 0
warnings, 0 notes". Maybe
this is an issue with SLIME, not Sbcl.
On Oct 17, 11:32 am, budden <········@mtu-net.ru> wrote:
> Hmm, I need to take look at it again when I get home. Loaded it with C-
> c C-k in SLIME.
> This command compiles and loads file. Result was "0 errors, 0
> warnings, 0 notes". Maybe
> this is an issue with SLIME, not Sbcl.
No, was an issue with SBCL. I suspect Ari is running a not-very-recent
version of SBCL.
Fixed in 1.0.21.22.
(Apropos, bug-reports to sbcl-help or sbcl-devel are preferred: there
is no guarantee that issues mentioned on comp.lang.lisp are seen by
SBCL hackers. Note that sbcl-help is a fairly low-volume list, so it
won't fill your inbox.)
Cheers,
-- Nikodemus
> No, was an issue with SBCL. I suspect Ari is running a not-very-recent
> version of SBCL.
Ok
> Fixed in 1.0.21.22.
Yes, my version is 1.0.20.something
>
> (Apropos, bug-reports to sbcl-help or sbcl-devel are preferred: there
> is no guarantee that issues mentioned on comp.lang.lisp are seen by
> SBCL hackers. Note that sbcl-help is a fairly low-volume list, so it
> won't fill your inbox.)
Thanks, but I was unable to do that from my emal (due to spam
protection, likely). Didn't get time
to explore other ways to do so, but noticed that previous bug I
reported was fixed.