Various issues

[jgh07]

Not sure if the WebCompiler is up to date, but I found several issues with very basic language constructs:

• Real literals

  Console.WriteLine(1.5); // NotImplementedException

  Also, the grammar apparently doesn't allow shorting 0.x to just .x:

  Console.WriteLine(.3); // unexpected input while parsing expression

• Accessing constants

  Console.WriteLine(Math.PI); // NotImplementedException

• Chained member access on value types

  val date = DateTime.Now;
  Console.WriteLine(date.ToString()); // works
  Console.WriteLine(date.TimeOfDay.ToString()); // NullReferenceException

• Overloaded operators The compiler does not seem to care about op_x methods at all.

  val date = DateTime.Now;
  val time = TimeSpan(2, 0, 0);
  val newDate = date + time; // no matching overload found for operator +

  
  // op_Implicit
  val a: BigInteger = 2; // type mismatch between BigInteger and Int32

val b: Int64 = 10; // type mismatch between Int64 and Int32

- **Boolean logic**

val a = 2; val b = 5;

val c = a & b; // unexpected input while parsing statement val d = a | b; // unexpected input while parsing statement val e = a ^ b; // unexpected input while parsing statement val f = a >> b; // unexpected input while parsing statement val g = a << b; // unexpected input while parsing statement val h = ~a; // unexpected input while parsing expression

- **Flags enums**

import System.Reflection;

val flags = BindingFlags.Public | BindingFlags.Static; // unexpected input while parsing statement

[LPeter1997]

Hey, thanks for taking the time to open the issue!

The playground isn't 100% up to date currently, we'll need to bump it eventually.

Real literals

This is known, as we haven't decided how/if we want literal type inference. Since most our samples simply didn't rely on floating point numbers, we have postponed it until we decide on what we want to do with it.

About the shorthand, it's because we didn't specify to allow it, as we didn't feel like saving one character was worth for a relatively more obscure literal notation: https://github.com/Draco-lang/Language-suggestions/blob/main/Specification/ExpressionsAndBuiltins.md#floating-point-literals

Accessing constants

The MSIL codegen backend probably has quite a few holes on it still, it's essentially driven by what subset of the BCL we are currently playing with. It's likely not too hard to implement, we just didn't bother.

Chained member access on value types

We didn't know about this, thanks. I'll try to look into it in a few days. Valuetypes were implemented in a hurry, so they probably require some patchwork all around.

Overloaded operators

That is actually outdated, we do look up operators in the participant operand types. The only problem is that it crashes for a similar reason as the chained member access, we'll have to patch this up. The fact that implicit casting isn't taken into account at all is more of a feature than a missing one (or bug), as we are trying to discourage implicit conversions as much as possible. We'll eventually add some way to interop with the operators ofc.

Boolean logic

Generally what you don't see in the specifications, you won't see implemented for expressions: https://github.com/Draco-lang/Language-suggestions/blob/main/Specification/ExpressionsAndBuiltins.md#operators-and-precedence

There is no proposal yet, but a soft-suggestion from my end was to add intrinsic methods for these instead of operators.

Flags enums

This has not been implemented yet, in no small part because we don't even support bitwise or-ing. We have the most bare-bones enum support for now and read very little of the important attributes in the compiler for now (like the flags enum attrib).

[LPeter1997]

Hey, just letting you know that the crash fixes for the constants and chained member access have been fixed in #430 .

The former was a simple matter of extending the CIL encoder for the remaining literal types. As for the latter, turns out we missed an important detail when decoding method signatures that come from generic contexts. Hopefully both should be fixed now with the PR.

As for operator overloading, the error is actually misleading, it simply can't resolve a ctor with integer parameters (since we didn't deal with floating point types at all yet). Here's a sample session from our REPL showcasing operator overloading working:

The rest are really "just" a matter of specifications.