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

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 han

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