[HN Gopher] Retro: A modern, pragmatic Forth
___________________________________________________________________
 
Retro: A modern, pragmatic Forth
 
Author : Drakonis
Score  : 97 points
Date   : 2023-07-11 17:04 UTC (5 hours ago)
 
web link (www.retroforth.org)
w3m dump (www.retroforth.org)
 
| rickcarlino wrote:
| Hacker news may be giving this site the hug of death.
| https://web.archive.org/web/20230711163359/https://retrofort...
| 
| Retro is an interesting Forth platform because it has numerous
| features not present in more traditional Forth systems, such as
| the ability to create closures and first class literals while
| still maintaining compactness that would be expected of a Forth
| system.
| 
| It was originally meant for desktop scripting but has been ported
| to tiny devices like microcontrollers.
| 
| It is worth a look if you are even mildly curious about Forth
 
  | Pet_Ant wrote:
  | I would love a Forth with a type system. I don't know if that
  | is heretical, but I'd love a higher-order type system for when
  | you are several meta-words deep. Disclaimer: I've only used
  | Factor on Project Euler problems.
 
    | mananaysiempre wrote:
    | > I would love a Forth with a type system. I don't know if
    | that is heretical [...].
    | 
    | Jack Woehr (of the ANS Forth committee) and Mitch Bradley (of
    | Open Firmware fame) think it's old hat[1], so guess not.
    | (They also think it probably won't work though.)
    | 
    | In general, people have tried a lot of times; there's a
    | number of _postfix Lisps_ with type systems--Kitten mentioned
    | elsethread, ActorForth[2], etc.; a low-level _Forth_ , as in
    | identidally sized cells on stack and no automatic memory
    | management, I don't think has been done to completeness (IIRC
    | either Forth, Inc. or MPE have a standing offer for any
    | that's able to process their legacy code even just for stack
    | checking), but then C wouldn't be complete by that standard
    | either (and Rust far too limiting).
    | 
    | Honestly I'm not sure how well it would work. In C, you get a
    | great deal of utility out of compound types, and classic
    | cell-oriented Forth kind of sucks at even mildly complex
    | datastructures--they are certainly possible, but being unable
    | to manipulate them as values on the stack makes things quite
    | unnatural. (And that's where I draw the line between Forths
    | proper and "postfix Lisps" like PostScript, Joy, and Factor,
    | as such manipulation doesn't seem feasible without some sort
    | of automatic memory management.)
    | 
    | [1] https://github.com/ForthHub/discussion/issues/79#issuecom
    | men...
    | 
    | [2] https://github.com/ActorForth/ActorForth
 
    | vanderZwan wrote:
    | While not quite a Forth, Kitten _is_ a stack language:
    | 
    | https://kittenlang.org/
 
    | jwmcq wrote:
    | I've only used Forth briefly, but one of the things I loved
    | about it is that it almost has the opposite of a type system
    | - everything is just 'memory' - but you just build words
    | around that and barely even notice.
    | 
    | I've seen people recommend C as a way to "get closer to the
    | hardware", but I think we all know that that's not really
    | been a thing for longer than most of us have been alive.
    | Forth, though? Maybe!
 
      | [deleted]
 
      | vegabook wrote:
      | Forth is the only language I have dabbled with that feels
      | _lower level_ than assembler itself.
 
    | klardotsh wrote:
    | I'm slowly working on one. The repo is a mess and the
    | examples don't actually run (they're sketches of where I'm
    | trying to go; the unit tests in the Zig source are a better
    | idea of where I'm actually at so far), but I'm attempting to
    | slap a "minimum viable "does this shape align with this other
    | shape" type of type system" onto a loosely-FORTH-inspired
    | stack machine with some modern amenities with Gale.
    | https://sr.ht/~klardotsh/gale/ (or for the GitHub fans,
    | https://github.com/klardotsh/gale)
 
    | TapamN wrote:
    | Might not be quite what you're thinking of, but for typed
    | Forth, there's StrongForth, which is statically typed. I
    | wrote a Forth-based scripting system for Dreamcast homebrew,
    | and used StrongForth's type system in it. I would run and
    | edit the scripts live on the console, and the static typing
    | was a big help to prevent errors that could crash the system
    | (since the game ran under a single process, and did not use
    | the MMU).
    | 
    | https://www.stephan-becher.de/strongforth/intro.htm
 
      | poldy wrote:
      | Personally I prefer Dr. Becher's follow-on project,
      | StrongForth.f, which is just a library to load into a
      | standard system like gforth (which is probably in your OS's
      | package repo).
      | 
      | http://www.arestlessmind.org/2013/08/17/
 
    | mk12 wrote:
    | smaddox is working on one called Dawn:
    | 
    | https://news.ycombinator.com/from?site=dawn-lang.org
    | 
    | There hasn't been an update in over a year but I hope it's
    | still going because it looked really interesting.
 
    | tengwar2 wrote:
    | There are a few stack-based languages that you might enjoy.
    | Pop-11 is a typed open stack language roughly at the level of
    | Common Lisp. RPL (originally "reverse Polish Lisp") is an
    | interpretive stack based language on some HP calculators.
 
| [deleted]
 
| retrocryptid wrote:
| Cool beans. The literate coding system they're using (Unu) is a
| bit primitive, but it's _GREAT_ that they 're using one at all.
 
  | zimpenfish wrote:
  | > The literate coding system they're using
  | 
  | We need a new name for this kind of thing[1] because it's not
  | really literate programming - you can't re-order your code
  | blocks in the literate source files and have them come out in
  | the right place in the code source files which is, I think, a
  | key part of it being literate programming. Don't get me wrong -
  | I use this a lot with the various *occos - but it needs a name
  | of its own.
  | 
  | [1] Assuming we don't already have one that I've missed.
 
    | crc_ wrote:
    | I'd love to have a better name for this, and am quite willing
    | to change my description of it when I find one.
 
    | dllthomas wrote:
    | Sadly, I think the new name for this kind of thing has been
    | "literate programming" for the past 20 years at least, while
    | the literate programming that Knuth described has been
    | renamed something like "the literate programming that Knuth
    | described".
 
      | mananaysiempre wrote:
      | I think Docco was when that approach acquired some kind of
      | popularity? So 2010 or so[1].
      | 
      | Of course Haskell has had its "literate format" since
      | forever (ETA: the Haskell 1.2 report[2], dated March 1992,
      | has a description in an appendix), and it became mildly
      | popular for Haskell blogging when blogs caught on, but its
      | name was always accompanied by a side note that in Haskell
      | you don't really need to reorder things (kind of true).
      | 
      | [1] https://github.com/jashkenas/docco/commit/9b666b77c476f
      | d76b9...
      | 
      | [2] http://haskell.org/definition/haskell-report-1.2.ps.gz
 
        | dllthomas wrote:
        | I recall, on first encountering Literate Haskell at some
        | point after 2010, mentally comparing it to something I
        | thought I recalled from earlier in the perl ecosystem (on
        | top of being vaguely aware of Knuth's stuff, although I
        | hadn't actually read up on it at that point - at this
        | point I have a copy on my desk).
 
        | mananaysiempre wrote:
        | POD? I've only encountered people using it to embed
        | manpages into their single-file scripts, even if it turns
        | out that the documentation[1] doesn't consider this the
        | canonical use case and demonstrates something much more
        | like LH. But then I've never done much Perl.
        | 
        | [1] https://perldoc.perl.org/perlsyn#PODs:-Embedded-
        | Documentatio...
 
        | dllthomas wrote:
        | I don't think it would have been POD (which I agree isn't
        | the same thing) but maybe. It's been a while.
 
    | WorldMaker wrote:
    | It's in the interesting overlap space with Notebooks. I don't
    | know if that is a name you'd want to reuse for "non-
    | reorderable literate programming", especially as more
    | Notebooks move the other direction and support cell
    | reordering.
 
  | mananaysiempre wrote:
  | > The literate coding system they're using (Unu) is a bit
  | primitive, but it's GREAT that they're using one at all.
  | 
  | There's an old tradition of annotating Forth code with
  | documentation: code would go into even-numbered 64x16-character
  | "blocks", accompanying documentation into odd-numbered "shadow
  | blocks", and on e.g. a VGA you could even view them at the same
  | time.
 
| yuppiepuppie wrote:
| Seems like something is wrong with the site. I'm unable to reach
| it.
 
  | retrocryptid wrote:
  | I think it's getting more requests than the site owner
  | expected.
 
  | danjoredd wrote:
  | same
 
| dang wrote:
| Related:
| 
|  _RetroForth 2021.1_ -
| https://news.ycombinator.com/item?id=26168640 - Feb 2021 (52
| comments)
| 
|  _Retro: A Modern, Pragmatic Forth_ -
| https://news.ycombinator.com/item?id=19997008 - May 2019 (50
| comments)
| 
|  _Retro: Neat use of ports as high-level API from inside a VM
| (stack language)_ - https://news.ycombinator.com/item?id=9764962
| - June 2015 (1 comment)
 
| genpfault wrote:
| https://web.archive.org/web/20230711163359/https://retrofort...
 
| mikewarot wrote:
| http://www.retroforth.org/ seems to work just fine
 
  | zelphirkalt wrote:
  | Works no longer.
 
  | dang wrote:
  | Thanks- let's try it for now (changed from
  | https://www.retroforth.org/)
 
___________________________________________________________________
(page generated 2023-07-11 23:00 UTC)