instanciated by a polymorphic operator.

iterated, was still printed using the prefix/long name method (e.g.,
"Lustre__not(a)"  instead   of  "not  a").   Moreover,  equality  was
inconsistently represented as "eq" and "equal". I choose the former.

still   printed   using    the   prefix/long   name   method   (e.g.,
"Lustre__and(a,b)" instead of "a and b".

expansed) type  definitions that were containing struct  or arrays in
the expand_structs mode.

var only! Hence, I tranform "#(a)" into "a" in the lv4 mode.

extern constants.

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

i.e., transform

      x,y = (0,1) -> (a,b);

into

      x = 0 -> a;
      y = 1 -> b;

where generated in the --expand-nodes mode..

(i.e., tuple of size one).

with a non-empty body (instead of just the first node).

some_clk" should be written "(x:some_type) when some_clk"

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.

node, as UniqueOutput.check take as argument the source info with the
original arity...

conjunction of some program transformation (-ei or -esa).

In Lazycompiler.node_check_do, I've forgotten  to put the node i/o in
the local_env table in the case of node alias.

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

For example, that kind of set of equations didn't trigger any error:

  x [1 .. 2][0][0].f1 = z ;
  x=y;

nb : it was working if equations were ordered differently tough...

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.

+ more work on the release dir.

lustre-v6 release.