Improve mixfix syntax

[evincarofautumn]

Current

def if___else_ (…): …
if (…) {…} else {…}
(…) {…} {…} if___else_

def account_name (…): …
user account name → x;

Alternative 1

// Reuse wildcard syntax.
def if _ _ else _ (…): …
if (…) {…} else {…}
(…) {…} {…} if _ _ else _

// Allow multi-word identifiers.
def account name (…): …
// “Is this ‘account’ followed by ‘name’ or ‘account name’?” — the reader
user account name → x;

Would work much better in a C-like language with more punctuation:

x = account name(some user, viewer context);

Alternative 2

// Use underscores to evoke wildcard syntax.
def if__else_ (…): …
if (…) {…} else {…}
(…) {…} {…} if__else_

// No way to express multi-word identifiers.

The more conservative option, and my preferred one, though multi-word identifiers are very attractive to me for some reason, perhaps because they’re more naturalistic than camelCase or underscore_case.

One downside is that identifiers imported from C-land may have underscores, but you probably don’t want to use them as mixfix.

Alternative 3

// Reuse wildcard syntax.
def if _ _ else _ (…): …
if (…) {…} else {…}
// Require explicit quoting of some kind at the call site.
(…) {…} {…} «if _ _ else _»

// Allow multi-word identifiers.
def account name (…): …
// Same quoting rule.
user «account name» → x;

We’re running out of ASCII characters, which for some reason everyone wants, and I really don’t like using backticks. Could use digraphs.

• ''account name''
• \"account name"
• account name
• …?

[strager]

Require explicit quoting of some kind at the call site.

Why not have different functions?

def ifThenElse: // ommitted
def if _ _ else _: ifThenElse
if x y else z
x y z ifThenElse

On having multiple adjacent words in an operator: I don't like the idea because Kitten's syntax is "ambiguous" (context-driven?) enough as-is.

I don't like mixfix operators in Kitten at all because it makes refactoring (a big feature of Kitten's syntax) more difficult.

[evincarofautumn]

I don't like mixfix operators in Kitten at all because it makes refactoring (a big feature of Kitten's syntax) more difficult.

Yeah, I want to have our cake and eat it too. It’s kinda like APL or Lisp—the best features of the notation are also the most unusual and therefore intrusive, so we should strike a balance between novelty and familiarity, only including the most important syntactic concessions. At present:

• Whitespace sensitivity Making sane indentation practices syntactically meaningful.
• Infix operators Just copy expressions from “C” and tweak!
• Mixfix flow control The control archetype (if, for) and all the information needed to understand the block (condition, loop bounds) are stated up front.

And then only with an obvious desugaring to the minimal core. I think that is the best strategy.

[strager]

Why not hardcode mixfix operators like if and for? You'll be able to produce better error messages and you can generalize later.