1. 22
  1.  

  2. 3

    I had a stack-based Lispy language idea myself but looks like I got beaten to the punch. Pretty neat. Looks like it’s suitable for general-purpose scripting.

    1. 2

      One thing I feel these not-forths get wrong are anonymous words, called lists here. [ and ] can be defined to make anonymous words (quotations) in Forth, such as :[ and ];, and you keep the simplicity of parsing one token at a time. You’d just use NONAME though which is (mostly?) the same thing.

      Retro does this and a lot of similar stuff right, it’s probably my favourite language. Good quotation syntax allows for postfix (i.e. consistent) if syntax. [ do something ] if. Else? [ true ] [ false ] choose. It only lacks Worst’s quote (which are ' and ['] in Forth).

      Worst looks cool, and I wouldn’t want to discourage implementation of another concatenative, stack based language, but it doesn’t seem to do anything…. of note? The scoping rules are quite interesting to think about. I’ve never been completely sold on hyperstatic scoping

      1. 2

        I had toyed with making [ and ] regular words, and a few months ago that was easy to do in plain Worst, but I temporarily replaced the modifiable parser engine with the basic one it has at the moment in order to reduce scope. In the near future I’ll add it back in again and the internals will be able to just parse one token at a time, and the syntax won’t be as restricted as it is now.

        It’s good you mention if, because it’s actually implemented in terms of a postfix if%, which is itself implemented in terms of the call-when builtin – the only conditional construct available from the start. One could easily write a library in Worst for postfix-only syntax.

        In the long term, I intend to have it so that the concatenative + stack-based-ness is more of an implementation detail. It already makes heavy use of a definition called local, which enables local “variables” (e.g. 5 local five and then five five add local ten). I’m mildly convinced that enough utility functions like that will let you forget you’re using a not-Forth.

        1. 1

          I suppose the use of locals is simplified because of the scoping rules? Existing Forth-like locals solutions have always been lacking imo.

          1. 1

            It does help with locals, yeah. The most powerful things I’ve found the scoping rules can do so far are error handling and Ruby-like DSL blocks.

            The scoping is largely just an accident though. It’s the simplest way I could think of to implement definition lookup, and can be a real pain sometimes compared to lexical scope. I’ve experimented with faking lexical scope with a beefier version of define, but it really slowed things down at the time.

            1. 2

              …simpler than a Forthy linked list dictionary?

              1. 1

                Not in isolation, for sure. But I already had a data structure for the call stack, so I just stuck the dictionary in that and got the scoping for free. (Edit: here’s the lookup function)

        2. 1

          retro has no docs does it ? I would like to have an overview of the language

          1. 1

            lots of documentation in the download, and also WIP RETRO book

            1. 1

              Link to retro book looks 404. Documentation online would be a nice to have

              1. 1

                Are you sure? I edited it immediately after posting because I’d added the wrong link.

                1. 1

                  now it works