Front Page All Articles Recent Changes Random Article

Contents

Concatenative language

  • ACL
  • Ait
  • Aocla
  • Breeze
  • Callisto
  • Cat
  • Cognate
  • colorForth
  • Concata
  • CoSy
  • Deque
  • DSSP
  • dt
  • Elymas
  • Enchilada
  • ETAC
  • F
  • Factor
  • Fiveth
  • Forth
  • Fourth
  • Freelang
  • Gershwin
  • hex
  • iNet
  • Joy
  • Joy of Postfix App
  • kcats
  • Kitten
  • lang5
  • Listack
  • LSE64
  • Lviv
  • Meow5
  • min
  • Mirth
  • mjoy
  • Mlatu
  • Ode
  • OForth
  • Om
  • Onyx
  • Plorth
  • Popr
  • Porth
  • PostScript
  • Prowl
  • Quest32
  • Quackery
  • r3
  • Raven
  • Retro
  • RPL
  • SPL
  • Staapl
  • Stabel
  • Tal
  • Titan
  • Trith
  • Uiua
  • Worst
  • xs
  • XY
  • 5th
  • 8th

Concatenative topics

  • Compilers
  • Interpreters
  • Type systems
  • Object systems
  • Quotations
  • Variables
  • Garbage collection
  • Example programs

Concatenative meta

  • People
  • Communities

Other languages

  • APL
  • C++
  • Erlang
  • FP trivia
  • Haskell
  • Io
  • Java
  • JavaScript
  • Lisp
  • ML
  • Oberon
  • RPL
  • Self
  • Slate
  • Smalltalk

Meta

  • Search
  • Farkup wiki format
  • Etiquette
  • Sandbox

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.

Mutating vs non-mutating words

Factor has many words that do almost the same thing but have different stack effects, such as remove-nth ( n seq -- seq' ) and delete-nth ( n -- seq ). This results in having to remember two different names for every concept. One proposed solution is to use Scheme's naming convention for mutation, which is a ! at the end of the word. Then we'd have delete-nth for creating new sequences and delete-nth! for mutating existing ones. What would the stack effects be on these new versions?

One issue is that ! is already used for comments. One proposed idea is to change the comment character to #. The # symbol is a word in the make vocabulary, but this could be changed. Ideas?

An alternative approach is to move towards using Persistent data structures for hashtables and vectors and making just a single word do both mutation and non-mutation, with the stack effect being word ( ... old-obj ... -- new-obj ). Maybe you would still need two names. Anyone?

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

This revision created on Thu, 25 Sep 2008 00:39:20 by erg

Latest Revisions Edit

All content is © 2008-2024 by its respective authors. By adding content to this wiki, you agree to release it under the BSD license.