Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> We we already warn when importing something that shadows a core
>> definition, so we could as well warn when redefining one.
>
> I thought about that for my lint program and decided it'd be too
> annoying to
Neil Jerram <[EMAIL PROTECTED]> writes:
> Marius Vollmer wrote:
>> Hmm. There are two things here that might want a warning:
>> redefining
>> something that was a macro as a variable;
>
> Sounds good; and vice versa?
Yes, and vice versa.
> By the way, has your idea about having "identifier -> m
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> There is probably code that relies on redefinitions being silently
> interpreted as a `set!', I'm afraid. So I don't think Guile should
> start issuing warnings for redefinitions by default.
The warnings would be about redefinitions that would not ha
Ludovic Courtès wrote:
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
Or are you thinking of a "redefinition" as something different to what
I'm thinking? The case I'm thinking of is where a file contains a
definition, and you load that file twice (perhaps via use-modules, but
that's not import
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Or are you thinking of a "redefinition" as something different to what
> I'm thinking? The case I'm thinking of is where a file contains a
> definition, and you load that file twice (perhaps via use-modules, but
> that's not important).
What I'm thi
Ludovic Courtès wrote:
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
Isn't the rule we want "whenever a new definition shadows an existing
definition in a module, and the existing definition did not originate
in the current module"? This rule would also avoid giving unwanted
warnings when an e
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Isn't the rule we want "whenever a new definition shadows an existing
> definition in a module, and the existing definition did not originate
> in the current module"? This rule would also avoid giving unwanted
> warnings when an edited module is rel
Marius Vollmer wrote:
Hmm. There are two things here that might want a warning: redefining
something that was a macro as a variable;
Sounds good; and vice versa? By the way, has your idea about having
"identifier -> macro" instead of "identifier -> variable -> macro" been
implemented yet?
Marius Vollmer <[EMAIL PROTECTED]> writes:
>
> We we already warn when importing something that shadows a core
> definition, so we could as well warn when redefining one.
I thought about that for my lint program and decided it'd be too
annoying to report local bindings that shadow, but I did set u
Neil Jerram <[EMAIL PROTECTED]> writes:
>> Also (and don't try this at home kids):
>> (define 'x (* x x))
>> '2
>> => 4
>
> And presumably (or in my view) this is all fine, except for the last
> example, where Guile should signal an error or at least give a
> warning. Right?
Hmm. There are
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Sure it is, but I can't reproduce it with either 1.6.7 or 1.7.2, hence
> my sadness. ;-)
What happens? This should work in all version of Guile...
___
Guile-user mailing list
Guile-user@gnu.org
http://li
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Hmm, no, I meant (define 'x (* x x)). I think '2 => 4 is pretty
> funny, no? :-)
Sure it is, but I can't reproduce it with either 1.6.7 or 1.7.2, hence
my sadness. ;-)
Ludovic.
___
Guile-user mailing li
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Actually, you meant something like:
>
> guile> (define x 2)
> guile> (define 'x 3)
> guile> x
> 2
> guile> 'x
> 3
>
> Right? The example you gave doesn't produce anything funny unless `x'
> was previously defined.
Hmm, no, I meant (define
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Also (and don't try this at home kids):
>
> (define 'x (* x x))
> '2
> => 4
Obviously, I did try this at home. :-) Actually, you meant something
like:
guile> (define x 2)
guile> (define 'x 3)
guile> x
2
guile> 'x
3
Right? The exa
Marius Vollmer wrote:
It is a bit tricky. The syntax 'x is short for (quote x). This
expansion is done by the reader without looking at the context. So,
what the evaluator really sees is
(case 'x
((quote x) #t)
(else #f))
This is indeed in the form required by R5RS, although probably o
Aaron VanDevender <[EMAIL PROTECTED]> writes:
> Hello,
>
> I have noticed that guile evaluates the following to #t
>
> (case 'x
> ('x #t)
> (else #f))
>
> even though R5RS section 4.2.1 seems to say that all of the statements
> (besides else) must be of the form ((datum ...) ...). Clearly the
Hello,
I have noticed that guile evaluates the following to #t
(case 'x
('x #t)
(else #f))
even though R5RS section 4.2.1 seems to say that all of the statements
(besides else) must be of the form ((datum ...) ...). Clearly the symbol
'x is not a list. What is going on here? Is this an agree
17 matches
Mail list logo
