[Openmcl-devel] Reader Macro Question

[Gary Byers]

? (find :openmcl *features*)
:OPENMCL
? (find :ccl *features*)
NIL

There is no other magic difference betwen the way that #+/-openmcl
and #+/-ccl work besides the fact that :openmcl is on *FEATURES*
and :ccl isn't in the 1.1 snapshots.

There was some discussion of this on this list a bit over a year
ago.  The consensus (as I remember it) was:

  - there were a lot of symbols on *features* whose significance
    was non-obvious and whose rationale for existing was long
    forgotten

  - the presence of :MCL on *features* was confusing; some people
    used it to conditionalize for "MCL or OpenMCL" (a), and others
    used it to mean "Commercial MCL" (b).  Ideally, it'd probably
    be better if :MCL was not on *features*; it was suggested
    that its use in the (a) case be deprecated and that :MCL
    be removed from *features* in the next release.

If :MCL was removed from OpenMCL's *FEATURES*, the code that
was really intended to run in either implementation would have
to be conditionalized like:

#+(or mcl openmcl)
(setq *too-much-float-consing-sometimes* t)

That's a little more to type, but easier to read without getting
nervous: it suggests that the author has thought about the issues
and concluded that the conditionalized form applies to either
implementation.


That's still the right thing, but there wasn't a whole lot of
work done to actively deprecate the (a) use of :MCL; I removed
:MCL from *FEATURES* (along with many other things whose meaning
seemed imprecise, like :CCL) in early 1.1 prereleases, but 
started getting bug reports from people who used packages that
still used :MCL to conditionalize for either implementation.

I wimped out and put :MCL back, resolving to try to do a better
job of deprecating that usage and eventually removing :MCL
permanently.

A lot of the symbols that remain on *FEATURES* are primarily useful
when compiling (or cross-compiling) OpenMCL itself. Certainly things
which try to separate attributes of the compilation host from target
attributes are redundant, so *FEATURES* might get a little less
crowded if one set (:HOST-*) only existed when compiling/cross-compiling
OpenMCL itself.




On Tue, 30 Jan 2007, Brent Fulgham wrote:

> I just realized I don't understand the way reader macros work, at
> least with respect to the "#+ccl" and "#-ccl" values:
>
> I always thought a form like:
>
> (let ((a #+openmcl
>              "Whee"
>             #-openmcl
>             "Whoops"))
>        (format t "~a~%" a))
>
> ... would conditionally provide the right text based on the certain
> pre-defined settings in the current environment.  So, in OpenMCL I
> get "Whee", and in MCL 5.1 (Demo) I get "Whoops".
>
> So far, so good.  But I'm confused how the corresponding "#+/-ccl"
> stuff works:
>
> ? (in-package :ccl)
> #<Package "CCL">
>
> (let ((a #+ccl
>              "Whee"
>             #-ccl
>             "Whoops"))
>        (format t "~a~%" a))
>
> ... Gives me "Whoops".
>
> Also, the following:
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
>
>   (defmacro MEMORY-ALLOC (Size)
>     #+ccl `(#_NewPtr ,Size)
>     #-ccl (error "MEMORY-ALLOC not implemented")))
>
> Indicates the error case:
>
> ? (eval-when (:compile-toplevel :load-toplevel :execute)
>
>   (defmacro MEMORY-ALLOC (Size)
>     #+ccl `(#_NewPtr ,Size)
>     #-ccl (error "MEMORY-ALLOC not implemented")))
>
> ;Compiler warnings :
> ;   Unused lexical variable SIZE, in MEMORY-ALLOC.
> MEMORY-ALLOC
> ? (MEMORY-ALLOC 3)
> > Error: MEMORY-ALLOC not implemented
> > While executing: MEMORY-ALLOC, in process Listener(4).
> > Type :POP to abort, :R for a list of available restarts.
> > Type :? for other options.
>
> Are #+ccl and #-ccl special beasts that can't be used the way the #
> +openmcl or similar guards work?
>
> Thanks,
>
> -Brent
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>