[nem-en] Please, describe variables...

Kamil Skalski kamil.skalski at gmail.com
Fri May 18 20:17:40 CEST 2007


>       Typer_checked_macro = null;
>       Typer_unchecked_macro = null;
>       Typer_yield_macro = null;

These are caches for catching "builtin" macros, like
checked {  x *= 2 }   --->    _N_checked_macro ( <[ x *= 2 ]> )
unchecked { x *= 2 }
foreach (x in xs) yield x;

which allows typer to catch "manually" all the nodes where those macros are used

They can be nulled safely, since Typer (AFAIR) always checks if they
are initialized. You could also remove the nulling, but you should
reset them in case the core macros (Nemerle.Macros.dll) are reloaded.

>       StaticTyVarId = 0;
>       Typer_DT_Id = 0;
>       TyVar_Id = 0;
>       Util_Id = 0;
>       AttributeMacroExpansion_global_nr = 0;

They are just the counters used to generate compilation-wide unique
identifiers for various objects, like TypeBuilders, variable-names,
etc. They are used mainly for comparisons and for making sure that
compiler or macro-created variables do not clash with others.  If you
reset them, then there might appear collisions with old objects.

>       Macros_in_pattern = false;

This is a little hack to distinguish between

def x = <[ some_quoted_code () ]>
and
match (x) {
   |  <[ some_quoted_code () ]> => ...
}

as we need to translate quotations to PExprs a little bit differently
if we are in pattern or in plain code. This variable is used only
locally by Macros module when translating single quoted expression.

>       Message_error_cnt = 0;
>       Message_warning_cnt = 0;
>       Message_emitted_hints.Clear ();

This is the counter of errors / warning, which appear during
compilation. We use it to decide at the end if compilation should fail
or succeed. The emitted_hints is used to prevent emitting the same
"hints" several times, like "use _ or _name to disable unused variable
warning".

>       TyVar_reuse_queue = null;
>       Typer_BetterTypeCache.Clear ();

I'm not sure, maybe Michal will know, or some code inspection is needed.

>
> In VS Integration we not reset NamespaseTree (we only remove TypeBuilders
> from it) and method KillStatics() reset Util_Id. It cause bad match in cases
> like:
> tc.Equals (InternalType.Object_tc)
>
> I try splitting it method to too. But I not fully understand what do each
> variable.
>

I think that you can disable reseting the counter, maybe only make
sure that they won't overflow after a long time without full restart.
The code, which increments them should be easy to localize and fix,
e.g.   unchecked {  Util_id++ }
Or maybe you could detect if they go very high and then order full
reset of project state.


-- 
Kamil Skalski
http://nazgul.omega.pl



More information about the devel-en mailing list