Neil Jerram <[EMAIL PROTECTED]> writes:
> Now in CVS:
Ok, cool.
Thanks,
Ludovic.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> And I was surprised to see that this wouldn't work on any kind of
>> non-immediate. [...] Right, source properties are not "one size
>> fits all" and should only be used by the reader. Perhaps we should
>
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> My original motivation was to implement "position recording" in
> `guile-reader'. In order to be compatible with the built-in reader, I
> wanted to use the same mechanism as the one it uses. When I initially
> implemented it (not knowing about the re
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> I didn't say it was! I just wanted you to describe your motivation in
> more concrete terms.
I actually only partly describe my motivations. ;-)
My original motivation was to implement "position recording" in
`guile-reader'. In order to be compat
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Yes, but why is that useful?
>
> Why is it useless? ;-)
I didn't say it was! I just wanted you to describe your motivation in
more concrete terms.
There are a couple of reasons why it seems obvio
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> That's fair enough. I guess the rationale is that the unit of
> evaluation (as presented in backtraces for example) is a list, so it
> is useful for source properties to be stored on lists when those are
> read.
Sure.
> Yes, but why is that useful?
Kevin Ryde <[EMAIL PROTECTED]> writes:
> But cf currently just one empty string,
>
> (eq? "" "") => #t
This also is made compulsory by R5RS.
Ludovic.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-d
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> In particular, `(eq? "a" "a")' returns `#f' with Guile.
But cf currently just one empty string,
(eq? "" "") => #t
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/lis
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Well, the manual doesn't mention this restriction and, rather than
> fixing the manual, I wanted to understand the rationale behind this
> restriction.
That's fair enough. I guess the rationale is that the unit of
evaluation (as presented in backtrac
Neil Jerram <[EMAIL PROTECTED]> writes:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>> A symbol used in two places is the same object, so file/line attached
>> by both occurrances will overwrite, or whatever. Ditto other uniques
>> like keywords, and immediates like fixnums and chars.
Symbols and
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> guile> (define x 'a-symbol)
>> guile> (set-source-properties! x '((a . 2)))
>> ((a . 2))
>> guile> (source-properties x)
>> ((a . 2))
>
> A symbol used in two places is the same object, so file/lin
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> guile> (define x 'a-symbol)
> guile> (set-source-properties! x '((a . 2)))
> ((a . 2))
> guile> (source-properties x)
> ((a . 2))
A symbol used in two places is the same object, so file/line attached
by both occurrances will overwrite, or w
Hello,
Does anyone know the rationale for allowing to attach source properties
_only_ to pairs?
Since I couldn't think of any compelling reason, I tried to remove this
limitation, and still I can't see any problem. :-) The patch below
allows to do things like this:
guile> (define x 'a-symbol
13 matches
Mail list logo
