Bulleted arrays with . or •

[edemaine]

Fixes #803

[bbrk24]

Can you add as tuple or as const (or any other type cast, really) to a bulleted array without adding parens?

[edemaine]

Good question. No, it's not possible without parens. I think at least |> as tuple and |> as const should be addable, but even those don't work yet.

I think trailing type casts (as ...) in the same places that trailing member/call expressions (and maybe pipes from #1168) would make sense as a separate issue.

[STRd6]

Thanks for implementing this feature. I'm a little bit scared so I think that means we should do it.

[edemaine]

I definitely feel like I'm stretching the grammar a bit here. We lack a nice place to put things that work only at the indentation level, not deeper in an expression. For example, I didn't want to allow something like this:

array.map . foo
          . bar

(in particular because array.map . foo already has a meaning, involving placeholders)

As a result, it seems like I had to add (Nested)BulletedArray in a few too many places. Perhaps this could be cleaned up somehow... I'm open to ideas!

Related, I just added support for trailing members/calls and pipelines after top-level bulleted arrays, enabling |> as const. I'm not sure I added it to all the right contexts though...

I think this is a reasonable starting point though, and we can extend/fix as we run into further issues.

[danielbayley]

@edemaine Surely YAML-like - would make more sense here than ., which feels a bit too close to…

object
  .method()
  .chaining()

[edemaine]

@danielbayley How would you distinguish from subtraction?

[danielbayley]

@danielbayley How would you distinguish from subtraction?

Iv’e never personally used, or seen any multiline subtraction expressions in the wild. Which is of course, not to say this edge case doesn’t exist…

Maybe the distinction could be that if there is a newline between - entries, then it’s an array, else -s on the same line is interpreted as subtraction. Then if you did actually want multiline subtraction, you could just wrap that in parentheses? Something like:

total := (
  n
  - 1
  - 1
)

Although, maybe that isn’t even necessary, given that in order to subtract, the first token after the assignment = would be a value to subtract from anyway…

@edemaine What do you think?

[edemaine]

My worry is examples involving indented function calls, like this:

func x
  - y
  - z

// parse 1: subtraction (how Civet works now)
func(x
  - y
  - z)

// parse 2: call with array argument (how . works now)
func(x(
  [ y,
    z]))

I guess you're saying to prioritize the latter parse, but I don't see how to obtain subtraction behavior without moving the - signs onto the previous line (as requierd in CoffeeScript, but something I really don't like about CoffeeScript). Wrapping in parentheses doesn't help.

[edemaine]

One possibility that comes to mind: We could add an opt-in YAML compatibility mode via "civet yaml" (or some better name) that

• enables - and * as bullets, but also
• prevents - and * from being used as binary operators when preceded by a newline.

For some, I can imagine this is a worthwhile trade-off.