1. 26
  1.  

  2. 7

    The other minor frustration I have with Factor is the fact that any file that does much work tends to accrete quite a few imports in its USING: line (the calculator I wrote has 23 imports across 4 lines, even though it’s only 100 lines of code). This is mostly due to a lot of various Factor systems being split into quite a few vocabularies. I could see this being helpful with compilation

    Chatting with @yumaikas about this, we ended up working on a little Vim keyboard macro that lets us type out a module name anywhere in a file and move it into the USING: block at the top. The version I ended up with:

    " add word at cursor to final line of imports
    noremap <buffer> <Leader>i diWmz?^USING:<CR>/^;/-1<CR>$a<Space><Esc>p'z
    " add word at cursor to new line of imports (while preserving existing indentation; that's what the '%<Backspace>' is for)
    noremap <buffer> <Leader>I diWmz?^USING:<CR>/^;/-1<CR>o%<Backspace><Esc>p'z
    
    1. 2

      The built in peg parsing library in factor is super impressive. The tiny C compiler builds a stack while parsing C code and pops it to emit code, since the stack is already there implicitly with factor, I wonder how terse a super tiny C compiler could be written in factor.

      1. 1

        I haven’t played with the PEG parser in Facctor yet, hearing this intrigues me a bit, however.

        There is already an implicit stack in factor, but because it does duty as being where the parameters live, it might be a little tricky to use in the way that the Tiny C compiler uses it (I haven’t checked the tcc, so I don’t know for sure), if there’s any off-stack state (though factor does have globals and dynamic/lexical variables that could also be used).

        1. 1

          Thinking more, you are definitely right that it may be super awkward to do anything tricky, but the code embedded in a peg parser would still help make things compact.