Okay, I see now. My first intuition is that this is impossible in a statically typed language (without dependent types) as you won't get any runtime-polymorphism, which you need as you don't know the source code you are going to feed the compiler until runtime.
There are all sorts of type-system hacks (like we did in the HList paper) to force this kind of typing to work in Haskell, but its going to be difficult to read and maintain. The only way I can think off the top of my head is with polymorphic recursion and continuations. So polymorphic recursion is used to try all the possible parsers at a given point, then the successful parser calls the continuations with the result type. At the end of parsing a continuation would be called with a statically typed tree. Keean. On 11 June 2015 at 15:47, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Jun 11, 2015 at 7:18 AM, Sandro Magi <[email protected]> > wrote: > > >> If the type is unclear at any given point while parsing, couldn't you >> simply assign a type variable until parsing is complete? > > > I do not believe so. > > First, the type of the entity appended to the parse stack is totally clear > for every shift action. The types of the top K items on the parse stack and > their replacement item is perfectly clear for every reduce action. The > actions, in turn, are a pure function of the current parser state and the > lookahead token (that is: in bottom-up parsers). So it's not that we don't > know what the type is. It's that we can't express the relationship between > that type and the (state, lookahead) pair. > > You can't get out of this with a type variable, because the parse stack > cannot be instantiated with a non-concrete type. > > > shap > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
