2015-02-11 11:16 GMT+01:00 kilon alios <kilon.al...@gmail.com>:
> "What you see is that, with the {{}}, I create PyAtomNode instances for
> all productions, even if it isn't appropriate. Maybe this should be changed
> like that for lists :
>
> | <lbrack> <rbrack> {{List}}
> | <lbrack> listmaker 'list' <rbrack> {{List}}"
>
> Both approaches you described a) adding instance methods to PyAtomNode
> that provide checks for the type b) Creating separate nodes for diffirent
> types work for me. Solution (b) seemed more smalltalky to me. Maybe a best
> compromise would be to have for example PyListNode as a subclass of
> PyAtomNode ?
>
Yes, if you find that appropriate or if they share some implementation bits
(I'm not sure of the latter, but it may help to organise stuff). What you
do is, in the grammar, you add a %hierarchy directive, like that:
%hierarchy Atom (List Dictionary);
And, at AST generation, SmaCC will inherit as much as possible from Atom
definition in List and Dictionary (at least, I suppose it does: some of the
SmaCC code generation tools are rather impressive, and, if you look
carefully, it is prepared for more than just generation of Smalltalk code)
> If I can create something that others find useful too, I certainly would
> prefer it. My needs are not very specific, I think I want pretty much what
> anyone would want for importing data from python to pharo . One way or
> another I will satisfy my needs this is not my worry.
>
And that's fine to refactor the grammar to match your requirements :)
>
> "And the last one is about the visitor. For complex processing like the
> transformations you intend, I would see two strategies: a builder inside
> the visitor with a stack/context strategy, so that you can recurse in your
> visit of the ast and add elements to the right collection, or a simple
> recurse and merge the result of the lower visits (when in a List node,
> collect the visit of all the children as an array or as an
> OrderedCollection)."
>
> Yes that was my way of thinking too. A collection of methods that consume
> the AST , walk the tree and build a more simplified structure.
>
> The problem I was having was two side, from one side PyAtomNode is used
> for several diffirent things. From the other side not only lists,
> dictionaries, tupples can be multidimensional but also can act as
> containers for each other. So a list can contain a dictionary which can
> contain a list which can contain a tupple and as you imagine the rabbit
> whole can go very deep. Of course nothing of this is surprising for any
> language.
>
> Generally speaking this is not such a big problem right now for me because
> I prefer dealing with simple types with a bit of multidimensionality. Most
> of the types Blender uses is like that. But it may become a problem later
> on for example if the user wants to have access to the node system of
> blender. Nodes can easily contain other nodes and it can create a nightmare
> scenario in that case but I will leave that for when the time comes.
>
For me, the way to deal with that is to have a model of that data and
visitors on it, to tackle the "future" complexity.
If you go that way (recursive structure), two good (and not that easy)
things to have are: equality and copy.
>
> "I believe you are on the right path, if my explanations made sense :)"
>
> Your explanation not only made sense but you pretty much described what I
> was considering doing.
>
See, I don't have much to do then ;)
>
> "If you start changing the grammar as suggested above, make a fork and
> pull requests on github :)"
>
> Will do, my focus is in latest python 3 because its what Blender uses, but
> on types should not make any diffirence.
>
Good point. It would be nice to have a diff on the grammars of Python2 and
Python3; at the moment, there is space in the naming for a Python 3 parser
(named PythonParser3, of course), however we would have a collision on the
AST nodes (two PyAtomNodes, two ...). Have to consider that and maybe have
Py2AtomNode, etc... to leave space for the Python 3 AST if it differs too
much.
Thierry
