On 28/01/2011, at 7:45 PM, Emmanuel Onzon wrote:
>
> So, if I have a ref to global data somewhere, and I also use it in user
> actions,
> what happens?
>
>
> You're not supposed to have a ref to global data. Global data is supposed to
> be not mutable (except if the parsing is always deterministic). The way to
> use global data is to return a fresh value to the parser from a user action
> in the parser command list.
That's nice in theory but not so easy to do in my context. What I have is
Scheme code
in the user actions that has to refer to the production symbol properties and
source
references. There's also a need for a unique counter. Finally, Scheme helper
functions have to be defined.
All these things are done with mutation of the Scheme interpreter state.
As mentioned before "unfortunately" Scheme is not purely functional.
There is no easy way to "control invert" Scheme code in the middle of a user
action, return the "continuation" so that later we can extend the state further.
This is a universal problem with callbacks, including user actions.
What I CAN and do do is use things like (define (f x) ....
which are mutators of the interpreter state. It would take a Scheme expert to
figure
out a way around it.
In the case of symbol properties, the use of a fixed set of global variables is
ugly,
but it is localised to a single user action (the variables are assigned before
the Scheme
is run and don't matter afterwards). If Dypgen actually used *threads* for its
threads this
technique would fail.
The *right* way to do this is possible but tricky: the user actions should be
designed
as functions accepting the symbol properties. Indeed, that would be very nice
because
it would make them independent of mutable global state (though they'd still need
global constants such as helper functions). But I shuddered in horror at the
idea
of trying to make this work AND be confident there'd be no performance penalty.
It would be a major change to undo if it turned out not to work or be too slow
(and there are other parts of Felix to work on .. :)
There's another thing you're missing here too: the scoping of a purely
functional
data set required for parsing and the scoping of grammar extensions are
DIFFERENT
scopes. So it becomes much harder to implement what you say should be done,
since the "fresh value" returned to the parse goes out of scope, and it doesn't
matter which of the two scopes I try to use, I need the other one too :)
To be clear, Felix lets you do this:
module Fred {
syntax Joe { .. }
open syntax Joe; // use the syntax extensions
// stuff using Joe syntax
id = $fresh_id .. // get a unique integer
}
// end of the module, Joe Syntax is out of scope now
// id2 = $fresh_id .. // get a unique integer
So here when Joe goes out of scope, $fresh_id had better not.
It is only going out of scope in a dead parse thread (more precisely,
it is OK to have duplicate fresh_id in each parse thread provided
all but one die).
Note this is just an example.
NOW, I believe that this actually can be implemented now, since you can
construct any global_data you want, so you can pop stacks of things to make
stuff go out of scope, and propagate the global data linearly. But I'm not sure.
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
