On Mon, Jun 1, 2015 at 10:58 AM, Matt Oliveri <atma...@gmail.com> wrote:
> I don't see forward references as fundamentally different from
> recursive definitions, since that's exactly what they let you do....
Yeah. Never mind. Don't know what I was thinking when I started in on
co-recursive types. Chalk it up to a brain fart.
The question from a language design perspective is whether we want to
consider getting rid of forward declarations altogether in favor of using
LETREC and TYPEREC (placeholder name) for that purpose.
For types, I don't think we even need TYPEREC, because everything you can
do with TYPEREC is subsumed by parameterization. E.g. you can simply use a
type variable as a placeholder. So e.g:
struct S 'a {
... other fields ..
recursive : 'a
}
struct corecurse {
corecurses : S corecurse
}
or some such. If that suffices, then there is no real semantic gain to
forward declarations, but I still think there is some expressive
simplification to be had from them.
The awkward part about forward declarations is that they introduce some
subtleties about subsumption checks where the declaration and the
definition get compared for consistency, but it's nothing we can't handle.
The other question, I suppose, is whether we really need LETREC at all
given the existence of forward declarations. I'm not inclined to remove it,
but it's still helpful to know which constructs are adding power to the
language and which ones aren't.
> > But I don't even see a good solution for CFGs, because of the "subunion"
> > issue. I know how to deal with that using dynamic checks, but not
> > statically.
>
> I guess I don't see why subunions are important for ASTs for CFGs. It
> seems to me like unions of unboxed tuples are good enough. Subunions
> would additionally guarantee the use of the same tag for the same leg
> in all subunions of a given union. But why is that so important? And
> of course, those unboxed tuples being unboxed is an optimization. It
> still works if they're boxed.
>
I'll respond to this separately.
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
