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

[Neil Jerram <neil@ossau.uklinux.net>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> 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 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.

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.

> I found it useful in a project that evaluates source in several steps:
>
>   read [sexp] -> convert to alternate representation -> write things
>
> Errors may occur during the last stage.  However, the user doesn't care
> about the intermediate stage: they just want to know how the errors
> occurring in the last stage relate to its source.  Therefore, source
> information needs to be "piggy-backed" all along the process.
>
> In any case, it's up to the user to decide what's useful and what's not.
> Guile is here to implement mechanisms, not policy.

Yes, but in this case the mechanism is make-object-property, and
AFAICT that would meet your need just fine.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel