syntax proposal: disallow whitespace in unit

[avh4]

The following are all valid, and I propose they should be disallowed as they only lead to confusion:

u1 = (   )
u2 = (  {-comments-}  -- more comments
   --
   )

Instead, () should be the only valid way to represent unit.

[jvoigtlaender]

Yes!

[mgold]

Yup, no reason not to.

[vito]

Aren't they just 0-tuples? Having special syntax for this case makes that interpretation slightly awkward given that I'd expect ( 1, 2 ) to be the same as (1, 2) (or really any other whitespace/comments around tokens). It's a little smelly, but that's where elm-format would come in. :)

Same goes for [{- foo -}] for empty lists. It looks a little funny but it's pretty clear what it'll do. Sure I'd never ship code like that, but when I'm debugging things I could see myself commenting stuff out willy-nilly and not wanting to have to hoist the contents of a list/tuple somewhere else before commenting it out.

Encountering shipped code in that form would definitely be confusing, but imo predictability and consistency within the grammar is more important. Maybe the crux of the issue lies elsewhere? You could cause a lot of confusion with {- these comments -} alone. I'll bet Go's lack of block comments makes go fmt a lot easier to implement. edit: huh, Go does support multiline comments, nevermind. I just never see them used.

[avh4]

w/r to consistency in the grammar, parens are different from square brackets because [1] is a list of one item, but (1) is not a tuple of one item.

In any case, I think this is an example of a rarely (if ever) used syntax. Imo we do want to prioritize removing confusing syntax, especially in cases where the grammar doesn't match how the syntax of the language is described in the docs.

[vito]

There are infinitely many rarely used syntaxes, just by having block comments and insignificant whitespace. :)

[1] and (1) are semantically different, but I'd expect them to parse with the same basic rules (whitespace and comments being insignificant) before those semantics are applied. It so happens that Elm is using parsec which blurs the line between parsing phases and doesn't define a grammar in one place, but these are still basic assumptions people make about how a language's syntax works. It helps a new user understand new concepts by building on ones they already know, rather than internalize that () is a fundamentally different beast than [] and {}.

My main concern is that by trying to prevent confusing edge cases at all levels of Elm (rather than just relying on a formatter to say "don't do that") we may end up with a more complicated set of primitives than we started with. I'd much rather have a small, consistent grammar as a basic assumption, even if it means you can do weird things with it. Haskell for example permits ( {- whee -} ) and it's never been an issue.

Also keep in mind that elm-compiler's parser won't be the only one people have to maintain. Editor plugins, syntax highlighters, or alternative implementations will have to enforce these same rules. A complicated grammar quickly makes many other problems harder. Having "sometimes significant" whitespace is one way to make things complicated.

Ruby's parser serves as a cautionary tale of putting too much complexity in the parsing phase. It's a hand-rolled bag of C filled with edge cases, making it impossible for any other correct implementations to exist, which was a major pain for other projects. Other Ruby implementations like Rubinius resorted to vendoring it wholesale (a battle they're still fighting), and anyone writing a syntax highlighter or editor plugin had a hard time.

I've probably typed a bit too much and don't want to monopolize the discussion, but there's my 2c.

[jvoigtlaender]

@vito, your argument hinges on the interpretation of () as the type of 0-tuples, and of () as the 0-tuple value. But what if I tell you that there is no type of 0-tuples in Elm? Just as there is no type of 1-tuples in Elm? That k-tuples in Elm only start at k=2?

Then () is just a new type that contains exactly one value (). The type and value could be named Unit, but they happen to be called (). Where () is a fixed symbol, just as ++ is a fixed symbol and you cannot use +{- something -}+ for list append.

There is no argument of continuity to be made here. For lists, yes. You can say that you want empty, singleton and longer lists, and you expect them to follow the same rules, so if [1,2 {- xyz -}] is allowed it would be strange to not also allow [{- xyz -}]. But for () you cannot make the same argument "by continuity". You cannot say that there are 0-, 1- and k-tuples and you want them all to follow the same rules and hence ( {- xyz -} ) must be allowed. This supposed continuity is already broken since the 1-case does not exist. So we might as well say (and I have done so above) that the 0-case does also not exist. Tuples start at 2-tuples. And () is not the type of 0-tuples. So there is nothing to be said about its syntactic rules as a consequence of what syntactic rules apply to pairs etc.

Your other arguments, about parser compatibility etc., are on a very general level. And on that level hardly debatable. But whether the concrete case, saying that () is a fixed symbol like ++, is even potentially problematic, is not demonstrated and not clear at all.

[vito]

@jvoigtlaender Today they're concretely 0-tuples. They're parsed in the same code branch, and constructed as Tuple0 when writing native packages. Those could be changed, but even coming from other languages that's very often how () is explained, so having Elm be the odd one out just to change this parsing case doesn't greatly help understanding.

The absence of a 1-tuple case is not very significant given that all behavior attributed to tuples comes from producing/destructuring them syntactically. They're a self-reflecting type; with a single value it's a single type. You could "pretend" you have 1-tuples by wrapping everything in parens and get the exact same behavior. :)

Even if () were interpreted as its own token, it appears as the same syntactic construct as (1) and (1, 2), with some relationship to [], but it would behave differently. It doesn't actually fix anything. If you're going to make it its own thing, you might as well call it Unit, otherwise you're reusing syntax from a totally unrelated concept.

[jvoigtlaender]

@vito, concerning your first paragraph: I know all this (about how it is concretely now in terms of implementation). I was proposing a change of perspective on () with my saying "But what if I tell you that there is no type of 0-tuples in Elm?"

About your second paragraph: Yeah, probably one could pretend that there are 1-tuples. I would have to think more to see whether it really works seamlessly. Note that in Haskell (which you referenced before) you couldn't do this. Because due to boxing there would be a semantic difference between the type Int and the type (Int), the latter containing more values than the former, just as the type (Int,Int) contains more values than just the Cartesian product of the types Int and Int. That alone (that the situation in Haskell is not like what you describe) makes me weigh this argument (countering my statement about the absence of a 1-tuple case) somewhat low.

About your third paragraph, have you considered the situation with ++? The + in there is also existing independently. One might well have decided to say that any succession of two +, possibly separated by whitespace, makes a ++. That wasn't done. I don't find it more weird to decide that () is one token than to say that ++ is one token despite the fact that + is also one token. So I don't buy the "the same syntactic construct" (or "reusing syntax from a totally unrelated concept") argument either.

[vito]

@jvoigtlaender Grouping constructs like [], (), and {} carry a bit more weight than arbitrary operator characters in just about every language, so I don't find the ++ vs. + comparison very compelling. There's no such thing as a +) operator, though curiously (+) already has meaning - again because () is a different class of syntax. On that note - should we disallow ( + {- whee -} ) too? (You can see how this becomes a rabbit hole.)

Haskell's boxing behavior isn't particularly relevant to me as that's more of an optimization characteristic than an actual language-semantics-defining behavior.

Again, if you're going to redefine tuples to not include the 0-length case, you might as well just have a separate type and distinguish between them syntactically.

[jvoigtlaender]

Yes, a separate type would be clearer. And it's true that ( and ) are more special than +.

On the other hand, I admit that I would want to disallow ( + {- whee -} ). Turning an operator into a function should be (operator), nothing else. Because it is also the case that turning a function into an operator can only be done as x f y, not as x f y or other whitespacey stuff.

Aside: Concerning the Haskell comparison, I shouldn't have said "boxing" and I shouldn't have used Int as example. Maybe that made it sound as "just optimization-relevant" and "not semantics-defining behavior", as if what I was pointing out was specific to the treatment of primitive types. That's not the case. The type (Tree,Tree) is also semantically different from the Cartesian product of Tree with itself, for a nice algebraic data type Tree defined inside the language. It's not boxing as in Java or so.

[jvoigtlaender]

I've added a separate proposal to remove syntax like ( + {- whee -} ): #1213

Also, @vito, I actually consider the turn-an-operator-into-a-function syntax as a case of the following now: "Even independently of (), Elm does already use ( and ) for other purposes than as grouping constructs."

In fact, I don't see how the use of brackets to turn + into (+) has anything to do with "grouping". It is just some other use of brackets. So using brackets to form () without interpreting that as grouping/0-tupling would not set a new precedent of "now suddenly brackets are not used as grouping construct".

[vito]

Devil's advocate: (+) is also present in Haskell, which additionally allowed the forms (1 +) and (+ 1) for partially applying the left-hand-side and right-hand-side respectively. Arguably the parens are just used as a delimiter for a partially applied infix function, even in the (+) case. Even more arguably (heh) they're just serving as a delimiter for explicitly no value in the () case. :) And typically whitespace around delimiters doesn't matter.

The long and short of it is that these proposals seem to go against the syntax rules I've internalized from other languages for imo marginal benefit, compared to what would be a nice uncontroversial feature in a formatter.

[jvoigtlaender]

I had already commented on that Haskell situation you mention, over in #1213.

[vito]

Should've clicked through first, thanks. (Doesn't really affect what I said though.)

Has Elm expressly chosen not to support (1 +) syntax, or has it just not come up? Some things like where bindings have been turned down but I haven't come across discussions on partial infix application.