Last few syntax changes

[cpurdy]

We're pretty close to the end of the list of planned (and semi-planned) changes to the details of the language syntax. A few little changes went in this week:

• The "tick bar" multi-line syntax introduction was changed to the "escape bar", as you can see here.

• We finished removing the old ellipsis support from the lexer/parser. This used to be used for the varargs feature, but we dropped support for that some time ago.

There are two switch related topics that we have been considering, that I would like some feedback on:

• We have discussed dropping the switch () (the "switch ladder") construct. The main issue is that we haven't used it much, and that does point towards the construct being somewhat unnecessary. It's easier to chop things now than later, but there's no rush on this decision.

• (DONE) We know that we need a specialization of the switch statement for types, specifically to test for "isA" instead of "equals". I've mocked up quite a few ways to do this, but most of them I've eliminated for reasons of obvious ugliness. Some languages have taken the match keyword for this purpose, which seems reasonable. Another possibility is to use the existing is keyword with the switch keyword to indicate the different use case:

    switch is (o) // final syntax is "switch (o.is(_))"
        {
        case List:
            ...
        case Collection:
            ...
        default:
            ...
        }

• (DONE) We have had a few cases in which we explicitly wanted the C-style "assignment expression", which Ecstasy purposefully does not support. In C, a = b = c assigns the value of c to b and to a, and then further yields that value as the expression's value; Ecstasy disallows this because it is an error prone construct, and also because it conflicts with several other capabilities, such as named arguments. However, in the case that a value assignment + value yield is desired, we are considering introducing a new operator to indicate this purpose explicitly. Unfortunately, no obvious operator has volunteered for this purpose; obvious means "contains an = operator character somewhere in the operator, and doesn't confuse people". The := operator, for example, is already used as the conditional assignment operator. One operator that we are considering is the <- operator (i.e. the backwards lambda), which reads fairly well and seems fairly explicit. Unfortunately, it does not contain the = operator character that would clearly identify the purpose of the operator. Again, there is no rush, but feedback is welcome. Consider the typical use cases, such as foo(a, b <- c, d);

There are some other possible changes in my notes, so I'll need to go back through them to see what else is still under consideration. Type algebra is one such item that I can recall, which is particularly useful for things like forming a bespoke type for the delegates keyword. We also have a few type system thoughts that we haven't quite nailed down yet, that could eventually impact syntax at the edges, but most of these we've deferred for a "2.0" (i.e. 6-10 years away, since we're still years away from an actual 1.0). The one thing that I'd be willing to make some sacrifices to get in to a 1.0 (because it would require breaking changes) is a limited form of dependent type support, focused primarily on integer types, but this is worthy of a separate conversation.

Ideas and feedback are welcome.

Also, if you have any particular challenges from using the current syntax, raise them now before you get used to it and you forget what bothers you!

[cpurdy]

I've combed back through a pile of notes, and extracted out the various TODOs regarding syntax.

• (moved to new thread) Overriding resource injection for imported modules (i.e. within the same type system). This is an already-decided project, but it just hasn't been on the critical path. Currently, all of the injections into a type system come from outside of the container, but when a module depends on (imports) another module, it may also desire to provide some of the injections into the depended-upon module itself. This would somehow have to be specified as part of the package <name> import <module> statement.

• Similar to the above, we had a requirement to be able to specify optional attributes for module loading (test / debug / version / etc.) This is a change to the Container API, and not a syntax change, but I wanted to make sure that we captured the requirement somewhere.

• (DONE) "if not" or "if else" (sometimes called "unless") - the basic idea is to be able to skip the "then" portion of an if statement. In many languages, including Ecstasy, a boolean expression can be negated using a prefix ! operator, but in Ecstasy, there are constructs that are not boolean expressions, per se. For example, "if (val x := foo())" evaluates to a boolean, but it is a statement, and is also comma-combinable, e.g. "if (val x := foo(), val y := bar())" . What if the developer wishes to negate one of the two, but not the other? Here's an example from List.x:

    static <Element> List<Element> sort(List<Element> list, Element.Orderer? order = Null)
        {
        if (order == null)
            {
            if (order := Element.ordered()) {}
            else
                {
                throw new TypeMismatch($"Element type {Element} is not Orderable");
                }
            }

        if (list.is(immutable List) || !list.inPlace)
            {
            list = list.toArray(Mutable);
            }

        bubbleSort(list, order);
        return list;
        }

• (DONE) Current, we can suffix a type with :public, :private, :protected, or :struct to make a new type. Compare this to the "immutable T" form, and it seems self-evident that "public T" has some readability benefits compared to "T:public". Discuss.

• Originally, we had a type called This, which represented the auto-narrowing type. We have had some discussion of re-introducing it.

• (moved to new thread) Forming types:

  • Currently, we support intersection types via the | operator, as in "Nullable | String". (Some languages call these types "tagged unions".) We are considering an explicit compile-time & operator to differentiate between the "it's either type A or type B" meaning (|) of the intersection, vs. "we're talking about the members that overlap on both type A and type B" meaning (&).
  • We still need a syntax for compile-time adding and removing methods and other members from a type. This is primarily for specifying a one-off type in a delegates or an implements clause, for example. The idea is that the syntax would be a simple as possible without being ambiguous.

• (DONE) There was a recommendation at one point to include a construct such as: if (T t : x.is(T)). I don't think this gained much traction because type inference already does this automatically (x is known to be a T).

• Statements as expressions (much like there exists a switch and a statement block expression); likely would include all of these:

  • if - there's already ternary, so it's not clear if this is needed, although if supports more complex conditions
  • while, do..while, and for - would complement the if capabilities for looping
  • using and try - these seem like ideal candidates

[cpurdy]

• Regarding "Statements as expressions", we can prototype the statement expressions just by wrapping them with a StatementExpression AST node. In theory, that's all we'll need to do, since there is no syntax difference between if/while/for/using/etc. as a statement, vs. the same keyword being used as an expression. (In the case of the switch expression, there were minor differences between the statement and the expression form, so it did make sense to create a SwitchExpression.) This seems like a no-brainer to try.

• (DONE) Regarding the if (T t : x.is(T)), there's no reason that the imaginary .is() method (i.e. the implicit method that the operator implies) could not be signature-defined as <T> conditional T is(Type<T> t), which would allow the construct to naturally be supported by the current := operator, e.g. if (T t := x.is(T)) (and t := x.is(T);, for that matter). This seems like a no-brainer to try.

• (DONE) For the conditional operators ?= and :=, we could specifically allow the "not" operator ! to support them, in a parenthesized manner. I'm not sure how complex this is to support; it should be easy (famous last words), but since there is variable declaration potentially occurring, etc., this could get hairy. This seems like a no-brainer to try. Here's the old versus the potential new:

// old
if (order := Element.ordered()) {}
else
   {
   throw new TypeMismatch($"Element type {Element} is not Orderable");
   }
} 

// new
if (!(order := Element.ordered()))
   {
   throw new TypeMismatch($"Element type {Element} is not Orderable");
   }
} 

[cpurdy]

Two more items found in old notes:

• (Deferred) The ability to use tick marks around a name, to explicitly indicate that the name is an identifier. This is a forward-looking insurance policy, because it means that any keyword (and maybe pure gibberish) can be used as an identifier, allowing keywords to be introduced later. This also helps avoid potential language interop issues, if multiple languages compile to the same binary format, and those languages have different sets of "reserved words". In theory, it allows identifiers to contain pretty much any character, including otherwise-illegal characters (e.g. whitespace). Furthermore, it's a nice escape route for machine-gen'd code to not worry about accidentally producing something that can't be called or dereferenced by Ecstasy code. Here's one bad example of what this capability would look like:

        // please don't ever write code like this
        Int `while` = 4;
        Int `if` = `while`;

• (Deferred) The ability to specify a property using var or val instead of a specific type, iff the property has an initializer. While I don't particularly like code that uses var/val for declaration, it seems odd that we currently disallow this usage.

[cpurdy]

(DONE) One tiny change this past week that had been planned but didn't make it onto the list: The syntax for properties was modified to allow properties with method and/or class body definitions to also have an initial value.

Int x.get()
    {
    // stupid example; never do this
    return super() + 1;
    } = 1;  // <-- that is the initial assignment of property "x"

[cpurdy]

• The parsing changes has been made for negated assignment conditions; Gene will update the code gen accordingly.
• Gene is going to change IsExpression to produce two types, Boolean and T.

[cpurdy]

This one is done and in:

• We have had a few cases in which we explicitly wanted the C-style "assignment expression", which Ecstasy purposefully does not support. In C, a = b = c assigns the value of c to b and to a, and then further yields that value as the expression's value; Ecstasy disallows this because it is an error prone construct, and also because it conflicts with several other capabilities, such as named arguments. However, in the case that a value assignment + value yield is desired, we are considering introducing a new operator to indicate this purpose explicitly. Unfortunately, no obvious operator has volunteered for this purpose; obvious means "contains an = operator character somewhere in the operator, and doesn't confuse people". The := operator, for example, is already used as the conditional assignment operator. One operator that we are considering is the <- operator (i.e. the backwards lambda), which reads fairly well and seems fairly explicit. Unfortunately, it does not contain the = operator character that would clearly identify the purpose of the operator. Again, there is no rush, but feedback is welcome. Consider the typical use cases, such as foo(a, b <- c, d);

We ended up using the <- syntax. The implementation is rudimentary as a proof of concept.

[cpurdy]

These two are both done and in:

• Regarding the if (T t : x.is(T)), there's no reason that the imaginary .is() method (i.e. the implicit method that the operator implies) could not be signature-defined as <T> conditional T is(Type<T> t), which would allow the construct to naturally be supported by the current := operator, e.g. if (T t := x.is(T)) (and t := x.is(T);, for that matter). This seems like a no-brainer to try.

• For the conditional operators ?= and :=, we could specifically allow the "not" operator ! to support them, in a parenthesized manner. I'm not sure how complex this is to support; it should be easy (famous last words), but since there is variable declaration potentially occurring, etc., this could get hairy. This seems like a no-brainer to try. Here's the old versus the potential new:

// old
if (order := Element.ordered()) {}
else
   {
   throw new TypeMismatch($"Element type {Element} is not Orderable");
   }
} 

// new
if (!(order := Element.ordered()))
   {
   throw new TypeMismatch($"Element type {Element} is not Orderable");
   }
} 

[cpurdy]

This one is done and in:

• Current, we can suffix a type with :public, :private, :protected, or :struct to make a new type. Compare this to the "immutable T" form, and it seems self-evident that "public T" has some readability benefits compared to "T:public". Discuss.

Specifically, we introduced public, protected, private, and struct as prefix keywords for types.

Additionally, the following stand-alone keywords can be used as types:

• immutable - conceptually identical to immutable Object
• service - any reference (including service and virtual child thereof) that is passed across a service boundary by proxy; the reference may or may not implement the Service interface
• const - any reference originating from an actual const, enum, package, or module class (not just one that implements the Const interface)
• enum - any reference originating from an actual enum class (not just one that implements the Enum interface)
• package - any reference originating from an actual package or module class (not just one that implements the Package interface)
• module - any reference originating from an actual module class (not just one that implements the Module interface)
• class - any reference that has an actualClass, i.e. has not been masked; @Inject references, for example, do not have a class

The primary use case for these is with the .is() operator, such as:

// determine if the object can be passed to another service
if (o.is(service | immutable | Freezable)) {...}

Note that the syntax is context sensitive; it can not appear in every single place that a type expression can appear. For example:

// this will not compile
service s = foo();
// but this is ok
(service) s = foo();

(As an aside: It would be possible, in most cases, to support the syntax in a context-insensitive manner, but would require fairly heavy back-tracking to do so, so for the time being we constrained the syntax.)

[cpurdy]

Regarding:

• We still need a syntax for compile-time adding and removing methods and other members from a type. This is primarily for specifying a one-off type in a delegates or an implements clause, for example. The idea is that the syntax would be a simple as possible without being ambiguous.

We have reserved the &! (aka "and not") operator for this purpose, but the implementation of this capability is deferred.

(Update: Moved to new thread)

[cpurdy]

An alternative syntax to consider for the switch is (o) example:

switch class (o)
    {
    case List:
        ...
    case Collection:
        ...
    default:
        ...
    }

Thoughts?

[cpurdy]

The issue with the switch is and switch class syntax is that it only applied to a single condition, so in the end we ended up using a slightly different syntax, which was designed to work well in a multi-condition switch, e.g.:

switch (x.is(_), y, z.is(_))
    {
    case (String, 4, Int):
        // ...
        break;
    case (_, 10..20, Number):
        // ...
        continue;
    default:
        // ...
        break;
    }