On Sat, May 30, 2015 at 4:39 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sat, May 30, 2015 at 12:11 PM, Matt Oliveri <[email protected]> wrote: >> So BitC will automatically have a >> statically-checked solution to your problem, one way or another. > > I don't know of any language in which the Node<T> solution works.
So then I've misunderstood the problem, or you've misunderstood the solution. > Ignore, for a moment, the grouping issue that i raised earlier. Union leg > names are not types in current languages, and therefore cannot be specified > as a resolution for the type parameter T. Can you give a simple illustrating > example of how this would work? Maybe I'm missing something. I don't see a > mechanism to do type-indexed children. What it looked like you were doing to handle this was define all the things you want to be types as mutually recursive types. I was building on that by showing how you can still factor out the fields that are common to all legs of all types. >> You don't need to do anything special when defining "AST"/"Node" in >> order it thread recursiveness through it later. > > Sure you do, because union leg names aren't types! That's unrelated. All I was saying there is you can pass a recurrence as the type parameter of an already-defined type constructor, without having to define said type constructor in a special way. Whether that helps in your case or not is another question. >> By "thread recursiveness" through a type constructor, we mean pass a >> recurrence (a reference to something currently being recursively >> defined) to the type constructor, I assume. > > But in these languages there is no way to obtain a reference to either a > type constructor or a value constructor! For example, the Expr type, in our case. That's a recurrence, when inside the definition of Expr itself. Sorry if I'm making things worse with my semantics jargon. >> > The two parts of this that are a bit unusual are that the type AST< T <: >> > ASTTree > and the type ASTTree are co-recursively defined, so we >> > probably >> > end up needing something similar to letrec for this definition. Perhaps >> > typerec? >> >> Yes and no. AST<T> doesn't depend on ASTTree... > > Of course it does! The arguments we want at T are the leg types of ASTTree! Right. That's why the instances of AST<T> that we'll use _do_ depend on ASTTree. But still, AST<T> itself does not. Unless it does for some other reason that you haven't told me. What I'm saying is AST<T> doesn't depend on whatever we could potentially instantiate T to be. (Even if we already know what that will be.) This is really easy to just check by trying it in a language implementation, so I'm worried we're not understanding each other, even on this minor point. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
