A quick idea based on something frustrating in Java.

Imagine we have an enum and a method that calls it. In Java:

public enum TrafficLight {
  RED, YELLOW, GREEN
}

changeLights(TrafficLight.RED);

Here is the same code in Fan:

enum TrafficLight {
  red, yellow, green  }

changeLights(TrafficLight.red);

Now in Java, the method calling syntax needs to be as shown because methods can be overloaded and which is to be picked is hard to resolve. But Fan does not have methods overloads. So why can we not write this:

changeLights(red);

In other words, infer the enum class based on the method call.

Theoretically, the same could be done for == as well:

// currently
if (color == TrafficLight.green) { ...}
// possibly
if (color == green) { ...}

Now, looking at these makes me wonder if Fan's coding convention of lower case enum constants is wise? The following looks even more promising:

if (color == GREEN) {
  changeLights(RED);
}

I think the code is a lot more readable without the extra enum classname prefix. I don't think that the prefix is needed in Fan (it is in Java, hence static imports).

Any views?

I agree it is annoying - especially with an API like fwt which uses lots of enums. I'm not sure it is worth a special case though.

On the other hand the notion of infering the rhs side of equations based on the expectation of the lhs (or parameter of a method call) does have other uses. Perhaps the biggest use case is that ability to infer closure types:

list := [1, 2, 3]
list.each |val| { echo(val) }

In the case above I can easily infer the type of the function being passed to the each method. If we ever did closure type inference this was how I planned on doing it.

LINQ does something similar to infer the type of the lamba expressions (as a function or an AST).

OK, I absolutly don't like all uppercase names. They were used in C for macros (which were simple text replacements). In order to make sure they don't replace anything accidently you made the all uppercase and didn't use all upper case names for any thing else. As macros were often used as simple constants this convention somehow got stuck.

To see what a lambda expression is see the lambda calculus.

Edit: when I enter a ? (Unicode lambda) it get's correctly shown in the preview but when postet it seems to be stored as a questionmark.

OK, I absolutly don't like all uppercase names.

I'm total agreement - "screaming caps" seems very distracting to me. We actually originally used them for "constants", then switched to upper case. But the problem tends be what defining what is a constant? Is it only primitives? Is it any const static field? So we decided convention should just be normal lower-camel case for all slots - nice simple rule to follow.

when I enter a ? (Unicode lambda) it get's correctly shown in the preview but when postet it seems to be stored as a questionmark.

Andy will have to take a look - I though Unicode was round tripping correctly.

when I enter a ? (Unicode lambda) it get's correctly shown in the preview but when > postet it seems to be stored as a questionmark.

Yeah, looks like there's a bug here, that is either fixed in the latest runtime, or easily fixed in my code. When we roll out a new revision of Sidewalk, it should be fixed, not sure when that will be though.