Re: bug in syncase

From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Cc: Guile Development <guile-devel@gnu.org>
Subject: Re: bug in syncase
Date: Sun, 24 Nov 2002 11:33:56 +0100 (CET)	[thread overview]
Message-ID: <Pine.GSO.4.05.10211241122050.27972-100000@sallust.ida.ing.tu-bs.de> (raw)
In-Reply-To: <m3bs4f5ngl.fsf@laruns.ossau.uklinux.net>

On 24 Nov 2002, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:
> 
>     Dirk> There is a mechanism in scheme that allows to prevent
>     Dirk> memoization: eval.  If it is correct that emacs does not
>     Dirk> perform memoization, then it might be that the whole concept
>     Dirk> of the @fop memoization is wrong.  Could you check whether
>     Dirk> it is possible to achieve emacs' behaviour by replacing the
>     Dirk> @fop solution by a solution based on eval (or some elisp
>     Dirk> equivalent of this)?  I would postpone working on @fop until
>     Dirk> this is solved - there are still enough other things to do
>     Dirk> for me :-)
> 
> Is this a blocking problem for you?  If it isn't, I'd say that we
> don't particularly have to solve this problem now.  It is only
> relevant in the pathological scenario where a symbol previously
> defined as a function becomes a macro, and vice versa, so it's a low
> priority bug.  (For example, much lower priority than the odd
> behaviour of array?.)

It is not currently blocking _me_ but it will block the integration of my
changes as soon as they are completed.  And, since issues like the one
above lead to questioning very basic assumptions (see your question about
detection of redefinition and rememoization below), it is better to get
answers quickly.

> - I dislike explicit uses of eval, so would prefer not to have to use
>   such an approach.

If there is a solution that works with separate memoization, I don't mind.
Maybe one could change the elisp translation code that it does
re-translation itself, without support for such code in the evaluator?

> - Looking at the analogous example in Scheme, have we agreed
>   (definitively) that Guile should _not_ detect the redefinition and
>   rememoize accordingly?

As far as I have understood things, yes:  All our current discussions go
towards the direction, that if you want that changed bindings will have
effect on already loaded code, you will have to reload that code.  This
IMO also covers the fact of redefinitions of macros etc.

Best regards
Dirk Herrmann

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