"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 ?
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 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.
"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.
"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.
