soc

Packages are usually provided by distribution packagers, not by the developers of the code itself.

This submission reminded me that I also had some articles on this topic that people may find interesting.

That's still a workaround to try and keep a completely artificial distinction alive.

Even if I didn't need [] for types, I still wouldn't want "some functions use (), some functions use []" as a language rule.

Oh, good idea ... any preference on the first? :-)

I have some articles on naming specific areas of program code that people might find helpful:

• Naming language keywords
• Naming value creation operations
• Naming value conversion operations
• Naming operations on Options and Results
• Naming lookup operations
• Naming operations on Streams

Wasting a perfectly good pair of brackets on some random function call and then suffering for it in many other places sounds more like syntactic salt.

What's a form of access but a function from some index type to some element type?

Happily using it for presentation slides.

If you read more than just the headings, you'd find out that your objections have been addressed in the article. ;-)

Sure, there are some worse/more limited predecessors – my design was partially motivated by a desire to improve upon these.

For instance, that ML-derivative you are using for your examples

• very likely still has if then else in the language, thus making it not unified
• desperately tries to emulate functionality with guards that simply comes out of the box with my approach
• relies on the ultimate hack of "match on unit", because match is very limited in which coding patterns it can express

Also, none of the examples are "more clear" or "have less magic":
Maybe they are more "familiar" to you personally, but that's about it.

Too me they just look clunky, full of accidental complexity and trying to work around a poor/limited language design.