As far as ldbg is concerned, it only traces the toplevel node, at
call event.

Note that I needed to rename quite a lot of modules to avoid name clashes
between lus2lic.a and ltop.

I've also merged the Verbose module with the one of Lutin so that
they can be shared (there were sharing 95% already).

1) At the Lic level, there's no reason to distinguish betwenn node
calls, and predef node calls. Indeed it makes things simpler and more
homogeneous afterwards.

2) int strings are only converted when necessary (constant evaluation).

3) const are handled directly under Lic.by_pos_op instead of being under
   PREDEF_CALL, which make things easier and more logical.

BTW, put everything that concerns node environement into the new
IdSolver module (from the Lic module).

Pascal prepared « the field » for that change.

Also, force the merge to operate over an ident rather than on any val_exp.

nb : do not work for lv4/ec mode

Also fix some bugs in DumpLic when printing condact in other modes.

nb : I've transformed all the regressions I've seen into todo entries
in todo.org.

nb 2 : I did not mv the newly broken tests into the broken dirs. I'll
do that for those I do not want to fix in the short term.

nb: les tests ne passent toujours bien sur.

* Partie lus -> AST

predef.ml -> srcPredef.ml
syntaxTreeCore.ml -> astCore.ml
syntaxTree.ml     -> astV6.ml
syntaxTreeDump.mli-> astV6Dump.mli

* Partie Ast -> Ast

solveIdent.mli -> astRecognizePredef.mli
syntaxTab.mli -> astTab.mli
symbolTab.mli -> astTabSymbol.mli

* Partie  AST -> lic (static evaluation)

eff.ml  -> lic.ml
getEff.mli -> ast2lic.mli
lazyCompiler.mli -> licTab.mli
builtIn.ml -> licMetaOp.ml
predefEval*.ml -> licEval*.ml
name.mli -> licName.mli

* Partie Lic -> Lic

uniqueOutput.mli      -> l2lCheckOutputs.mli
structArrayExpand.mli -> l2lExpandArrays.mli
nodesExpand.mli       -> l2lExpandNodes.mli
doNoPoly.ml           -> l2lRmPoly.ml
doAliasTypes.ml       -> l2lAliasType.ml
doSplit.ml            -> l2lSplit.ml

et donc ne marchent plus !

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.

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.

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.

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.

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

and PredefEvalClock.

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

(support for fill, red, etc. is coming soon).

In order to add support  for iterators, I have extended the by_pos_op
(and the by_pos_op_eff) data type with a list of static arguments. In
other words, iterators are handled as a particular case of predefined
operators.

not compile them is (well, was) the default...).

also, during pretty-printing, remove the type in the constant definition
(e.g., "const x = 42;" instead of "const x = 42:int;"), except if it is an abstract
constant of course

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 !!!

This is done via the new module EvalEq.

A lot of new errors appear in the on-reg tests, which is normal as
quite a lot of the code is now used...

EvalNode.f

rename back predef_node into by_pos_op.

currently only evaluates predef nodes.

	Do not test nodes with static params as it is too difficult
  	to do from the top-level automatically. Indeed, it would
	require to build effective static arg before, which would
	require to make node_check mutually recursive with type_check
	and co. Its not worth the trouble, as such node can be tested
	anyway if used.

LazyCompiler.solve_node_idref:
	compile (with the new function check_static_arg) static
	params instead of ignoring them.

EvalConst.eval_const -> EvalConst.f
	for simplicity and homogeneity with the naming scheme used in EvalType.