canonical form of request names

[kjx]

how should we write or print the names of request internally (when we don't e.g. know or want to write parameter names in etc)?

1. no-argument messages: foo vs foo()
2. spaces between parts: foo(_)bar(_,_) vs foo(_) bar(_,_)
3. closing training bracket: foo(_)bar(_) vs foo(_)bar
4. operators should include their argument brackets: +(_) vs +
5. prefix ops start with the word prefix, no spaces: prefix+
6. type parameters may be omitted
7. If they needed to be included (e.g. to charactise request, rather than definition), write foo<>, foo<_>, foo<_,_> for generic arguments before the first ( if any.

My preferences are the first option in each list. I could see an argument for () for zero-arg requests however.

[apblack]

The absence or presence of the parens is not optional, if it ever was. Minigrace gets this wrong, treating foo(_) and foo synonymously, so we have grown sloppy. foo() is a syntax error: if the method has one parameter, it's foo(_), and if it has no parameters, it's foo. We never had zero parameter method names; now that varargs is gone, there are no zero argument requests either, which is a great simplification.

I agree with the first 4 of your orderings, but if we accept number 4, then why is prefix + not written + (since binary + is written +(_))? I also don't understand the may be in 6 and 7, and probably don't understand type parameters. Didn't you say "canonical"? I want to use these names in method dictionaries.

[apblack]

I changed the label to 1:now because I need an answer to this to move forward with implementing alias and exclude.

[kjx]

No 4: I have a feeling this was related to #37 - if we write prefix+ elsewhere, why would we want to write something differently here?

No 6: dunno. it's probably wrong. Either a method or a request has type parameters, or it doesn't. Either way, there probably isn't much benefit to dropping the type parameters if they are there!

[apblack]

No 4: I have a feeling this was related to #37 - if we write prefix+ elsewhere, why would we want to write something differently here?

Right: we should be consistent. I'm asking: why should we write prefix+ anywhere? The prefix operator is written +; th infix operator is written +(_).

No 6: dunno. it's probably wrong. Either a method or a request has type parameters, or it doesn't. Either way, there probably isn't much benefit to dropping the type parameters if they are there!

The problem is that we allow type arguments to be omitted in requests. At the request site, we can't know, in general, whether the invoked method will have type parameters or not. This is handled on the receiving side: If the receiver has type parameters but there were no type arguments in the request, we pretend that the arguments were provided, and that they are all Unknown. But we have to get to the right method before we can do this fixing-up — which means that the presence or absence of type arguments can't itself affect method dispatch.

[kjx]

Right: we should be consistent.

good - we agree on that at least.

I'm asking: why should we write prefix+ anywhere? The prefix operator is written +; th infix operator is written +(_).

for me, because I'm still wary (to put it lightly) about overloading. Originally we didn't want any implicits or overloading for good reasons. We could do that, but it puts overloading on arity closer into the core of the language design.

The problem is that we allow type arguments to be omitted in requests

right, right, I guess this is what motivated me to write that above. Requests may omit type parameters; if they omit them, so do these descriptors, obviously

[apblack]

for me, because I'm still wary (to put it lightly) about overloading. Originally we didn't want any implicits or overloading for good reasons. We could do that, but it puts overloading on arity closer into the core of the language design.

I must be remembering thing wrongly. I thought that allowing both forms of - (zero and 1 argument) was something that you (@kjx) originally proposed and championed. Are you having second thoughts about that?

I'm not sure where minigrace's prefix- notation came from. It is an inconsistency, since we have taken pains to make other operator declarations look like their uses (unlike, say, Python, where the programmer must memorize a list of equivalences). It's one of the least defensible parts of the language.

[kjx]

I must be remembering thing wrongly. I thought that allowing both forms of - (zero and 1 argument) was something that you (@kjx) originally proposed and championed. Are you having second thoughts about that?

No. (Only about the more general overloading on arity). One reason we needed to write the prefix keyword is that before we had overloading by arity, we couldn't define both in our syntax.

It's one of the least defensible parts of the language.

I'm so tempted to rise to that, but am currently in a band practice...

(traits, class initialisation, [], []:=, [], <>, type checking, manifestness, arithmetic precedence, type vs type --- argh obviously could not resist)

[apblack]

Yes, you are right. I should have said: "it's one of the least defensible parts of the syntax".

I never understood why Michael was so opposed to putting the trailing () on the names of methods that have parameters. I do recall having him tell me that it was "obviously wrong" to name a method declared as

method size { ... }

size and to name a method declared as

method sizeOf(arg) { ... }

sizeOf(), but I never figured out why. (minigrace then, and still, names the first size and the second sizeOf. Method names with parameter lists in the middle do use the parens.) Knowing Michael, there was probably a very good reason, but I couldn't get him to say what it was.

[kjx]

1. single no-argument part: foo
2. no spaces between parts: foo(_)bar(_,_)
3. args in parens, _ separated by ,, always a closing training bracket: foo(_)bar(_)
4. operators should include their argument brackets: +(_)
5. prefix ops start with the word prefix, no spaces, no parens: prefix+
6. this point removed
7. Type parameters shouldn't be included, but if they are, list them after name of first part foo<_>, foo<_,_>, foo<_>(_)
8. Writer methods treated as a single name ending in :=: foo:=(_)

[kjx]

This is now scattered into the method name section of the spec - https://github.com/gracelang/language/blob/master/spec.md#method-names