[Bug-openmcl] LOOP 'feature'

[Gary Byers]

Arrgh; I missed this, sorry.  I think that it's a bug (though I'm
sure that it's easy to think of worse bugs); see the last paragraph
in the "description" section of the CLHS dictionary entry for the
FUNCTION special operator.  (In this context, that seems to say
that it's OK for LOOP to be too lazy to check for (FUNCTION MACRO-NAME),
but not OK for that failure to be defined as useful behavior, i.e.
as "a feature".)  So, the current behavior ("undefined results that
happen to be useful") is probably technically compliant, but there's
no good reason not to arrange for the error to be detected.

I think that the code in LOOP is transforming the reference to
#'some-macro into the combination:

(some-macro ...)

and that just gets macroexpanded normally.

That transformation isn't really correct, since FUNCTION can't really
be used to reference a macro.  LOOP should probably just expand into
something which does:

(funcall #'whatever ...)

If WHATEVER turns out to name a macro, the compiler should catch that and
complain about the use of FUNCTION to reference a macro; if it doesn't
name a macro, then

(funcall #'whatever ...)

will compile exactly the same as

(whatever ...).

I didn't see this until now, and didn't get this change into the
070722 snapshots.

On Sun, 6 May 2007, Rainer Joswig wrote:

>
> interesting LOOP 'feature':
>
> (loop for ... by #'i-am-a-macro ... )
>
> seems to work. If i-am-a-macro is a macro
> (say for CDDR) you can use it as a step-fun .
>
> Is it a feature or a bug? ;-)
>
> Regards,
>
> Rainer
>
> -- 
> http://lispm.dyndns.org
>
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>