bug in syncase

bug in syncase

[Dirk Herrmann]

Hi Marius,

the separation of memoization and execution is going forward.  However,
there is one thing that I cannot solve by myself (or at least, which would
take me too long).  Guile now does not accept the following any more:

guile> define
ERROR: In procedure expression:
ERROR: Misplaced syntactic keyword
ABORT: (misc-error)

and similarly:

guile> (identity and)
ERROR: In procedure expression:
ERROR: Misplaced syntactic keyword
ABORT: (misc-error)

That is, syntactic keywords are only allowed at the operator position of
an expression.  (OK, the error messages are not quite helpful yet.
Please ignore this for the moment.)  This required to change some code
like
  (define foo <some-macro>)
into
  (defmacro foo args `(<some-macro> ,args))

However, in (ice-9 syncase) there is one place where I don't know how to
fix it correctly, namely in function putprop there is the following line:
  (variable-set! v sc-macro)
where sc-macro is a macro.  As a workaround, I have changed the line to
  (variable-set! v 'sc-macro)
but without being aware of the effects.  However, the test-suite almost
completes flawlessly now.  (There is only goops and the elisp macros that 
I have not yet worked on.)

Could you (or someone else being familiar with syncase) please check
syncase.scm for a correct patch?  Otherwise, it will cost me a lot of time
trying to figure it out by myself.

Best regards, 
Dirk



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

Re: bug in syncase

[Clinton Ebadi]

On Thursday 14 November 2002 06:59, Dirk Herrmann wrote:
> the separation of memoization and execution is going forward.  However,
> there is one thing that I cannot solve by myself (or at least, which would
> take me too long).  Guile now does not accept the following any more:
>
> guile> define
> ERROR: In procedure expression:
> ERROR: Misplaced syntactic keyword
> ABORT: (misc-error)

That shouldn't be a bug. In every other scheme system that is a perfectly 
valid statement since there are no "magic" operators in Scheme. I don't see 
the advantage of making it impossible to do things like this. Guile should be 
fixed, not syncase.

-- 
http://unknownlamer.org
The root of unspoken fear
The root grows deep in my heart
A dark cold sound tears at my life


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

Re: bug in syncase

[Lynn Winebarger]

On Thursday 14 November 2002 23:10, Clinton Ebadi wrote:
> On Thursday 14 November 2002 06:59, Dirk Herrmann wrote:
> > the separation of memoization and execution is going forward.  However,
> > there is one thing that I cannot solve by myself (or at least, which would
> > take me too long).  Guile now does not accept the following any more:
> >
> > guile> define
> > ERROR: In procedure expression:
> > ERROR: Misplaced syntactic keyword
> > ABORT: (misc-error)
> 
> That shouldn't be a bug. In every other scheme system that is a perfectly 
> valid statement since there are no "magic" operators in Scheme. I don't see 
> the advantage of making it impossible to do things like this. Guile should be 
> fixed, not syncase.
> 

   Nonsense.  Here's the response in Petite Chez Scheme:
> define

Error: invalid syntax define.
Type (debug) to enter the debugger.
> 

   What scheme systems are you refering to?

Lynn


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

Re: bug in syncase

[Lynn Winebarger]

On Thursday 14 November 2002 06:59, Dirk Herrmann wrote:
> However, in (ice-9 syncase) there is one place where I don't know how to
> fix it correctly, namely in function putprop there is the following line:
>   (variable-set! v sc-macro)
> where sc-macro is a macro.  As a workaround, I have changed the line to
>   (variable-set! v 'sc-macro)
> but without being aware of the effects.  However, the test-suite almost
> completes flawlessly now.  (There is only goops and the elisp macros that 
> I have not yet worked on.)
> 
     I don't know the answer to your question, but according to Jim Blandy,
psyntax.ss is non-free.  You can redistribute it, but not modify it.  
     But apparently this is part of Guile's support functions rather than
psyntax.ss (just took a look).

Lynn



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

Re: bug in syncase

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    Dirk> (There is only goops and the elisp macros that I have not
    Dirk> yet worked on.)

I don't understand syncase, but let me know if you need any assistance
with the elisp.

        Neil



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

Re: bug in syncase

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> the separation of memoization and execution is going forward.

Great!

> However, in (ice-9 syncase) there is one place where I don't know how to
> fix it correctly, namely in function putprop there is the following line:
>   (variable-set! v sc-macro)
> where sc-macro is a macro.  As a workaround, I have changed the line to
>   (variable-set! v 'sc-macro)
> but without being aware of the effects.  However, the test-suite almost
> completes flawlessly now.

I can't say right now how to fix this, but in general, I think the
whole syntax transformer business needs to be redone for a separate
memoizer/compiler pass.  That is, it is OK when your new evaluator
breaks the existing syncase and this is not easily fixed.  We need to
find a fix eventually, but that fix should also remove the kluginess
of the current situation completely.

In my vision, the syntax transformer in essence _is_ the memoizer.
Thus, I'd say it is acceptable that syntax-case support must be redone
from the ground up.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: bug in syncase

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> I can't say right now how to fix this, but in general, I
    Marius> think the whole syntax transformer business needs to be
    Marius> redone for a separate memoizer/compiler pass.  That is, it
    Marius> is OK when your new evaluator breaks the existing syncase
    Marius> and this is not easily fixed.  We need to find a fix
    Marius> eventually, but that fix should also remove the kluginess
    Marius> of the current situation completely.

OK in principle, but how long will "eventually" be?

I suggest that this work be code-managed such that we can still
release a 1.8 series with syncase working and _before_ redoing syntax
transformation.

More positively, perhaps this memoization/evaluation separation,
redoing syntax transformation, support for compilation and storage of
memoized code etc. is such a big improvement that we could call its
first release Guile 2.0.

That would be great. But I really want to see a 1.8.x series first.

        Neil



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

Re: bug in syncase

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    Dirk> Yes, I could need some help: What are the macros nil-cond
    Dirk> and @fop used for, and how are their macro transformers
    Dirk> supposed to work?

nil-cond's macro transformer just replaces nil-cond by #@nil-cond.
nil-cond is just a simplified cond, described in
lang/elisp/primitives/syntax.scm as:

;;; NIL-COND expressions have the form:
;;;
;;; (nil-cond COND VAL COND VAL ... ELSEVAL)
;;;
;;; The CONDs are evaluated in order until one of them returns true
;;; (in the Elisp sense, so not including empty lists).  If a COND
;;; returns true, its corresponding VAL is evaluated and returned,
;;; except if that VAL is the unspecified value, in which case the
;;; result of evaluating the COND is returned.  If none of the COND's
;;; returns true, ELSEVAL is evaluated and its value returned.

@fop is used to translate an Elisp application, and is complicated in
two ways:

- When the application is translated, we don't know whether the CAR of
  the application represents a function or a macro, and therefore
  whether the application arguments need to be translated.

- The symbol in the CAR may need to be looked up recursively, for
  defalias support.

The Scheme translation code translates (fn arg ...) to (@fop fn
(transformer-macro arg ...)). Then, when (@fop ...) is memoized and
evaluated,

- scm_m_atfop changes it to (#@apply fnval (transformer-macro arg
  ...))  if fnval is a function, or (fnval arg ...) if fnval is a
  macro, where fnval is the function or macro obtained from looking up
  fn's symbol function slot (recursively if needed)

- remaining evaluation of (#@apply fnval (transformer-macro arg ...))
  or (fnval arg ...) is done by the evaluator.

Does this help?  Let me know if you need any more.

        Neil



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

Re: bug in syncase

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> >>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
>     Marius> I can't say right now how to fix this, but in general, I
>     Marius> think the whole syntax transformer business needs to be
>     Marius> redone for a separate memoizer/compiler pass.  That is, it
>     Marius> is OK when your new evaluator breaks the existing syncase
>     Marius> and this is not easily fixed.  We need to find a fix
>     Marius> eventually, but that fix should also remove the kluginess
>     Marius> of the current situation completely.
> 
> OK in principle, but how long will "eventually" be?

Syncase needs to work again before we can switch over to the new code,
I'd say.  If that is exceedingly difficult, and we badly want the new
code, I think we could first only support syntax-rules, if that is
simpler.

> I suggest that this work be code-managed such that we can still
> release a 1.8 series with syncase working and _before_ redoing syntax
> transformation.

Yes.  The separate memoization pass looks like a big enough change to
postpone it after 1.8.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: bug in syncase

[Dirk Herrmann]

Hello Neil,

thanks for your explanation of nil-cond and @fop.  I will try to get them
done.  If I need more help, I will bother you again.

Best regards, 
Dirk Herrmann



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

Re: bug in syncase

[Dirk Herrmann]

Hello Neil,

> ;;; NIL-COND expressions have the form:
> ;;;
> ;;; (nil-cond COND VAL COND VAL ... ELSEVAL)

OK, done with that one.

> @fop is used to translate an Elisp application, and is complicated in
> two ways:
> 
> - When the application is translated, we don't know whether the CAR of
>   the application represents a function or a macro, and therefore
>   whether the application arguments need to be translated.
> 
> - The symbol in the CAR may need to be looked up recursively, for
>   defalias support.
> 
> The Scheme translation code translates (fn arg ...) to (@fop fn
> (transformer-macro arg ...)). Then, when (@fop ...) is memoized and
> evaluated,
> 
> - scm_m_atfop changes it to (#@apply fnval (transformer-macro arg
>   ...))  if fnval is a function, or (fnval arg ...) if fnval is a
>   macro, where fnval is the function or macro obtained from looking up
>   fn's symbol function slot (recursively if needed)
> 
> - remaining evaluation of (#@apply fnval (transformer-macro arg ...))
>   or (fnval arg ...) is done by the evaluator.

I have some questions about that one:  As you say, scm_m_atfop changes the
code in one of two ways, depending on the state of fnval at some point in
time.  Currently, this time is when the code is _executed_.  See the
following example:
  (define foo 1)
  (define (fn) <some code>)
  (define (bar) (if (= foo 2) (@fop fn (transformer-macro arg ...)))))
  (bar)
  (define foo 2)
  (defmacro fn args <some macro transformer>)
  (bar)
In the current implementation, the decision, how the @fop expression
should be changed, would be taken when foo was set to 2.  In contrast,
with my memoization phase I would like to perform the transformation
(including the expansion of the transformer-macro expression) at the point
where bar gets defined.

In other words:  Are there any statements about _when_ the expansion of
the @fop macro and the transformer-macro should happen?

Best regards,
Dirk Herrmann



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

Re: bug in syncase

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    Dirk> In the current implementation, the decision, how the @fop
    Dirk> expression should be changed, would be taken when foo was
    Dirk> set to 2.  In contrast, with my memoization phase I would
    Dirk> like to perform the transformation (including the expansion
    Dirk> of the transformer-macro expression) at the point where bar
    Dirk> gets defined.

    Dirk> In other words: Are there any statements about _when_ the
    Dirk> expansion of the @fop macro and the transformer-macro should
    Dirk> happen?

I would say that there are no statements except that transformed Elisp
code should behave in the same way as Emacs.

In Emacs:

(setq foo 1)
1
(defun fn () 'function-value)
fn
(defun bar () (if (= foo 2) (fn)))
bar
(bar)
nil
(defmacro fn () ''macro-value)
fn
(bar)
nil
(setq foo 2)
2
(bar)
macro-value
(defun fn () 'function-value)
fn
(bar)
function-value

In Guile (current unstable CVS):

guile> (use-modules (lang elisp base))
guile> (define-module (lang elisp base))
#<directory (lang elisp base) 4033e1f0>
guile> (setq foo 1)
1
guile> (defun fn () 'function-value)
fn
guile> (defun bar () (if (= foo 2) (fn)))
bar
guile> (bar)
#nil
guile> (defmacro fn () ''macro-value)
guile> (bar)
#nil
guile> (setq foo 2)
2
guile> (bar)
macro-value
guile> (defun fn () 'function-value)
fn
guile> (bar)
macro-value

So Guile as it stands is already wrong in the last result.  It looks
as though Emacs behaves as though there is no memoization at all.

It strikes me that macros have two meanings that are confused.

1 is to prevent automatic evaluation of arguments.

2 is to gain execution efficiency by expanding/transforming code at
read time.

Apparently Emacs does 1 but not 2.  I wonder if Guile's macros should
offer explicit control over which of 1 and 2 should apply.

        Neil



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

Re: bug in syncase

[Dirk Herrmann]

On 21 Nov 2002, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:
> 
>     Dirk> In the current implementation, the decision, how the @fop
>     Dirk> expression should be changed, would be taken when foo was
>     Dirk> set to 2.  In contrast, with my memoization phase I would
>     Dirk> like to perform the transformation (including the expansion
>     Dirk> of the transformer-macro expression) at the point where bar
>     Dirk> gets defined.
> 
>     Dirk> In other words: Are there any statements about _when_ the
>     Dirk> expansion of the @fop macro and the transformer-macro should
>     Dirk> happen?
> 
> I would say that there are no statements except that transformed Elisp
> code should behave in the same way as Emacs.
> 
> In Emacs:
[example deleted]
> 
> In Guile (current unstable CVS):
[example deleted]
> 
> So Guile as it stands is already wrong in the last result.  It looks
> as though Emacs behaves as though there is no memoization at all.

There is a mechanism in scheme that allows to prevent memoization:  eval.
If it is correct that emacs does not perform memoization, then it might be
that the whole concept of the @fop memoization is wrong.  Could you check
whether it is possible to achieve emacs' behaviour by replacing the @fop
solution by a solution based on eval (or some elisp equivalent of this)?
I would postpone working on @fop until this is solved - there are still
enough other things to do for me :-)

Best regards
Dirk



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

Re: bug in syncase

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> So Guile as it stands is already wrong in the last result.  It looks
> as though Emacs behaves as though there is no memoization at all.

Does Emacs behave like this even when the code is compiled?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: bug in syncase

[Neil Jerram]

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

(So we don't lose the details, I'll add a file
translation/elisp-and-memoization.text to the workbook shortly.)

For when we do solve it, here are two considerations.

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

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

Regards,
        Neil



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

Re: bug in syncase

[Dirk Herrmann]

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

Re: bug in syncase

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

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

Though I tend to agree, and though it may not apply here, I'd like to
try to make sure we all consider whether or not the way guile has
handled things up to now may have hidden a bunch of operations that
are more or less equivalent to using eval.  In such cases (personally
speaking) I'd probably rather just see an explicit eval.

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

I'm not sure -- it might be nice if the guile interpreter was smart
enough to detect and handle such things if the costs (in code,
performance, and time complexity) aren't too high when running
interactively.

However, I'd like to try not to require things of *non-interactive*
sessions that are at odds with extremely efficient offline
compilation, a situation where separating the expansion environment
from the evaluation environment is likely to be fairly important to
good performance.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: bug in syncase

[Carl R. Witty]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I would say that there are no statements except that transformed Elisp
> code should behave in the same way as Emacs.
...
> So Guile as it stands is already wrong in the last result.  It looks
> as though Emacs behaves as though there is no memoization at all.
> 
> It strikes me that macros have two meanings that are confused.
> 
> 1 is to prevent automatic evaluation of arguments.
> 
> 2 is to gain execution efficiency by expanding/transforming code at
> read time.

Emacs does not do memoization during eval; macros are re-evaluated
every time they are encountered.  However, if you byte-compile a
function (typically by byte-compiling an entire file at install time,
although it's also possible to byte-compile an individual function at
run time), macros are expanded during the byte-compilation process.

This means that Emacs Lisp code which is to run correctly both
interpreted and compiled must be insensitive to when or how often
macro expansion is done; such code -- which includes virtually all
distributed Emacs Lisp code, I would think -- would also work if macro
expansion were memoized.  The interactive development process would be
different, though; for a complete clone of Emacs, including the
development process, you would want to have an eval that does no
memoization and some sort of separate compilation phase.

The above is how GNU Emacs 19.x worked, but I would be surprised if
any of the branches or later versions were different.

Carl Witty


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

Re: bug in syncase

[Neil Jerram]

>>>>> "Carl" == Carl R Witty <cwitty@newtonlabs.com> writes:

    Carl> Emacs does not do memoization during eval; macros are
    Carl> re-evaluated every time they are encountered.  However, if
    Carl> you byte-compile a function (typically by byte-compiling an
    Carl> entire file at install time, although it's also possible to
    Carl> byte-compile an individual function at run time), macros are
    Carl> expanded during the byte-compilation process.

Many thanks for this.

    Carl> This means that Emacs Lisp code which is to run correctly
    Carl> both interpreted and compiled must be insensitive to when or
    Carl> how often macro expansion is done; such code -- which
    Carl> includes virtually all distributed Emacs Lisp code, I would
    Carl> think -- would also work if macro expansion were memoized.

A persuasive constraint to have ... except only for the interactive
development angle ...

    Carl> The interactive development process would be different,
    Carl> though; for a complete clone of Emacs, including the
    Carl> development process, you would want to have an eval that
    Carl> does no memoization and some sort of separate compilation
    Carl> phase.

I don't quite understand.  By `interactive development process', do
you mean what a user does with `C-x C-e', or something more specific
to the core Emacs developers?

If the former, I don't see how you reach your conclusion.  What if you
redefine a macro that was in use by a byte-compiled function?  It
seems to me that what you need to handle this scenario is a
recompilation protocol.  How does a non-memoizing eval and separate
compilation help?

        Neil



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

Re: bug in syncase

[Carl R. Witty]

Neil Jerram <neil@ossau.uklinux.net> writes:

>     Carl> The interactive development process would be different,
>     Carl> though; for a complete clone of Emacs, including the
>     Carl> development process, you would want to have an eval that
>     Carl> does no memoization and some sort of separate compilation
>     Carl> phase.
> 
> I don't quite understand.  By `interactive development process', do
> you mean what a user does with `C-x C-e', or something more specific
> to the core Emacs developers?

I meant `C-x C-e' (although I would have said `M-C-x').

> If the former, I don't see how you reach your conclusion.  What if you
> redefine a macro that was in use by a byte-compiled function?  It
> seems to me that what you need to handle this scenario is a
> recompilation protocol.  How does a non-memoizing eval and separate
> compilation help?

Usually when I'm developing an Emacs Lisp package that's simple enough
to fit in a single file, I will load the whole thing in interpreted
mode (typically by loading the file and using M-x
eval-current-buffer).  At this point, I know that no macros I defined
in this file are used by a byte-compiled function, so I can safely
redefine macros.  (Of course, things would be different if the package
were sufficiently performance-critical that parts needed to be
byte-compiled even during development.)

Carl Witty


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