On Sat, May 30, 2015 at 12:11 PM, Matt Oliveri <atma...@gmail.com> wrote:
> > From a language design perspective, there seem to be two possible ways to > > deal with this sort of pattern: > > Maybe we had a misunderstanding. The Node<_> solution I gave a week > ago is something that I believe can already be applied in pertty much > any language with generics. (But it seems useful primarily when you > don't have subclasses, since subclasses already let you factor out > common fields to the superclass.) 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. 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. > 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! > 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! > > 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! > shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
