not use the module name. Otherwise, names with "::" are created, and
sometimes the lhs of the "::" does not even correpond to an existing
module.

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.

the moment, I just don't generate such operator anymore (i generate the
polymorphic version Lustre::lt instead). I don't really know what is the
better.

fixing the v4 backend : print "+" instead of "Lustre::plus" (and ditto for the others).

When a node P::n1 wants to access to a node P::n2, it is ok to
search for it in the boby of P.

nodes (e.g., map<<+,2>>). While fixing  that, I put all the functions
that deals with polymorphism into a new (Eponymous) dedicated module.

The idea to be able to expand polymorphic node is basically the same,
as the one for printing polymorphic  nodes: we need to wait until the
type is instanciated (in GetEff).  That delay is implemented by using
a stack of nodes.

an expanser to will expand only struct, and i whant to name it like that).

+ more work on the release dir.

lustre-v6 release.