The great punctuation shift

[dougalm]

Let's admit that we never should have stolen . for indexing. Its power is wasted as an ordinary infix operator. But how are we going to return it to its rightful role?

We've had some entertaining proposals like using 's for field lookup (as in foo's bar) and more serious ones like trying to overload . for both uses. That turns out to be tricky because when . is used for field access the right-hand side is quoted/uninterpreted.

But we finally have a plan. We'll do a three-way switcheroo like a hermit crab shell swap.

1. . for field access, like foo.bar
2. _ for table indexing, like xs_i (think "subscript")
3. - for separating words in identifiers, kebab-case. Hillel Wayne approves.

One thing I like about this proposal is that the error messages if you mess it up in the obvious way will be pretty good:

• If you use _ to separate words in an identifier, writing do_stuff instead of do-stuff, you'll get an error message about do and stuff not being defined.
• If you write x-y when you meant "x minus y" but forgot the spaces, you'll get an error message about x-y not being defined. Again, pretty clear that it's an unintended lex.

To get a sense of how this would look, here's takePicture from the raytracer.

def take-picture {m} (params:Params) (scene:Scene m) (camera:Camera) : Image =
  n = camera.num-pix
  rays = camera-rays n camera
  root-key = new-key 0
  image = for i j.
    pix-key = if params.share-seed
      then root-key
      else ixkey (ixkey root-key i) j
    sample-ray-color : Key -> Color =  \k.
      [k1, k2] = split-key k
      trace params scene (rays_i_j k1) k2
    sample-averaged sample-ray-color params.num-samples pix-key
  Image.new _ _ $ image / mean (for (i,j,k). image_i_j_k)

Thoughts?

[glaebhoerl]

(N.B. I'm not involved with the project nor a user of it, just observing out of interest.)

Is there a reason against considering the "usual mainstream" syntax, table[i][j][k] or table[i,j,k]?

If function calls were to also become f(x,y), there could be an interesting bit of symmetry, with both the type- and term-level syntaxes for tables resp. functions resembling each other while remaining distinct: A=>B and a[b] vs. A->B and a(b).

[dougalm]

@glaebhoerl , that's an excellent point. If we end up using f(x, y) for function application I think it almost becomes a no-brainer to use table[i,j,k] too.

[gaurav-arya]

(Just another external observer) Extending the above analogy, it would be interesting to see to what extent future syntax for array slicing and general function partial application could be unified:)

For fixing the first args: if table[i] (for a three-dimensional table) were to fix i, that's analogous to the sort of partial application syntax #1240 seeks to disallow. But wanting to fix the first indices in particular is a much more natural assumption for (row major) arrays than for functions due to the memory ordering.

[axch]

Underscore is just so common as a name character, though! But we could do step 3 right now :)

[dougalm]

Done! #1250