Keean Schupke

@shelby3 I think it's a mistake to conflate boxing (storing the type tag with the value) and pointers. I also think that it's a mistake to conflate l-values and r-values....

@shelby3 @sighoya Let's thinks about values like "3" or "(3, 4)" or "{a: 3, b: 4}" It should be obvious that all these are values, and hence are immutable. If...

@shelby3 @sighoya So values are straightforward and we know for example that "3 == 3" or "{a:3, b:4} == {a:3, b:4}" are identities for values. So what about mutability? To...

@shelby3 @sighoya So one way we could deal with this syntactically is to use tuple notation for value records like this: ``` Values: 3 (3, 4) (a:3, b:4) ``` So...

@shelby3 @sighoya This leaves "read-only", "write-only" and "read-write" references, which are a distinct thing from mutable and immutable (value Vs object). Obviously as values are referentially transparent, there can be...

@shelby3 @sighoya Now something a bit different for consideration. Currently with the above syntax '.' gets overloaded to access both values, and objects (references). For values it always creates r-value,...

@shelby3 > We don’t only compare the addresses when comparing if two values are equal. We do compare the two separate pointers to two values if we are comparing whether...

Yes, I think that is correct. We basically split objects into three orthogonal concepts, data are effectively object properties, typeclass are inferfaces, an modules control data hiding (privite data etc)....

Extension and functors are something ML supports on modules, at the moment I don't think we should. I like the ability to have multiple modules in one file, but effectively...

> So the lesson that once we bind an interface at compile-time before the function call site, then we forsake static polymorphism and the opportunity for mono-morphisizing the function. This...