maintaining (ugly and error-prone) hash tables.

That change revealed an untriggered bug in EvalClock.check_args: it was wrong
to add in subst the substitutions made of the parameters and the arguments (it
is enough to unify the clocks of the pars and of the args). For instance, consider
the node (in should_work/clock/clock.lus)

   node clock5(x :  bool; y:  bool when x; z: bool when y)

and the call

  z2 = clock5(a, b when a, c when e);

I was adding y/b in the subst, which was wrong.

Other minor changes:
 - move const_to_val_eff from Eff to UnifyClock.
 - GetEff.translate_val_exp now returns a substitution, in order to be able
   to unify clock vars and propagate the resulting substitution.

not expanded.

instanciated by a polymorphic operator.

In  short, the  rationale for  this change,  is that  it is  having a
recursive node_exp is
- useless,
- too complicated,
- wrong w.r.t. nesting iterator calls

In long:

- It is useless because, at the  Eff level, a node cannot call itself
  via one  of its  static arg (which  was where the  recursivity came
  from).

- and indeed, it  is much simpler to consider that  a static arg node
  can only be ident.long that identifies a node alias.

  This  means of  course, that  nested iterators  have  been unnested
  before,   inventing  alias   node  names   along  the   way...  And
  polymorphism makes thing difficult once again.

- But the  *big* problem  with a recursive  node_exp is that  it make
  things very  complicated to (lic)dump nested  iterator call because
  of polymorphism!   Actually, it  even makes thing  complicated when
  the iterators were themselves not nested in the source code !

  Some ugly  things were done in  LicDump to unnest  those calls when
  printing node_exp.   But this uglyness  have a price:  tricky code,
  and bugs! Indeed, nested iterators calls were wong for example when
  using  the --inline-iterator  mode (but  i would  not  be surprised
  that is wrong in other cases...).

Hence,  LicDump  is  simpler,  but  of course  LazyCompiler  is  more
complicated.  But  this  is  reasonable:  a  pretty-printer  is  not
supposed to be complicated.

change the parser and accept only clock expressions after a when.

A clock is now made of 2 idents: one for the clock constructor, and
one for the clock variable.

as many  new local  variables as necessary  so that an  expression is
made at most of one operator.

The rational  for that  is to obtain  a lic  code that is  trivial to
clock check (nested node calls, for example, make it less simple).

The old behavior can still be obtained using --keep-nested-calls.

During  that  change,   I  realised  that  I  did   not  clock  check
asserts. Hence, I have also added this check.

clock_info, and  therefore also  remove clock_info. The  rationale of
this  change is  that  it  makes things  slightly  simpler, and  more
homogeneous with what is done in type checking.

It  does not  work, I  have changed  my mind  to use  a  more general
clocking algorithm based on  unification. I commit that current state
just in case I change my mind again...

type_eff_ext into type_eff btw). The  rationale is to be able to type
alias           on           polymorphic          nodes           (cf
test/should_fail/semantics/bad_call03.lus,  that now  have  a correct
error msg).  It also makes  to code more compact (no more translation
from one  to the  other), and more  general (type_eff_ext  being more
general than type_eff).  User polymorphic nodes should be easy now.

move all the code in parsey.mly into parserUtil.ml (ease the debug).

equations is not done at all yet). Also, print the clock decorations
(when clk) in the generated file.

performed. The resulting code is both more compact, and more general.

It is more  general, since that predef operators  are now represented
by  node_exp_eff, exactly as  user nodes.   Hence, all  the functions
that were  operating on  user nodes via  node_exp_eff (such  as, node
aliasing) works for free on predef op!

In order to be able  to perform that generalisation, it was necessary
to  extend sligthly  the data  structure used  to represent  the node
profile in CompiledData.node_exp_eff with information indicating if a
variable is polymorphic or overloaded.

Not that, currently, polymorphic  or overloaded variables can only be
introduced by predef  operators. But I think it would  be easy to add
those notions for normal user nodes after this change.

New non-reg files boolred now compiles. Those involving
- boolred
- alias on predef.op

Also, node aliased to other nodes were handled poorly: I was replacing
in the syntax tree the node by its alias. Now, I really define
the alias node using the aliases one.

For instance,

    node toto(x:t) returns (y:t);
    let
      ...
     tel
     node titi = toto;
     node tutu(...) returns(...);
     let
        ...
	z = titi(a);
     tel

was compiled into

    node toto(x:t) returns (y:t);
    let
      ...
     tel

     node tutu(...) returns(...);
     let
        ...
	z = toto(a);
     tel

Now, I generate

     node toto(x:t) returns (y:t);
     let
       ...
     tel
     node titi(i1:t) returns (o1:t);
     let
       o1 =toto(i1);
     tel
     node tutu(...) returns(...);
     let
        ...
	z = titi(a);
     tel

which is equivalent, but closer to the original program.

For non-regression tests, do not use Lazycompiler.test function
anymore and just use  LazyCompiler.node_check instead.

put in the new file compiledDataDump.ml all the stuff
related to string convertions of CompiledData items.

and anonymous structures. I've even found some type errors in the non-reg files!

operators. Predef contains the abstract syntax of those operators (taken
for SyntaxTreeCore.by_pos_op), and PredefSemantics contains:

 - const_eval: that says how to statically evaluate constants
 - type_eval: that provides the type profile of predef operators
 - clock_eval: that provides the clock profile of predef operators

The code in EvalConst that dealt with predef const evaluation is now in
Predef.const_eval

EvalNode.f -> GetEff.node,
EvalType.f -> GetEff.typ,
EvalEq.f -> GetEff.eq

EvalConst.f (val_exp -> const_eff list) should have been put there too,
but in fact EvalConst.f ougth to be splitted in two parts:
  - val_exp -> val_exp_eff (but this function already exist)
  - val_exp_eff -> const_eff list

Therefore, the signature of EvalConst.f will be changed to:
val_exp_eff -> const_eff list (and will use GetEff.val_exp)

Ditto for eval_array_index.

 eval_array_index : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int -> int

ougth to be splitted into two functions:
   - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff
   - SyntaxTreeCore.val_exp_eff -> int -> int

Ditto for eval_array_size

 eval_array_size : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int

ougth to be splitted into two functions:
   - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff
   - SyntaxTreeCore.val_exp_eff -> int

arg... evalConst.f est utilis par GettEff.typ !!!