et donc ne marchent plus !

IDENT remplacé par VAR_REF/CONST_REF
- plus de node_exp dans les CALL, juste une ref (node_key)
- reste a faire pareil pour les NodeStaticArgEff

qu'un noeud global avec param statique
i.e. node toto<<node foo...>> quand il existe un
node foo<< ...>> globalement
(cf. nodeparam.lus)

importante du mecanisme de UnifyType :
- fait :
  * definition de Eff.poly_match
  * TypeVar type_var au lieu de Any/Overload
    avec type_var = Any | AnyNum
    (pour l'instant et pour longtemps ?!)
- à faire :
  * revoir UnifyType pour qu'il rende un poly_match
  * stocker là où c'est nécessaire les poly_match
    calculés lors du type check
    (pour les CALL et peut-être les sargs ?)

Plus facile à chercher !

parametric nodes (or predef iterators) are nested.

Before, nested iterators were handles as follows : a source-level
(i.e., not compiled) alias node was created on-the-fly, and then
compiled. But this way to proceed was buggy for static args coming
from nested iterators or nested parametric nodes.

Now, I rely on Inline.iterators to get rid of iterators (the iterator
inlining is now recursive).

Add a -tlex option to debug the lexer.

Also, rename the rules in parser.mly now that their appear in the manual.
This renaming work is in progress though.

Fix a performance bug that was occuring with programs having a lot of variables and that were using constant.

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.

info is attached to all  val_exp. Moreover, this allow to perfrom all
the  type checking  in  EvalType.f, instead  of  doin part  of it  in
GetEff.translate_val_exp.

maintaining (ugly and error-prone) hash tables.

constants that  are not  on the base  clock, add the  suitable "when"
statement if it was not present  in the source code (the lic (and the
ec/lv4) backend  does not  perform such kind  of clock  inference for
constants.

instanciated by a polymorphic operator.

as extern constants.

Also  fix  a  bug   in  the  struct/array  expanser:  when  expanding
structured constants  into val_exp,  I need to  add a entry  into the
type and clock val_exp tables.

 - expr such as "current x,y" should be written "current (x,y)"
 - abstract   struct  or   array   types  were   handled  as   extern
   types, which  prevent the struct  and array expanser to  work them
   out. In order to fix that, I have added an Abstract_type_eff variant
   to Eff.type_ which contains the concerte type.

2 source transformations), we add an entry in the EvalType and the EvalClock
tables. Otherwise, when we use EvalType.lookup or EvalClock.lookup, an error
migth be raised.

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.

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.

The rationale for this change is that this is necessary for constants
appearing static  arg to  be replaced. One  problem is that  they are
handled in exactly  the same way as top-level  constants, which could
be left  un-expanded. I could make  something in order  to not expand
those top-levelconstants, but is it worth the trouble ?

To do that,  I have changed sligthly the  representation of Eff.ARRAY
(the elements  are now  attached to the  constructor itself,  and the
operands  is empty)  and  the one  of  array constant  (we attach  to
Array_const_eff  a  list  instead  of  an  array,  for  the  sake  of
homogeneity) with what is done in Eff.val_eff.

(Hat) were handled incorrectly.