Re: Strange memoizing behavior

[Matthias Koeppe]

Michael Livshin <address@hidden> writes:

> Matthias Koeppe <address@hidden> writes:
>> Michael Livshin <address@hidden> writes:
>> > Matthias Koeppe <address@hidden> writes:
>> >> Indeed, we cannot disallow passing macros to functions because that
>> >> would effectively destroy their first-class status.
>> > yes.  it also would allow Guile not to be stuck in interpreter-land
>> > forever.  I fail to see how that would be a bad thing.
>> 
>> Care to explain what you mean?  
>> 
>> I was suggesting (in the paragraph that you have cut away) to add
>> extra error checking to the macro-memoizing evaluator, because passing
>> macros to a procedure that expects a procedure-argument can cause
>> wrong, destructive memoizing when the passed argument is used in an
>> operator position.  (I gave an example where this has bitten me and
>> suggested that an error should be signalled in certain situations.)
>
> in the paragraph I've cut away you (as I understand) have suggested a
> way to avoid *calling* macros that are passed as values.  right?

Exactly.

> I simply fail to see what the ability to pass macros as values buys
> you, so what I'm suggesting is that this ability is taken out from
> Guile altogether.  macros shouldn't be first class.  

Thanks for the clarification.

I disagree, however.  I like Guile's current introspection features,
including the ability to get at the macro transformer, etc.  As thi
pointed out, we would lose introspecting procedures if we forbid
passing macro arguments to procedures.  (Passing the macro-designating
symbols to the introspecting procedures instead would break Guile's
ability to put syntax (macros) into modules, I think, and would also
feel quite non-Schemey.)

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe