operators (parsing and choice) [] [[ ]] < > []:=

[kjx]

which operator syntax do we want?

especially for:

• generic type parameters
• indexing
• list/collection/lineup literals

[] [[ ]] < > []:=  (| |) {| |} [| |]  

how do we parse operators?

• do we require spaces around operators (note that we cannot have spaces within operators already)?
• can we have spaces between indexing or generic parameters, and whatever is to their immediate left?
• how does the delimited argument rule work with lineup literals?

  operator ambiguity

how do we deal with multiple uses of [ ] (and also < >) option 1: kill indexing operators — every "Curly-brace" style reference language has these option 2: kill literal collections — again, almost every modern language has these too option 3: pick different operators [[ ]] note that [[ would be a different operator to [ [ , just as + + is different to ++ option 4: list literals don't participate in the delineated argument rule (write ([ ]) pretty much everywhere) option 5: space sensitivity: indexing has no space; literals have space

my preferred option 5: space sensitivity generic arguments and indexing operators cannot have a space between the name art and the operator: if you have a space, you’re a “lineup” literal or an operator symbol

[kjx]

Do we still want to keep arithmetic operator precedence?

[kjx]

generics

a related question is - do we still want special syntax for generics? recalling Gilad's rant from yesterday generics are a big mistake

If types must be #manifest, can we just write

list [ a, b, c ] ofType(Number) 

instead of

list<Number> [ a, b, c ]

(works particularly well with generalised requests, and particularly badly if you want sophisticated type checking and inference (I think))

[KimBruce]

Option 1, kill indexing operators. List operations (extracting values and updating values) are just like every other method on an object. If you don't like at() or at()put() then define your own, but it always struck me as a wart that we added special operators [] and []:= that were unlike anything else in the language.

I do want precedence. Things become less understandable (more complex) if you have to put parens everywhere.

I still want some syntax for generics. I realize that is one of the toughest places to reconcile dynamic and static typing, but it is very necessary to do a good job with static typing. (One of my biggest regrets is that I haven't had a chance to work more on this.) I've hear Gilad rant about this many times, but I just don't agree with him.

[kjx]

Option 1, kill indexing operators.. as a wart that we added...

I thought you'd say that, although I still like it because I think people need to learn read expressions involving indexing as it's so common (from JS to C)

I do want precedence.

and there's (one of) your warts :-)

I still want some syntax for generics

well really we should have got properly into the type system long ago.

[kjx]

we seem to have agreed to drop the indexing operators (from the spec, anyway). I'd still like to keep them. but.

we also agreed to allow only one prefix operator at a time: so e.g. - - x is illegal, but - (- x) would be legal.

Other operator things to clean up, particularly to help with disambiguating < (generics) from < (operator)

Option 1: my preferred option

• require spaces around every operator
• do not permit spaces between the first method request part name and a '<' if that '<' is indicating the start of a generic
• generics arguments to operators would be separated from that operator by a (i.e. `3 + 4`)
• nested generics must be written with spaces '< <' (not '<<' which is a different operator)

  genericInvocation<T> 
  nonGenericInvocation < T > x   

Option 2:

• switch to another character for generics, say '['
• which is OK until we want to use '[' for something else! (literal whatnots)
• then we need pretty much the same spacing rules as Option 1

  genericInvocation[T]
  nonGenericInvocation [T]  //passes list of T

Option 3:

• switch to a composite character for generics, like '[['
• then we can use '[' for something else (literal whatnots)
• we still need pretty much the same spacing rules as Option 1

  genericInvocation[[ T ]]
  nonGenericInvocation[ [ T ] ] //e.g. passes list of list of "T"

Option 4:

• use an extra (non operator) character between names and generics
• there aren't may other such characters (e.g. '_ ` ~ ) so you're write something like this:
• is ugly and nonstandard.

  genericInvocation_[T]
  nonGenericInvocation[T]  //e.g. passes list of list of "T"

Option 4:

• switch to another character for generics, one that is NOT otherwise used
• there are almost no such ascii characters left
• crazily nonstandard to use say ` or ^

  genericInvocation`T   // use ` ' as open and close brackets
  list'T // use 'T before each type parameter, like ML
  pair$TUFF$U /// or use $ :-)

[apblack]

Are we using ~ for anything? I don't think that we put it in the list of operator chars when we revised the spec.

I rather like using tagged identifiers for type parameters, but that doesn't solve the problem of distinguishing type arguments.

Why do we need a special syntax for type parameters, rather than doing as Emerald did, and Gilad suggests, which is to use the same parameters syntax as we do for ordinary objects:

list [ a, b, c ] ofType (Number)

I think that the answer is that we want to make the type parameters optional. If we use the ordinary parameter syntax, then every method that takes a type parameter would have to come in two flavors:

list [ a, b, c ] ofType (Number)
list [ a, b, c ]

where the second is defined by calling the first with the argument Unknown. This is too much of a pain to be practical.

I advocate for using ⟦and ⟧ for type parameters, as you knew I would. We stick a button on the IDE to insert them, or let programmers use [| and |] as a surrogate. That probably means that we can't use | as a prefix operator, but that's not a big loss. The only minor drawback is the [ and | don't line-up nicely in some fonts.

[kjx]

Hi Andrew

last leg own to andrew

On 6/03/2016, at 20:35pm, Andrew Black notifications@github.com wrote:

Are we using ~ for anything? I don't think that we put it in the list of operator chars when we revised the spec.

it's (currently) an operator char.

I rather like using tagged identifiers for type parameters,

so 'a or ~a ML style...

but that doesn't solve the problem of distinguishing type arguments.

we could use the same tagging, I think. Isn't that what ML does?

I advocate for using ⟦and ⟧ for type parameters, as you knew I would.

yeah (I knew you would); no (we can't).

We stick a button on the IDE to insert them, or let programmers use [| and |] as a surrogate. That probably means that we can't use | as a prefix operator, but that's not a big loss.

again; it depends on the operator spacing rules. [| |] or [[ ]] are always the reserved operators: if you want to write [ [ or [ | then thats' what you write.

Why do we need a special syntax for type parameters, rather than doing as Emerald did, and Gilad suggests, which is to use the same parameters syntax as we do for ordinary objects:

list [ a, b, c ] ofType (Number)

yep. I've wondered about this (and did check it would still work e.g. with the new constructor syntax)

I think that the answer is that we want to make the type parameters optional. If we use the ordinary parameter syntax, then every method that takes a type parameter would have to come in two flavors:

list [ a, b, c ] ofType (Number) list [ a, b, c ]

where the second is defined by calling the first with the argument Unknown. This is too much of a pain to be practical.

well yep.

we don't have to adopt the whole of MIchael's "generalised method design"

but we could just take a short step in that direction and support optional keywords with default arguments. or throw in a little bit of magic so that type arguments default to Unknown somehow.

I'd prefer this to overloading on arity, or a bunch of other stuff that's still in there.

— Reply to this email directly or view it on GitHub.

[kjx]

If we get rid of lineups literals too, and just us non-variadic replicated methods for collection literals, #94 we can just use [] for (optional) generic type parameters, and we're done

[KimBruce]

I am happy with James's last suggestion. Let's just use [] for generics (and drop [] for lineups).

If that doesn't work, then let's use [| and |], though that's much more awkward to type! (I'd rather use [[ and ]], but those will be ambiguous is [] are used for lineups)

[kjx]

I'm also happy to do without lineups, and rely on either overloading on arity, or Smalltalk-style "and".

If that doesn't work, then let's use [| and |], though that's much more awkward to type! (I'd rather use [[ and ]], but those will be ambiguous is [] are used for lineups)

we can use [[ and ]] even if we have lineups or other uses for [; we just have to have spaces to disambiguate the way we do between = and == or < and << now. That is [[ would always mean the [[ brackets, if you wanted to nest lineups you'd write '[ ['.

[kjx]

It seems Kim & I are heading towards [] for generics and overriding by arity for collections

https://github.com/gracelang/language/issues/94#issuecomment-193586542