2011/2/11 john skaller <skal...@users.sourceforge.net>
>
> On 11/02/2011, at 8:06 PM, Emmanuel Onzon wrote:
>
> > BTW: using StackOverflow the reason for Marshal failure of Felix
> automaton
> > now seems to be that OCS Scheme contains un-Marshalable WeakArray... ;(
> >
> > Ok,
> > I'm guessing a version of the parsing_device that doesn't contain any
> user action would be marshalable. One can imagine marshaling the
> parsing_device without the user actions. After loading it, it would be
> necessary to attach the user actions to it. For instance Felix could
> resubmit all the couples (rule, user action), then dypgen wouldn't have to
> build the automaton but would use the couples to attach the user actions to
> the parsing device.
> > To do this you would need dypgen to return the current parsing_device
> without the user actions and a function that would attach the user actions
> to the parsing_device.
> > What do you think about this?
>
>
> Something like that may be necessary, however it isn't clear it should be
> done by Dypgen.
>
> Consider that the user action is rewritten something like this:
>
> { (Hashtbl.find myhash index) () }
>
> Then the user action is again Marhsal'able, and the onus is on the
> application to
> load and save the table of action functions.
>
> My problem remains: how to save compiled Scheme code. Possible the answer
> is:
> save it uncompiled and compile (once) on loading.
>
> Since my user actions are machine generated, generating a unique index etc
> isn't a problem.
>
> in fact, all the Scheme actions are already saved "uncompiled", as part of
> the
> grammar, its just that loading them not only compiles them, it also builds
> the automaton.
>
> So my *guess* at the moment is that you shouldn't have to modify Dypgen
> to support this, and even if you did, it wouldn't save much. In fact, it
> might
> actually get in the way. For example with the Hashtable there is no
> ordering constraint: I could load the automaton THEN compiler the scheme,
> or, I could compile the scheme, THEN load the automaton.
>
>
It wouldn't get in the way, it would not force you to compile first. It
would just be not useful.
> Whereas if Dypgen tries to maintain the map, it might force the order,
> if for example you chose to use a Map or a functional data structure
> rather than an imperative one.
>
>
I don't see how it would.
The data structure I have to access the user actions is an array of list of
actions.
the index of the array is the integer that identifies a grammar rule. When
reducing with a grammar rule which identifier is the integer i, the parser
look up the array at the index i. There it finds a list of actions that are
all the user actions associated with this grammar rule (most of the time
there is only one action).
The other structures are: a list of couples (rule, action list) that
contains the same information as the array, and a hashtable that returns the
id of each rule.
> My big problem is that there's a fair amount of work to implement this,
> and it may not save any time :)
>
> Unfortunately .. this is a "suck it and see" experiment, both on finding
> out
> how hard it is to do, if there are any problems which suggest Dypgen HAS
> to do it, and finally if it was worth the effort.
>
> Bottom line: I think you shouldn't do it at this stage, unless someone else
> also needs it.
>
>
Doing it on the dypgen side should be straightforward.
> The really big plus would be if the save could be done without
> any closures, because that would make the saved data portable
> between many tools that happens to all analyse the same language.
>
>
> --
> john skaller
> skal...@users.sourceforge.net
>
>
>
>
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
