On Fri, May 15, 2015 at 5:49 PM, Matt Oliveri <atma...@gmail.com> wrote:
> On Fri, May 15, 2015 at 11:58 AM, Matt Rice <ratm...@gmail.com> wrote:
>> On Fri, May 15, 2015 at 7:59 AM, Jonathan S. Shapiro <s...@eros-os.org>
>> wrote:
>>> So I have a "how do I use this idiomatically" sort of question...
>>>
>>> In ML/Haskell and friends, there is no syntactically simple way to say "all
>>> legs of this union have the following fields in common". You either build a
>>> structure with the common fields and mention it explicitly in every leg of
>>> the union, or (conversely) you make the union an element of a larger
>>> structure.
>>>
>>> AST nodes are a use case. They tend to have a large number of common
>>> metadata fields (position, type, auxiliary marker bits of various sorts...)
>>> and a small variant part describing the children of the node.
>>>
>>> Is there a common idiom that people use in cases like this?
>>
>> in ML i've always used the latter, where the common elements and the
>> union are elements of a larger structure
>
> That's what I'd do. You want to factor out the common stuff, even if
> it's just types, or else you'll feel silly needing to factor out the
> handling of the common fields in each pattern match. (OTOH, if you
> know in advance that the way of handling the common fields will
> actually not be the same across cases, then probably you shouldn't
> factor the type either. Basically, whatever's convenient.)
mea culpa, I looked again at my AST trying to figure out how I managed
to have common stuff pulled out, and reference well typed subsets of
the AST
and indeed I misread what I had done (has been a while since i've
worked on it)... why on earth I named both type and fieldname the same
is beyond me.
so I did use the first in expediting progress
In general I was never happy with this (as Matt clearly says it makes
pattern matching long winded, but its what I started with and haven't
ripped apart the whole thing to try and find a better way...
what i'd prefer is using a tuple for the common stuff, or at least
stuff like the line numbers, and have the types contain only their
necessary components
so instead of: Let of {decls:Decl list, body:Expr, pos:pos}
something to the effect of Let of {decls:(Common * Decl) list,
body:(Common * Expr)}
the latter has more complex typing, but gives much more flexibility in
number of ways you can pattern match, and more importantly when you
can strip off the common stuff to avoid having to pattern matching
everything.
so in a sense there is a question here of whether you want more
readable types or cleaner pattern matching options, to expedite things
i went with simpler types, and certainly regretted it
I'm not sure if this matters too much since you seem to want to avoid
pattern matching *in* bitc, and it's useful to write it in as close an
approximation of the target language as one can manage...
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
