From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Source properties on arbitrary non-immediate values
Date: Wed, 12 Oct 2005 10:42:46 +0200 [thread overview]
Message-ID: <87mzlfxh15.fsf@laas.fr> (raw)
In-Reply-To: <877jcjrh4p.fsf@ossau.uklinux.net> (Neil Jerram's message of "Tue, 11 Oct 2005 20:24:54 +0100")
Hi,
Neil Jerram <neil@ossau.uklinux.net> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2005-10-12 8:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-07 12:23 [PATCH] Source properties on arbitrary non-immediate values Ludovic Courtès
2005-10-07 20:47 ` Kevin Ryde
2005-10-08 18:01 ` Neil Jerram
2005-10-10 12:10 ` Ludovic Courtès
2005-10-10 16:43 ` Neil Jerram
2005-10-11 8:53 ` Ludovic Courtès
2005-10-11 19:24 ` Neil Jerram
2005-10-12 8:42 ` Ludovic Courtès [this message]
2005-10-15 17:59 ` Neil Jerram
2005-10-15 18:36 ` Neil Jerram
2005-10-17 8:08 ` Ludovic Courtès
2005-10-10 21:24 ` Kevin Ryde
2005-10-11 8:43 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mzlfxh15.fsf@laas.fr \
--to=ludovic.courtes@laas.fr \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).