unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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


  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).