Factor/Design issues

These are erg's ideas for language changes. If we ever reach a concensus on any of them, they will be moved to To do.

Should integers be sequences?

Should associative lists be first-class tuples or remain as arrays of 2arrays?

Should math operators such as + be overloaded for vectors?

Should at and nth be the same concept?

Should at return the key you attempted to look up if there is no value found?

If there is no value at a key in an assoc, then f f is returned. Since the first f is always present in this case, there is no benefit of including it; if the programmer wanted an f they could push their own.

The benefit of changing at is seen in code such as:

SYMBOL: STAR
SYMBOL: PLUS
ERROR: symbol-not-found ch ;

: lookup-symbol ( ch -- symbol )
    H{
        { CHAR: * STAR }
        { CHAR: + PLUS }
    } at* [ symbol-not-found ] unless ;

( scratchpad ) CHAR: - lookup-symbol
symbol-not-found instance
"ch" 45

Throwing an error with the symbol you attempted to look up is awkward with the current at behavior:

SYMBOL: STAR
SYMBOL: PLUS
ERROR: symbol-not-found ch ;

: lookup-symbol ( ch -- symbol )
    dup H{
        { CHAR: * STAR }
        { CHAR: + PLUS }
    } at* [ nip ] [ drop symbol-not-found ] if ;

This change would make the (substitute) word unnecessary.

Erlang-style concurrency or 1:1 native threading?

Should call work on words?

The execute word would go away and call would be generic and replace the usages of execute.

Example:

 { 1 2 3 4 5 } \ even? filter

On the other hand, callable would no longer be a subtype of sequence, which would complicate macros that do sequence operations on quotations; they'd need to special-case words to avoid surprising the user with errors.