Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy Forth (2015)

skilldrick.github.io

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Easy Forth (2015)

#71

Post by tromp »

adastra22 wrote: post #56
s-macke wrote: post #7

Earlier quoted context omitted.

Right. And once again, you’ll also notice that no one is actually coding anything useful in Forth.

Bitcoin’s scripting / smart contracting language is Forth. Were there anything in the crypto space is actually solving a problem is up to your own biases and prejudices. But if you pick one thing as actually trying to solve a real problem, payments over lightning is probably that. Lightning, at its core, is a state machine composed of Forth spend scripts.

While bitcoin script is a stack language, it doesn't really qualify as Forth as it doesn't allow you to define any new words.

Re: Easy Forth (2015)

#72

Post by glimshe »

susam wrote: post #5

Glad to see Forth on HN today! For anyone who likes playing with small experimental projects, I once made a minimal, esoteric canvas colouring language inspired by Forth and Tixy: https://susam.net/fxyt.html

Very cool! It would be even better if you had a Library of preset demo programs for people to hack and see the power of your tool

Edit: I saw them on GitHub. But I've also seen some tools that put them in the main interface. That would be an improvement IMHO. Great work!

Re: Easy Forth (2015)

#73

Post by kragen »

zelphirkalt wrote: post #69
kragen wrote: post #28

Earlier quoted context omitted.

I think mostly learning Forth is like learning any other programming language (or, better said, programming environment): you learn by doing it. Books can be a useful complement to practice, but practice is how you learn to do things. You can't learn to do things by reading. As for string handling, in my limited experience, string handling in Forth is a lot like string handling in C; you have to allocate buffers and…

I think there is another problem for me: The last time I have done any manual memory management a la C, before using Forth was some >10y ago. And immediately the next question would pop up in my head: "What if that line is longer than 128 bytes? Is there no general function to read a whole line?" And I guess then I would reinvent the whole machinery to read a whole line, determining at which byte the newline appears.…

Well, to bake an apple pie from scratch, you must first create the universe.

In any programming language, to read an arbitrarily long line into memory, you need an arbitrarily large computer, so your software may need to pause to convert more Temu orders, continents, asteroids, or star systems into computronium. If you're not willing to go that far, you have basically two choices:

1. Process the line in a streaming fashion rather than holding all of it in memory at once.

2. Only handle lines up to some maximum length.

If you select option 2, the only remaining questions are:

2a. What is that maximum length?

2b. What happens if you hit it?

Maybe 128 bytes is not a limit you're happy with, but it's just as easy to use 1048576 or 1234567890. Your code may be easier to understand and easier to get right if you use a dynamically-allocated string type (I suggest studying stralloc from qmail 1.03), but don't fool yourself into thinking that that means there's no limit on input line length. Dismayingly often, the answer to 2b in that case is "Linux starts thrashing and becomes unusably slow until you reboot it."

(If your input is UTF-8, the line-reading function doesn't have to worry about whether the bytes represent Unicode characters or not, because byte 0x0a will never occur inside a non-ASCII character.)

Re: Easy Forth (2015)

#74

Post by s-macke »

kamaal wrote: post #31
bxparks wrote: post #19

Earlier quoted context omitted.

As I like to say: "C is a language that solves a million problems. Forth is a million languages that solve almost nothing." :-P I've been reading about Forth for 30-40 years. The dual stack is easy to understand. My problem is that I cannot see how control flow works in Forth, e.g. a simple if-then-else. I think that something as fundamental as an if-then-else should be obvious in a useful language. Heck, it's obviou…

>>Forth is a million languages that solve almost nothing." :-P That brings us to the question, when it was invented and people did use it. What kind of problems were they solving with it?

The Starflight role-playing game for DOS [0] was written in its own Forth dialect. Even today, it remains one of the games with the strongest Star Trek feeling.

[0] https://en.wikipedia.org/wiki/Starflight

Re: Easy Forth (2015)

#75

Post by pjmlp »

kragen wrote: post #39
pjmlp wrote: post #36

Earlier quoted context omitted.

Unfortunately we aren't in the 1980's glory days of Forth in 8 bit home computers, and many students don't know what HP-48GX stands for.

RPL isn't Forth.

Technically you are right, in practice they are close enough in concepts, exploring stack based languages.

Re: Easy Forth (2015)

#76

Post by susam »

glimshe wrote: post #72
susam wrote: post #5

Glad to see Forth on HN today! For anyone who likes playing with small experimental projects, I once made a minimal, esoteric canvas colouring language inspired by Forth and Tixy: https://susam.net/fxyt.html

Very cool! It would be even better if you had a Library of preset demo programs for people to hack and see the power of your tool Edit: I saw them on GitHub. But I've also seen some tools that put them in the main interface. That would be an improvement IMHO. Great work!

Thank you! Glad you liked it! There are a few demos at the bottom of the help screen, which can be invoked by typing '?'.

You are right that that they could be better linked directly from the main interface.

In any case, here are the direct links to the demos available in the help screen:

https://susam.net/fxyt.html#XYxTN1srN255pTN1sqD

https://susam.net/fxyt.html#XYaTN1srN255pTN1sqN0

https://susam.net/fxyt.html#XYoTN1srN255pTN1sqDN0S

https://susam.net/fxyt.html#XYpTN1srN255pTN1sqD

https://susam.net/fxyt.html#XYN256sTdrD

Community demos are available here:

https://susam.github.io/fxyt/demo.html

Re: Easy Forth (2015)

#77

Post by alexisread »

kragen wrote: post #52
bxparks wrote: post #41

Earlier quoted context omitted.

Thanks for that. I kinda know how it "works" at the user-level. I meant to say, I don't know how it is implemented . My mental model of Forth is that there is a simple parser that consumes space-delimited keywords. The interpreter looks up that keyword in a dictionary, which gives the address of the machine code that handles that word. The interpreter either makes a subroutine call to that address (subroutine threade…

You're describing the outer interpreter in interpretation state; Forth control flow words don't work properly in interpretation state, only in compile state. They're immediate words, so they execute at compile time instead of run time, so they can do arbitrary things to the code being compiled. Here's Mike Perry and Henry Laxen's implementation of the main control-flow words from F83, which is an indirect-threaded Fo…

Oof, I forget that most forths are a bit mind bending with the compiler STATE. There are 2/3 alternatives to using compiler state aka IMMEDIATE.

https://github.com/dan4thewin/FreeForth2 This uses a two-pass search, for macros` and after that immediate words.

The most interesting one is Able forth https://github.com/ablevm which uses flow control to defer execution, aka quotations. I find using quotations instead of immediate modes easier to understand.

With both of these, they always compile expressions before executing them, so IF/THEN/ELSE can be used at any time.

Re: Easy Forth (2015)

#78

Post by pjmlp »

PaulHoule wrote: post #38
pjmlp wrote: post #36

Earlier quoted context omitted.

Unfortunately we aren't in the 1980's glory days of Forth in 8 bit home computers, and many students don't know what HP-48GX stands for.

BASIC, especially the Microsoft dialect, became the dominant language for microcomputers because it would fit in a tiny space, e.g. 4k. For that matter it was big in the minicomputer age because it was used in multitasking systems that weren't that big. Circa 1980 my high school had a PDP-8 which had three terminals and could run a three user BASIC with just 32k 12 bit words. There weren't a lot of languages which wo…

Original BASIC did not fit into tiny space, that is why while Dartmouth BASIC always compiled into machine code before execution, everyone that learnt BASIC in 8 bit systems thinks it was originally interpreted and compilers only came later, which was the compromise to make it fit into a few KB.

Jupiter ACE had its followers, and it was common to see ads on Your Sinclair and similar magazines for ROM replacements using Forth instead of BASIC.

Re: Easy Forth (2015)

#79

Post by kragen »

pjmlp wrote: post #75
kragen wrote: post #39

Earlier quoted context omitted.

RPL isn't Forth.

Technically you are right, in practice they are close enough in concepts, exploring stack based languages.

I don't agree at all. They do have something in common: they're stack-based. But what they don't have in common is everything else. RPL is a dynamically-typed, bounds-checked, memory-safe, garbage-collected language similar to PostScript or Python. Forth is an untyped, unsafe language with arbitrary compile-time compilation and without even a heap, traditionally. It's the minimal veneer on top of assembly language to give it arbitrary compile-time metaprogramming and nested expressions and control structures. RPL doesn't even have compile-time metaprogramming at all.

These two languages represent diametrically opposed approaches to programming language design.

Re: Easy Forth (2015)

#80

Post by zelphirkalt »

kragen wrote: post #73
zelphirkalt wrote: post #69

Earlier quoted context omitted.

I think there is another problem for me: The last time I have done any manual memory management a la C, before using Forth was some >10y ago. And immediately the next question would pop up in my head: "What if that line is longer than 128 bytes? Is there no general function to read a whole line?" And I guess then I would reinvent the whole machinery to read a whole line, determining at which byte the newline appears.…

Well, to bake an apple pie from scratch, you must first create the universe. In any programming language, to read an arbitrarily long line into memory, you need an arbitrarily large computer, so your software may need to pause to convert more Temu orders, continents, asteroids, or star systems into computronium. If you're not willing to go that far, you have basically two choices: 1. Process the line in a streaming f…

The point is, I don't want to spend lots of time solving these essential problems, when I actually want to learn the language through solving puzzles. It seems, that Forth does not lend itself to be learned that way, since even very basic things are not provided and require in-depth knowledge of Forth and developing manual memory managed solutions to problems, that are solved in almost every programming language in their standard libraries. If I used Python it would literally be 2 lines of code, and with file.readlines() or so, I don't have to think about how long a line can be and then develop ad-hoc brittle half-solutions.

Perhaps readlines() has a limit somewhere too though. Just not aware of it and so far have not needed to deal with that kind of thing. But then again Forth and Python are 2 very different languages and act on another level of abstraction in many cases, so maybe that comparison is not fair.

Post reply on HN