Felix now caches the standard syntax in a disk file.
This is similar to the *.par cache of parsed files.
The preprocessor directive

#syntax <filename.flxh>

saves the parsed syntax in

        filename.flxh.syncache

using the Ocaml Marshal feature, unless the file already
exists. In that case it loads it instead, and skips
processing the flxh file entirely.

NOTE: although there IS a timestamp check, it doesn't
seem to work. If you have parsing problems try deleting

        lib/nugram.flxh.syncache

This is a trick feature. #syntax can only be issued ONCE
and the file must contain only syntax definitions. 
This is because loading the syntax simply sets the 
Dypgen 'local_data' variable which contains
the parsed syntax definitions.

//***************************************

At the same time, the #keyword preprocessor directive is 
deprecated. At present #syntax doesn't load or save user
defined keywords, therefore they're forgotten. So, I have
removed the user #keywords 'forall', 'whilst','upto', 'downto'
and replaced the syntax with:

  sifgoto := "forall" sname in sexpr do statement* done ; 
  sifgoto := "forall" sname in sexpr "upto" sexpr do statement* done ;
  sifgoto := "forall" sname in sexpr "downto" sexpr do statement* done ;
  sifgoto := "whilst" sexpr do statement* done; 
  sifgoto := "until" sexpr do statement* done; 

What this means is Dypgen will parse an ordinary identifier where
it sees "keyword", then checks the identifier is spelled "keyword".
This is exactly how user defined keywords were processed before,
except that they had a special token USER_KEYWORD whereas identifiers
just used NAME. The effect is to slow down the parse slightly, and
also introduce possible ambiguities, however these words are
no longer keywords, and can be used as names in any context
OTHER than the statements above .. or more precisely, any
context that *looks like* the syntax above. In case of
ambiguity, the last written production should take precedence.

At present, this is not done quite correctly in the nugrammar.
In particular the very nasty 'expression statement' and nasty
'assignment statement' should be the first productions,
to so this interpretation is considered a last resort.

There's an issue with this, that the 'aging' of productions
and the successive partitioning by using tree structured
nonterminals both conspire to change the 'merge' semantics.
For example the sifgoto nonterminals are disambiguated first
in order of writing their productions, THEN that is disambiguated
against the other nonterminal classes like sassignment and scall:
the current ordering is:

  statement:= sexecutable =># "_1"; 
  sexecutable := scall =># "_1";
  sexecutable := ssvc =># "_1";
  sexecutable := sreturn =># "_1";
  sexecutable := sifgoto =># "_1";
  sexecutable := stodo =># "_1";
  sexecutable := sassignment =># "_1";
  sexecutable := sgoto_statement=># "_1";
  sexecutable := slabel_statement =># "_1";

which means an sgoto always 'beats' any scall,
however an assignment 'beats' any sgoto. This is because
the current aging uses only the top level production age:
the age of the detail production is relevant only when
merging that detail nonterminal. I'm thinking to introduce

        alias statement ( sexecutable ( scall, ssvc, sreturn ..

i.e. a tree of aliases. The use of nonterminal names like
'sexecutable' or 'sdirective' or 'sdefinition' was actually
intended for documentation purposes, not ambiguity resolution.
Such an aliasing will also remove unnecessary reductions.
[Note that Felix still isn't using any of Dypgen's priority
system because I can't figure out a good syntax for using it
concisely .. i.e. without polluting the grammar with lots
of priority annotations]

I plan to eliminate quite a lot of keywords like this.

Note: you can *force* a USER_KEYWORD by the token spelled:

        k"user keyword"

but of course you have to write that in both the grammar AND
in your user code.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to