Re: [PATCH] Source properties on arbitrary non-immediate values

[Ludovic Courtès]

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.