2009/4/4 john skaller <skal...@users.sourceforge.net>
>
> On 05/04/2009, at 12:26 AM, Emmanuel Onzon wrote:
>
>
>>
>> 2009/4/4 Emmanuel Onzon <e.on...@gmail.com>
>> 2009/4/4 john skaller <skal...@users.sourceforge.net>
>>
>>
>> On 05/04/2009, at 12:09 AM, Emmanuel Onzon wrote:
>>
>>
>> Dyp.Undefined_nt("comma")
>>
>> PARSE ERROR
>> Unknown exception Parsing File
>>
>>
>> U mean like this? but I still don't understand how "comma" can be
>> undefined..
>>
>> Yes, I mean this exception.
>> comma is well defined, but dypgen believes it is not.
>>
>> Why? It is even listed:
>>
>> Basically, it is because the way dypgen decides to raise
>> Undefined_nt is ill-designed and must be changed.
>>
>
> Exceptions suck .. a good idea to eliminate almost all of them
> and return a sum type instead, IMHO.
>
>
>> I'm going to work on that for the next version.
>> dypgen decides to raise Undefined_nt if
>> it finds in the extension a non terminal that is only in a
>> right hand side and not in a left hand side, disregarding
>> whether it is in a left hand side in the initial grammar.
>> You can call it a bug :)
>>
>
> Indeed :)
>
> BTW: I get this processing the initial grammar:
>
> Warning: non terminal `strue' is never in a right-hand side.
>
> I would like to *selectively* suppress these, say by writing
>
> @strue = { ... }
>
> I.e. not by a global flag to turn the warning off, but a way
> to say "yes, this nonterminal is intended to be used by extensions"/
>
> With that, Dypgen could throw out unused productions. This is useful
> if you have a large file of definitions to be used as a "library" which
> you include then define something using only a few of the symbols.
>
> Actually that suggests:
>
> %keep strue
>
> as a better syntax, since it would allow defining not only
> something based on a subset of a library, but also providing
> extensions with a set of non-terminals, but still eliding others
> that aren't significant.
>
Ok. But note that the non terminals detected by the warnings
are not thrown away by dypgen.
%keep strue
would just prevents dypgen from emitting a warning.
>
> With this kind of "garbage collection" together with some namespace
> management (some kind of structured names for non-terminals
> resembling say X.Y .. perhaps X'Y since that's a legal Ocaml identifier)
> this would make grammar libraries more viable, particularly if
> they could be saved "pre-compiled".. both these things are possible
> because Felix already does both of them :)
>
>
>> The build system is now doing this:
>> [...]
>> checking build/test/regress/rt/rt-1.01.30-0: ok
>> * build/bin/flx.py --test=build :
>> build/test/regress/rt/rt-1.01.31-0.flx -> build/test/regress/rt/
>> rt-1.01.31-0.so
>> checking build/test/regress/rt/rt-1.01.31-0.so: ok
>> * build/bin/flx.py --test=build :
>> build/test/regress/rt/rt-1.01.31-0.flx -> build/test/regress/rt/rt-1.01.31-0
>> checking build/test/regress/rt/rt-1.01.31-0: ok
>> * build/bin/flx.py --test=build :
>> build/test/regress/rt/rt-1.01.32-0.flx -> build/test/regress/rt/
>> rt-1.01.32-0.so
>> checking build/test/regress/rt/rt-1.01.32-0.so: ok
>> * build/bin/flx.py --test=build :
>> build/test/regress/rt/rt-1.01.32-0.flx -> build/test/regre
>> [...]
>>
>
>
> Running regression tests :)
>
> Hmmm .. that doesn't have my patch to "Bind_to_cons" all the RHS
> non-terminals ..!! I haven't
> committed that yet! It works anyhow .. hmm :)
>
>
> --
>
> john skaller
> skal...@users.sourceforge.net
>
>
>
>
>
------------------------------------------------------------------------------
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
