[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Source properties on arbitrary non-immediate values
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] Source properties on arbitrary non-immediate values |
Date: |
Wed, 12 Oct 2005 10:42:46 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
Hi,
Neil Jerram <address@hidden> 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 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 restriction), I wrote something
like:
if (SCM_NIMP (expr))
{
scm_set_source_property_x (expr, scm_sym_line, line);
...
}
And I was surprised to see that this wouldn't work on any kind of
non-immediate. I considered this an /arbitrary/ limitation: why would
my reader record positions only on pairs?
> There are a couple of reasons why it seems obvious to me that
> extending source properties is a bad idea, but which may not be
> obvious generally.
>
> 1. Source properties are used for very specific purposes by libguile
> and on performance-critical paths:
>
> - when reading code using the built-in reader, so that the
> information can contribute later to the (also built-in) backtrace
> function
>
> - in the low level implementation of breakpoints, when deciding
> whether to call an evaluator trap handler.
>
> Adding stuff to scm_source_whash which doesn't need to be there is
> not going to help these paths.
Right, source properties are not "one size fits all" and should only be
used by the reader. Perhaps we should add a line about this in the
manual?
> 2. All of the old property interfaces (source-properties,
> object-properties and procedure-properties) are considered to be
> not very nice, and would all be deprecated but for the fact that
> they are still used for some important bits of libguile
> infrastructure (such as (1) and low-level tracing).
>
> The recommended way to handle properties in new code is with
> make-object-property.
>
> So unless you are wanting specifically to hook in to the mechanisms
> that currently rely on source properties, it's a bad idea to use
> them.
Right. Indeed, in my previous example, I should probably use
`make-object-property' instead.
Still, that doesn't make this restriction rational. ;-)
Thanks,
Ludovic.
- [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/07
- Re: [PATCH] Source properties on arbitrary non-immediate values, Kevin Ryde, 2005/10/07
- Re: [PATCH] Source properties on arbitrary non-immediate values, Neil Jerram, 2005/10/08
- Re: [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/10
- Re: [PATCH] Source properties on arbitrary non-immediate values, Neil Jerram, 2005/10/10
- Re: [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/11
- Re: [PATCH] Source properties on arbitrary non-immediate values, Neil Jerram, 2005/10/11
- Re: [PATCH] Source properties on arbitrary non-immediate values,
Ludovic Courtès <=
- Re: [PATCH] Source properties on arbitrary non-immediate values, Neil Jerram, 2005/10/15
- Re: [PATCH] Source properties on arbitrary non-immediate values, Neil Jerram, 2005/10/15
- Re: [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/17
- Re: [PATCH] Source properties on arbitrary non-immediate values, Kevin Ryde, 2005/10/10
- Re: [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/11