[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memoization and error messages
From: |
Daniel Skarda |
Subject: |
Re: memoization and error messages |
Date: |
Mon, 02 Dec 2002 21:45:16 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) |
> R5RS does allow macro and variable of the same name - in a sense. For
> example:
First I must say I have to add "read R5RS more carefully" to my TODO list :)
As my quick survey revealed, this macro part of R5RS is not consistently
implemented in most scheme implementations - in my opinion it shows that there
is something bad in R5RS.
> (defmacro foo <...>) ;; after this line, foo is a syntactic keyword
> (foo some-args ...) ;; foo will be expanded.
> (define foo <some-value>) ;; after this line, foo is bound to a location
> (foo some-args ...) ;; foo will not be expanded.
> (define (bar) foo) ;; bar will refer to foo's binding
> (defmacro foo <...>) ;; after this line, foo is a syntactic keyword, but:
> ;; bar will still refer to foo's _variable_ binding
And what would do
(define (bar) foo)
here (after second defmacro foo)? Return variable binding <some-value> or
macro? I rather would vote for simplicity, than for adhering to obscure feature
we find in standard (feature that most people do not care to implement in
"standard" way).
>> (if (macro? foo) ; not possible with your modification
>> ....)
>
> True, but if you would quote foo, this could still be checked.
No! If you quote foo, it is symbol.
Current Guile:
(cond
((symbol? x) ...)
((procedure? x) ...)
((macro? x) ....)
this code after your proposal would be:
(cond
((procedure? x) ...)
((and (symbol? x) (macro? x module))
...
((symbol? x) ...) ; now users has to remember that this line must be
written
; after macro? line..... What an obscure feature...
do you feel that you simplified programming in Guile?
>> (define old-foo foo) ; also not possible
>
> But
> (defmacro old-foo args `(foo ,@args))
> does the trick. The only problem that we currently have, is that defmacro
> is not able to keep track of the module the definition of foo came from.
> For a temporary workaround, see my email about preparation for hygienic
> macro expansion.
>
>> (defmacro foo args
>> (do something clever with 'old-foo args))
>
> As long as you don't mix up definitions of foo from different modules,
> this would also work with my example above.
No, it would not.
(defmacro foo args blah blah ,,,)
(defmacro old-foo args `(foo ,@args))
(defmacro foo args (blah blah `(old-foo ,@args)))
... would cause infinite expansion.
>> (module-ref (resolve-module '(guile-user)) 'define)
>>
>> ; returns the same value as simple "define" - but one line is correct
>> ; another would be error. Why?
>
> Who says that one line is correct and one is an error? sure:
> guile> define
> _would_be_ an error if my local version of eval became official. Today's
> guile still accepts such a line, as it also accepts the module-ref code.
> If my changes became official, the behaviour of module-ref with respect to
> syntactic keywords might also change.
Well, IMHO (module-ref foo bar) should NOT be an error because "bar" is
defined in "foo" module (no matter if it is macro or not....).
I like about Guile (or scheme) that it lets you to touch everything in one
simple way.
The "simple way" I understand as the way without many rule exceptions
one has to handle. I think something like: less exceptions in code => shorter
code => few bugs => shorter debugging time => faster development.
"One way" - in guile all values can be "stored in variables" and all variables
are "equal" - why macros should be different? Why do you want to invent new way
for storing values?
>> (defmacro dynamic-expansion code
>> `(local-eval '(begin ,@code) (the-environment)))
>>
>> so it would be easy to identify the code with dynamic macro expansion.
>> (I
>> do not know why people use dynamic macro expansion, but I guess it is
>> handy
>> during macro debugging...)
>
> Yes, this could be done, although I recommend that we get rid of
> local-eval.
I do not care about how "dynamic-expansion" would be implemented.
My implementation with "local-eval" was just an example - such
"dynamic-expansion"
works even with current guile eval and it clearly marks "odd" code.
> Maybe we are just discussing the wrong examples here: The major issue
> about first class macros is that you can define them at run-time. That
> is, you could at run time change the set of syntactic keywords and have
> the same code code expanded in different ways depending on the set of
> macro definitions defined at run-time. Do you have any situations like
> this in mind?
No. I do not defend dynamic macro expansion, rather I was speaking for
"the right to touch everything" (including macros - that's what I understand
as "macro is first class").
I understand that non-dynamical macro evaluation is vital for Guile speed.
But I can not understand why it is impossible to achieve non-dynamical macro
expansion without loosing "first class macros". How "(is-a? define <macro>)"
or "(class-of let)" lowers the performance and why you want to prohibit it?
Is there any other advantage than
guile> define
signals an error? In my oppinion it is easy to catch such errors - but what
would our tax? We would complicate other code and make it less immune to
possible bugs.
0.
ps: My small wish for Guile: macrolet (or let-macro - something like
let-syntax). How hard it would be to write macrolet with your eval?
- Re: memoization and error messages,
Daniel Skarda <=