Addressing language inconsistencies

[h3rald]

Currently there are a few language inconsistencies in min, and I was thinking of addressing them before hitting 1.0.0... some are minor other have a considerable impact on compatibility. Any thoughts on these? Anything else I missed?

quote-define, quote-bind ✅

At present:

• define auto-quotes scalar values and dictionaries but not quotations, so it's the fastest way to define symbol operators.
• bind behaves in the same way, to bind a value to an existing symbol.
• quote-define and quote-bind are auto-quoting all values, but typically are only used to store data quotations in symbols.
• Using define instead of quote-define to store a data quotation in a symbol is one of the most common source of bugs in min, as it doesn't really warn you about it (min can't know whether you are storing a quotation as data or as an operator definition).
• The sigil for define is used for capturing data quotations in signatures. This feels weird right now because it's inconsistent with what said above.
• Overall, although this makes sense, it is very confusing when you first start learning the language.

Proposal

(implemented and released in v0.31.0)

• Change define and bind to behave like quote-define and quote-bind.
• Remove quote-define and quote-bind.
• Encourage the usage of the operator symbol do define operators.
• In case you want to execute a quotation as an operator, you can still use the dequote symbol after it. This is OK for a one-off usage, otherwise you should refactor your code to use the operator symbol.

module, call ✅

At present, it is possible to convert a dictionary into a module using the module operator and then use call to access its symbols. While this originally made sense, defining modules in this way is quite verbose and you still need to use load to load the contents of a file containing the module definition.

Proposal

(implemented and released in v0.31.0)

• Remove module and call and + ^ sigils/aliases.
• Modules can only be created (automatically) by using the require operator, which automatically generates a module from the symbols defined in an external file (and performs stack pollution checks as wel).

This is somewhat similar to how JavaScript works, and I don't see any downside to it.

Typed dictionaries ✅

At present, some operators require typed dictionaries while others don't (but they require a dictionary to have specific symbols, like request). Also, it is possible to use the set-type symbol to simply set the type of a dictionary, which doesn't ensure that the dictionary satisfies any particular constraint.

Proposal

(implemented and released in v0.31.0)

• Make sure typed dictionaries are used consistently.
• If necessary, provide additional symbols to construct typed dictionaries.
• Remove set-type.
• Enrich the operator symbol to define constructor symbols that can create new typed dictionaries by specifying a way to construct them (in this case, the signature can take any number of input values but must return a dictionary). The output value returned will be annotated with a type. The idea here is also that any new type in min should essentially be a dictionary, while you can define type classes to specialize primitive types by setting additional constraints.

typeclass ✅

At present, it is possible to create new type classes by using the typeclass symbol. This is easy, but it doesn't ensure that the quotation associated to the new type class doesn't have side effects (e.g. it consumes more than one item from the stack) or correct (it pushes a Boolean value on the stack).

Proposal

(implemented and released in v0.31.0)

• remove the typeclass symbol
• enhance the operator symbol to create a new type class, checking that its signature is correct.
• Generated symbols should be prefixed with typeclass:, not type:.

seal, sealed?, delete, defined? unseal ✅

At present, these symbols operate on symbols, while seal-sigil, sealed-sigil, defined-sigil?, delete-sigil, unseal-sigil operate on sigils.

Proposal

(implemented and released in v0.31.0)

• Rename:
  • seal -> seal-symbol
  • sealed? -> sealed-symbol?
  • delete -> delete-symbol
  • defined? -> defined-symbol?
  • unseal -> unseal-symbol
• Remove ~ sigil and alias (rarely used).

[ghost]

There are so many discussions around. Are these all really?

[ghost]

A lot of discussions a lot of paragraphs, oh... I think a distillation should be.

[h3rald]

Yes I know... but I needed to write exactly what to implement/change. It is all already implemented in the next branch btw, except for the first one (but hopefully it will be ready soon)

Most of these things are breaking changes, but better do this now rather than later. The first one about the changes affecting define and quote-define is particularly nasty (nearly every one of my program will break) but I think in the end it will be for the best.