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.

is  part  of  the  Eff.node_ney  via  static  node  parameters.   The
consequence  was  that some  nodes  (the  ones  with node  as  static
parameters) were and printer several times (if used several times in
the user program)!

"one_op_per_equation" mode.

(--inline-iterators) to activate it.

nb : do not inline completely nested iterator calls (yet, cf TODO).

(Hat) were handled incorrectly.

by position). Rename ExpandPack into InstanciateModel.

dead hits versus all hits).

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.

simple, and also avoids  3 shift/reduce conflicts. It also make
the pragma stuff more homogeneous  and simple to explain in the
manual.

Moreover, pramgma  are no  more attached to  AST nodes,  but to
lexemes.

internal errors.

around the rigth-hand-side.

Note that by polymorphic here I mean *really* polymorphic, since they
can handle tuples, which is no the case of, let's say, "<".

splitting expressions.

polymorphic operators.

For instance, when LicDumping expression such as

    map<<map<<+,4>>,5>>

an  alias  node was  created  for  "map<<+,4>>"  (to unnest  iterator
calls). Fut this node is intrically overloaded (polymorphic). In this
change, we  look at  the type this  innr call  is used to  generate a
specialised (mono-morphic) version of the node alias.

Note that we currently still generate type variable when users write

     node mymap = map<<+,4>>;

+ enhance  error msg  (which helped finding  the bug, but  that migth
also be useful for ed-users...).

The  idea  is  the  following:  each  time  a  nested  iterator  call
(map<<map<<n,3>>,4>>) is  encountered, we  create a fresh  alias name
(create_alias_name) ad we  add it in the node_alias_tbl.   At the end
of the  compilation, LicDump.dump_node_alias is  called, which prints
the definition of those node aliases.

For example, the expression  "map<<map<<n,3>>,4>>" is printed like this:

    map<<_node_alias1, 4>>

and later, the node alias is defined:

    node _node_alias1(x:int) returns(y:int); let y = map<<n,3>>(x); tel;

enum nor a bool.

prefixed by "_".