gmane.lisp.common-lisp.implementation-hackers

LOOP non-compliance

Juan Jose Garcia-Ripoll — 2012-04-08T08:35:11

This is probably a silent cry in the woods and nobody will listen, but
could other implementations please warn users that there is a precise order
of statements in LOOP?

http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm

There are a lot of libraries out there which are being developed by
implementations that do not care whether (LOOP WHILE ... FOR I = ...) is a
valid or not, and this is at least affecting users of one implementation
that does (ECL).

You might say that it is up to the users to learn the Standard, but in
practice implementations may create a false impression that certain things
are ok, specially when those deviations are not explicit by the
implementation.

Juanjo

Declarations in compilers (feedback welcome)

Juan Jose Garcia-Ripoll — 2011-12-29T10:24:37

After struggling mentally with this for a few weeks, I would like to have
some consultation before I introduce some changes in ECL -- not that I
expect many users here, but at least some implementor-fellows and power
users of other implementations.

My concerns right now relate to how declarations should be used by a
compiler, and in particular how declarations interact with SAFETY levels.
Please correct me if I am wrong, but I have seen more or less the following
approaches

[a]- Most implementations blindly believe declarations below a certain
safety level. Above it, they seem more or less useless.

[b]- SBCL takes declarations (and THE) as type assertions. For instance, in
(LET ((Y (FOO X))) (DECLARE (FIXNUM Y))) ...) the assignment to Y would be
checked to be a FIXNUM. This means the type declaration is actually
enforced and believed and only at SAFETY 0 the checks are dropped (*)

In both cases one ends up with a model in which in order to truly believe a
declaration and have no extra burden (assertions), one has to drop to
SAFETY 0 in all code that is involved with it, which is a mess, because it
might inadvertently affect other parts of the code. It is for this reason
that I am considering an alternative model for ECL which would grade safety
as follows

- Type declarations are always believed
- SAFETY >= 1 adds type checks to enforce them.
- SAFETY = 0, no checks.
- SAFETY = 1, the special form THE or additional proclamations on the
functions can be used to deactivate the check. As in (LET ((Y (THE FIXNUM
(FOO X))) ...)

This would allow one to keep most code safe, while deactivating some checks
when they are really known to be true (**). Do you think this is
useful/useless? The problem I see with this approach is that all code
around is written for model [a] or [b], but I could not come up with
something more sensible so far.

Juanjo

(*) Actually the checks are also deactivated when SBCL can infer the type
of the value that is assigned to Y. This is somewhat contradictory, because
(SETF Y (THE FIXNUM (FOO X))) would still generate a check, but proclaiming
FOO to return a FIXNUM would completely bypass the check.

(**) Yes, indeed I know that LOCALLY exists for a reason, but it does more
than THE. For instance, if I (LOCALLY (DECLARE (SAFETY 0)) (THE FIXNUM (FOO
(SLOT-ACCESSOR X)))... this influences the safety of the code that accesses
a structure, which is not good.

P.S.: Thanks to Paul Khuong for pointing out that SBCL behaves differently
w.r.t. declarations.

problems with DEFAULT-SPECIAL-BINDINGS

Tobias C. Rittweiler — 2010-04-03T11:01:21

Most implementations that provide multi-threading also provide a
variable which contains an association lists for variable bindings to be
established in new threads.

I wanted to introduce the same to SBCL.

However, Gábor Melis made me aware of the following issue:


One use of *DEFAULT-SPECIAL-BINDINGS* is for libraries to establish
thread-local variable bindings to new threads by pushing onto
*DEFAULT-SPECIAL-BINDINGS*.

Howsoever, that will only affect new threads, not already running
threads.

That's a big problem for the following scenario:

Let's say your Lisp development environment is multi-threaded and allows
you to run multiple listeners at the same time. Each listener is run in
its own thread.

Now, you opened a few listeners, then loaded in this library which
pushes onto *DEFAULT-SPECIAL-BINDINGS*. Now all running listeners, when
the user uses them to call into that library, will operate on the _same_
global binding. 

Hilarity ensues.


Do you have ideas on how to provide a mechanism that handles this
scenario reliably?

  -T.

question about fresh-line.5

Ville Voutilainen — 2010-03-01T17:42:08

The test doesn't expect a space, abcl outputs a space. Is that test
correct? Why does it not expect
a space?

He has a point...

Juan Jose Garcia-Ripoll — 2009-11-20T23:38:26

_______________________________________________
Implementation-hackers mailing list
Implementation-hackers-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/implementation-hackers

locally special and symbol macros

Tobias C. Rittweiler — 2009-10-19T11:01:14

[ I just sent the following posting to the OpenMCL development mailing
  list. But it's also very apropos here. ]


I think the following

  (let ((x :special))
    (declare (special x))
    (symbol-macrolet ((x :symbol-macro))
      (values x (locally (declare (special x)) x))))

should return

  :SYMBOL-MACRO, :SPECIAL

It currently returns

  :SYMBOL-MACRO, :SYMBOL-MACRO

SBCL and CLISP return :SYMBOL-MACRO, :SPECIAL, while others signal an
error. I think, signalling an error is a mistake, and I'll mention this
issue to those implementations.

The reasoning why I think :SYMBOL-MACRO, :SPECIAL is the correct
implementation (and erroring is not) is mostly because

  http://www.lispworks.com/documentation/HyperSpec/Issues/iss228_w.htm

says so. I couldn't find it spelled out as explicitly in the spec
itself. Perhaps you're more lucky than me.


There's some inconsistency at place here, though, because
the definition of DEFINE-SYMBOL-MACRO explicitly forbids declaring a
global symbol macro to be special.

So the following _should_ signal an error:

  (progn (define-symbol-macro .foo. :global-symbol-macro)
         (locally (declare (special .foo.)) .foo.))  

(CCL returns :GLOBAL-SYMBOL-MACRO)

or

  (progn (define-symbol-macro .foo. :global-symbol-macro)
         (proclaim '(special .foo.)))

On the other hand,

    (progn (define-symbol-macro .foo. :global-symbol-macro)
           (let ((.foo. :special))
             (declare (special .foo.))
             (values .foo.
                     (let ((.foo. :lexical))
                       (locally (declare (special .foo.)))))))

should _not_ signal an error, but return :SPECIAL, :SPECIAL.

  -T.