On Sat, Jun 13, 2015 at 6:11 AM, Keean Schupke <[email protected]> wrote: >> >> > The grammar specification in the type checking will be redundant. The >> > type-inference specification will be the same as the grammar (the same >> > clauses with additional arguments for the types). >> > On 13 June 2015 at 10:47, Matt Oliveri <[email protected]> wrote: >> That may appear so, but it's different, since the grammar refers to >> surface syntax, whereas a separate set of typing rules would refer to >> ASTs, and not involve surface syntax. The cases of the AST type(s) do >> not exactly match the cases in the grammar, so a separate grammar is >> not redundant. For example, only a grammar would have a case to wrap >> an expression in parentheses. Conventional typing rules do not need >> that case. > > I see where we disagree now. I do not deal in surface syntax, and I do not > like string based formalisms for this. For me the grammar is abstract and > hence about the AST that is accepted.
I like that policy. But then what are you calling a parser, if your input is already an AST? Based on this, you've been saying some misleading things before about combining CFG/EBNF with the type checker. CFGs--written in EBNF or whatever--are about recognizing strings of surface syntax. Whenever I've been saying "grammar" I was talking about a generator/recognizer of surface syntax. > If for example we are working in > homoiconistic language like Lisp or Prolog, then we can write the AST > directly: > > Lisp: > > (abs x (var x)) > > Prolog: > > abs(x, var(x)) Yes. > Specifying how strings get converted into the AST representation is the job > of the parser. Exactly, and I thought we were talking about combining parsing and type checking into a single pass. And I thought you were saying a combined parser and type checker would be an acceptable alternative to separate grammar and typing rules. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
