LOOP non-compliance

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?



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

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
_______________________________________________
Implementation-hackers mailing list
Implementation-hackers@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/implementation-hackers

Declarations in compilers (feedback welcome)

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.

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
_______________________________________________
Implementation-hackers mailing list
Implementation-hackers@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/implementation-hackers
Picon

problems with *DEFAULT-SPECIAL-BINDINGS*


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.
Ville Voutilainen | 1 Mar 18:42
Picon

question about fresh-line.5

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...

  http://fare.livejournal.com/149264.html


To what extent should ASDF remain an individually maintained project, or rather get support from a number of implementations that distribute it?

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
_______________________________________________
Implementation-hackers mailing list
Implementation-hackers@...
http://common-lisp.net/cgi-bin/mailman/listinfo/implementation-hackers
Tobias C. Rittweiler | 19 Oct 13:01
Picon

locally special and symbol macros


[ 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.
Tobias C. Rittweiler | 27 Jul 22:14
Picon

Procedure for adding tests to the ansi test suite


Can anyone think of a good procedure for getting new tests into the test
suite?

I think there are a few requirements:

  * the new tests should be visibly separate from what's currently
    there. Perhaps this should be reflected on the file system layout of
    the source tree.

  * it should be possible to exclude the new tests when running the test
    suite.

  * a proposal explaining the justification for the test.

  * there should be at least N people who agree that the test checks for
    something that matches with their understanding of the
    specification.

More to the last point:

Preferably the N people represent different implementations.

What's a good N? >= 2 ?

Should a disapproval by as few as one person who can not be convinced
differently in reasonable time be enough to deny a proposal? Perhaps
this should be tightened up to a person representing an implementation.

Where should discussion take place? I'm sending this mail both to the
implementation-hackers and ansi-test mailing list mostly to reach as
many people who may be concerned.

  -T.
Tobias C. Rittweiler | 19 Jul 13:51
Picon

[imp-hackers] gmane.lisp.common-lisp.implementation-hackers


The mailing list is now also available as

  gmane.lisp.common-lisp.implementation-hackers

on the Gmane Mailinglist <-> News gateway.

  -T.

--

-- 
Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht
und ist - aktuelle Virenscanner vorausgesetzt - sauber.
Freebits E-Mail Virus Scanner

Gmane