Design patterns for composability with traits (i.e. typeclasses)?

[shelby3]

@keean

I am not bothered by ':' in type definitions. I tend to favour using lower-case for types and upper case for type variables like in a Prolog program

If you use lowercase for types, then you can't distinguish then from instance (aka variable) names except by context. In C++/Java/Scala, type parameters (aka variables) are usually all uppercase and type names are Camel case with first letter uppercase. Variable (and function/method) names are usually lower case or first letter lower case with Camel case for function names.

C was a very good language because it had a minimum of syntax. Symbol soup looks noisy. The dot operator can be thought of narrowing/accessing the type, so it makes sense we should use the dot operator for both type member access (since those members are part of the structural type even if we aren't employing structural typing else where in the language) and Type scoping is narrowing/accessing the nominal type.

@keean

The bad thing is that it splits the user base of existing languages.

Not necessarily. Did Python split any existing user base? Ruby's? Rather I think Python identified a niche for readable consistency.

If someone identifies a niche and hits that niche on the target, they can succeed.

So the key is identifying Rust's niche and focus on it.

Haskell's niche is apparently people who want to code like math. It isn't just that it is a functional language, but the lazy evaluation which enables expressing infinite series and other math.

@keean

I also thing imperative code is easier to read and more understandable than the functional style. This is due to the objects having stable types, and visible indexing. The functional style of chaining maps and folds results in invisible intermediate types that make reading someone else's code much harder. I call it "write only code"

I agree about "write only" code and as I wrote in another post today, this is likely because of Haskell's global type inference (which btw prevents a first-class union and thus Haskell can never implement my proposal in this thread).

Btw, afaics functional programming can be readable by annotating the code with the types. Afaics, readability can be higher in a functional style, if done well.

@shelby3

Rust and Haskell both have typeclasses and afaics they both need HKTs. Arguably what makes Haskell so obtuse are:

1. Uses spaces instead of commas and parenthetic grouping for function application.
2. Has global type inference so the function, data type, and typeclass (aka trait) signatures are rarely displayed explicity.
3. Is 100% immutable, thus requires category theory monads to emulate mutability.
4. Has lazy evaluation and memoization which complicates memory space and timing design and analysis.
5. Abstract data types (ADTs) are more powerful (in some ways and less in others) and less verbose boilerplate to accomplish the same employing struct, trait, mod, and enum. This conciseness and lack of verbiage, along with being an unfamiliar declaration to C/C++/Java programmers, makes it obtuse to some.
6. Etc.

My point is that Rust has many of the same roughly equivalent abstractions that Haskell has, and will probably need HKTs as well. But it doesn't necessarily have to be as obtuse to C/C++/Java programmers as Haskell is.

P.S. It is Sunday and I have an obligation to be at a beach party, so further replies will be delayed.