[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: |
Neil Jerram |
Subject: |
Re: [PATCH] Source properties on arbitrary non-immediate values |
Date: |
Tue, 11 Oct 2005 20:24:54 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <address@hidden> 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
- [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 <=
- Re: [PATCH] Source properties on arbitrary non-immediate values, Ludovic Courtès, 2005/10/12
- 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