3 ms·

It's clear you prefer the final type as suffix. That just means you need another syntax or keyword (such as "let") to introduce a variable declaration. Howeve

by xscott 4y ago

It's clear you prefer the final type as suffix. That just means you need another syntax or keyword (such as "let") to introduce a variable declaration. However function calls, array subscripts, and field accesses are the same "kind" of operation as dereferencing a pointer. Put the type last if it makes you happy, but you'll have "horrible" syntax if you don't treat pointers the same as the others: something.bar[10]() // access the field, subscript the array, call the function something.foo@ // access the field, dereference the pointer

mananaysiempre 4y ago
> It's clear you prefer the final type as suffix. That just means you need another syntax or keyword (such as "let") to introduce a variable declaration. Not really? Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Here’s an LR(1) grammar (in Grammophone[1] syntax) with postfix types and dereferencing: stmt -> init ; | expr ; . init -> decl | decl = expr . decl -> dtor type . dtor -> ambi | dfun . dfun -> ambi ( decl ) | ambi ( darg ) | dfun ^ | dfun ( ) . darg -> decl , | darg decl , . expr -> summ | summ = expr . summ -> prod | summ + prod . prod -> post | prod * post . post -> ambi | efun . efun -> ambi ( expr ) | ambi ( earg ) | efun ^ | efun ( ) . earg -> expr , | earg expr , . ambi -> name | ambi ^ | ambi ( ) . # Stub type -> int . name -> x . It lacks the comma operator or Go-style grouping of multiple variables before a single type, but adding either one is easy and both is possible, though in the latter case the “ambi” hack would need to be extended. I’m willing to believe you could even do this with LL(1) / recursive descent, but the grammar structure would probably end up rather horrible. Whether this is a smart idea as far as ergonomics of syntax errors go, I don’t know. [1] https://mdaines.github.io/grammophone/ https://mdaines.github.io/grammophone/
- xscott 4y ago
  > Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Hah, I appreciate your point and careful reply, but that's quite an assumption :-) I think using capitalization does qualify as "another syntax", which I was cautious to qualify. And (as you know) the "lexer hack" means you need to declare your types before you use them, which is a bummer for mutually recursive types. Anyways, I'll concede that you're right in that you can do it, but I don't think I was very wrong :-)
  - mananaysiempre 4y ago
    I can honestly say I wasn’t motivated by how wrong I felt you were, but by how I have been fiddling with declaration syntaxes like this over the last several months :) Which actually led me to make an error here. The starting point was C syntax so I thought assuming a lexer hack was fair game, but the grammar above doesn’t actually need it! It doesn’t need one even if you add parameterized types with the same syntax as function calls. It only needs it if you want to write function calls as juxtaposition without parens ML style, use infix syntax for type application, or (and that is what I have been fiddling with) drop the semicolons. (D'oh, I knew I was forgetting something! It was parenthesized expressions. And apparently I also screwed up optional comma termination. And curried calls.) So, for example, you can add these productions to the grammar above and it still stays LR(1): # Remove lexer hack, add parameterized types type -> name | type ( ) | type ( type ) | type ( targ ) | type ( targ type ) . targ -> type , | targ type , . # Fix the stupid dfun -> ambi ( darg decl ) | dfun ( decl ) | dfun ( darg ) | dfun ( darg decl ) . efun -> ambi ( earg expr ) | efun ( expr ) | efun ( earg ) | efun ( earg expr ) | ( expr ) . I’m not really a fan of this variant of “declaration mirrors use”, mind you. Type ascription usually requires some other syntax (both C and Go suffer from this); custom types that don’t have special punctuation are awkward and even tuples will be kind of forced. Typing the occasional colon does not seem like a bad tradeoff in comparison. I’d love to see these problems solved, though.
- xscott 4y ago
  By the way, I'm kind of surprised you didn't use 4-letter names for your stub section at the bottom. How can you suffer the inconsistency in such an otherwise consistent grammar? :-)
  - mananaysiempre 4y ago
    I console myself with the idea that they are terminals, and I can see if I forgot to define a nonterminal by checking that no examples contain four-letter words. Choosing a name for the sum nonterminal was much more painful :)
    - xscott 4y ago
      My friend and I keep a link to the following because of our similarly neurotic tendencies :-) https://github.com/timvieira/justified-variables https://github.com/timvieira/justified-variables

by xscott 4y ago

mananaysiempre 4y ago

> It's clear you prefer the final type as suffix. That just means you need another syntax or keyword (such as "let") to introduce a variable declaration. Not really? Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Here’s an LR(1) grammar (in Grammophone[1] syntax) with postfix types and dereferencing: stmt -> init ; | expr ; . init -> decl | decl = expr . decl -> dtor type . dtor -> ambi | dfun . dfun -> ambi ( decl ) | ambi ( darg ) | dfun ^ | dfun ( ) . darg -> decl , | darg decl , . expr -> summ | summ = expr . summ -> prod | summ + prod . prod -> post | prod * post . post -> ambi | efun . efun -> ambi ( expr ) | ambi ( earg ) | efun ^ | efun ( ) . earg -> expr , | earg expr , . ambi -> name | ambi ^ | ambi ( ) . # Stub type -> int . name -> x . It lacks the comma operator or Go-style grouping of multiple variables before a single type, but adding either one is easy and both is possible, though in the latter case the “ambi” hack would need to be extended. I’m willing to believe you could even do this with LL(1) / recursive descent, but the grammar structure would probably end up rather horrible. Whether this is a smart idea as far as ergonomics of syntax errors go, I don’t know. [1] https://mdaines.github.io/grammophone/ https://mdaines.github.io/grammophone/

xscott 4y ago
> Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Hah, I appreciate your point and careful reply, but that's quite an assumption :-) I think using capitalization does qualify as "another syntax", which I was cautious to qualify. And (as you know) the "lexer hack" means you need to declare your types before you use them, which is a bummer for mutually recursive types. Anyways, I'll concede that you're right in that you can do it, but I don't think I was very wrong :-)
- mananaysiempre 4y ago
  I can honestly say I wasn’t motivated by how wrong I felt you were, but by how I have been fiddling with declaration syntaxes like this over the last several months :) Which actually led me to make an error here. The starting point was C syntax so I thought assuming a lexer hack was fair game, but the grammar above doesn’t actually need it! It doesn’t need one even if you add parameterized types with the same syntax as function calls. It only needs it if you want to write function calls as juxtaposition without parens ML style, use infix syntax for type application, or (and that is what I have been fiddling with) drop the semicolons. (D'oh, I knew I was forgetting something! It was parenthesized expressions. And apparently I also screwed up optional comma termination. And curried calls.) So, for example, you can add these productions to the grammar above and it still stays LR(1): # Remove lexer hack, add parameterized types type -> name | type ( ) | type ( type ) | type ( targ ) | type ( targ type ) . targ -> type , | targ type , . # Fix the stupid dfun -> ambi ( darg decl ) | dfun ( decl ) | dfun ( darg ) | dfun ( darg decl ) . efun -> ambi ( earg expr ) | efun ( expr ) | efun ( earg ) | efun ( earg expr ) | ( expr ) . I’m not really a fan of this variant of “declaration mirrors use”, mind you. Type ascription usually requires some other syntax (both C and Go suffer from this); custom types that don’t have special punctuation are awkward and even tuples will be kind of forced. Typing the occasional colon does not seem like a bad tradeoff in comparison. I’d love to see these problems solved, though.
xscott 4y ago
By the way, I'm kind of surprised you didn't use 4-letter names for your stub section at the bottom. How can you suffer the inconsistency in such an otherwise consistent grammar? :-)
- mananaysiempre 4y ago
  I console myself with the idea that they are terminals, and I can see if I forgot to define a nonterminal by checking that no examples contain four-letter words. Choosing a name for the sum nonterminal was much more painful :)
  - xscott 4y ago
    My friend and I keep a link to the following because of our similarly neurotic tendencies :-) https://github.com/timvieira/justified-variables https://github.com/timvieira/justified-variables