Re: Syntax checks

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> 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?

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

    Dirk> I would like to apply such changes, but I have some questions:

    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.

    Dirk> * Should warnings be issued when dead code is eliminated from the 
source?

I guess it should be configurable :-)

It isn't currently possible to set source properties on something that
isn't a pair, so at least you don't need to worry about eliminating
code with important source properties on it (such as a breakpoint).

        Neil