Re: Syntax checks

[Dirk Herrmann <dirk@ida.ing.tu-bs.de>]

On 6 Apr 2002, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> 
>     Dirk> Hello everybody,
>     Dirk> in the evaluator, there are a lot of syntax checks performed that could
>     Dirk> probably better be performed in a previous syntax checking phase, keeping
>     Dirk> the evaluator itself free of such checks.
> 
>     Dirk> As an example, there is the 'do loop construct: In the body of the do loop
>     Dirk> you only have to execute expressions that can have a side effect.  We do
>     Dirk> not have a proper analysis for which expressions can have a side effect
>     Dirk> and which don't, but there is a simple syntactic criterion that can be
>     Dirk> used:  If the expression is not a list, then it is an object or a variable
>     Dirk> reference and can't have sideeffects.
> 
>     Dirk> Thus, the body of the do loop could be scanned in the macro transformer
>     Dirk> and freed of unnecessary expressions.  Then, the corresponding check in
>     Dirk> the evaluator could be removed.
> 
> What you say makes sense, but I'm struggling to see why it's really
> worth doing this.  Are you aware of a lot of code that puts pointless
> expressions in `do' bodies?

No, certainly not.  However, the evaluator has to check for it.  The
reason is the following:  SCM_CEVAL _must_ be called with a non-immediate.  
That means that whereever SCM_CEVAL is to be called with some expression,
the special case of an immediate has to be checked before doing the actual
call.

In the execution of the 'do body, every expression is checked to be an
immediate, and if it isn't, then SCM_CEVAL is called.  It is this kind of
check (and a couple of similar ones) that I try to remove, since it slows
down the evaluator.

> Also, does this fit into a more general picture of how we should
> evolve the interactions between transformation, evaluation,
> compilation etc.?  (I don't claim that such a picture exists, but it
> would be nicer if it did.)

I at least am not aware of such a general picture.  But, whatever it would
be like, it would require the following:
* a preprocessing (or compilation) of the code in order to reduce the
  actual work of the evaluator to a minimum.
* as a consequence, a more general way to track the relationship between
  source code and preprocessed (aka memoized) code.

My personal strategy is to move forward in small steps and learn during
that process.  A complete re-write of the evaluator and all of its
surrounding code (debugger, stack handling, source tracking, ...) is at
least for me too complex.  I don't know about the status of the other
attempts that are currently made towards this goal, but it seems that
there is little progress.

As you may have noticed, I have already started to clean up the evaluator
code (although that process is far from finished yet).  The number of jump
labels has been reduced, the intra-function communication has been
simplified and the code has been made somewhat easier (IMO) to understand.  
Things are going slowly, but they are proceeding :-)

>     Dirk> * Removing unnecessary expressions from code would change the source in a
>     Dirk> way that can't be restored by unmemoizing.  Do we care?  In the long run
>     Dirk> we will probably want to allow more transformations on the source anyway
>     Dirk> for the sake of optimization.  Then, memoization/unmemoization won't work
>     Dirk> and we will have to provide a different mechanism to record the
>     Dirk> relationship between transformed code and the source.
> 
> I don't have much experience here, but your general point sounds right
> to me.  That is, rather than unmemoizing, we may eventually need just
> to keep a copy of the original source.
> 
> >From the debugging point of view, the requirements are that
> 
> - breakpoint positions are preserved as code is transformed
> 
> - when a breakpoint is hit, it is possible to map back from the
>   transformed breakpoint location to the coordinates of the breakpoint
>   in the original source.

I have to admit that I have not taken a look at how debugging works.  If
you agree, we can work together:  Before doing any changes to the
evaluator, I would double check with you.

>     Dirk> * Should warnings be issued when dead code is eliminated from the source?
> 
> I guess it should be configurable :-)

That's what I think, too.  However, there are some difficulties with
macros:  A macro can be used perfectly fine, but resulting in a construct
with some dead code.  You might not be interested in warnings in such a
special situation, while in all other situations you might want to be
warned.  I think, it is best to start with issuing warning messages to a
dedicated output port and think of improvements later.

Best regards
Dirk Herrmann


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