puffnfresh / roy

Small functional language that compiles to JavaScript.
http://roy.brianmckenna.org/
MIT License
834 stars 74 forks source link

multiline object type aliases #196

Closed kennknowles closed 7 years ago

kennknowles commented 10 years ago

I really want to write this:

type Whatever = {
  field1: Type1
  field2: Type2
  field3: Type3
  ...
  // 10 or so more fields
}

Happy to put commas in there if I must or put newlines in different places.

From the grammar, examples, and my experimentation, I cannot sort out how to format such a thing in a sane manner. How should I proceed?

It seems straightforward enough to modify the grammar, but I wonder if things are the way they are for a good reason.

kennknowles commented 10 years ago

I'd be perfectly happy with alternate suggestions of a different way to express the same idea. It must have decent Javascript interop.

puffnfresh commented 10 years ago

@kennknowles commas:

 type X = {a: Number, b: String}

The structural typing is unsound in master. It sadly allows you to do silly things like:

type X = {a: Number, b: String}
let x: X = valueFromJS

// wat, compiles fine:
x.nonExistant

As you probably know, I've been working on a branch to make the type-system work much better, specifically because of cases like this.

kennknowles commented 10 years ago

Commas do not repair the situation. The problem appears to be the newline/indent: Unexpected 'INDENT'. The grammar does seem to include them for data but not really for type. No?

As for unsoundness, I'm porting a Javascript library, so I'll take what I can get :-)

puffnfresh commented 10 years ago

@kennknowles yeah, doesn't look like the typegrammar likes INDENT tokens, only commas:

https://github.com/puffnfresh/roy/blob/master/src/typegrammar.js#L38

Shouldn't be too hard to fix up.

kennknowles commented 10 years ago

This code does not work yet. I naively mimicked the object literal parsing, but there appears to be a fundamental error in how I am using Jison as now only empty object types can be parsed. Or maybe late last night I just made mistakes...

I've viewed the automata and it seems to be constructed as intended, but when I hack the generated parsed to give more details, it says that expected contains } TERMINATOR typePair which makes me wonder if this is a Jison idiosyncrasy or it if thinks typePair is a terminal for some reason.

For context, I have extensive experience with bison, ply, happy, ocamlparse, etc, and have taught the class on how to build them. I'm very comfortable reading grammars and automata but do not know how to get diagnostic info from Jison about the state in which the parse failed, or how to start a parse from a different symbol in order to write more narrowly targeted tests.

Any tips?

joneshf commented 10 years ago

You may be right that this is a jison thing. We are using an extremely old version of it. I'm not sure what changed between 0.2.7 (which we currently require) and 0.4.13 (latest), or if it fixed anything, but feel free to update the version. Might be as simple as that.

kennknowles commented 10 years ago

I just gave it a shot, but got the same errors. (But no others, so you certainly might as well upgrade jison.)