2024-03-18 00:01:00 <Al2O3       > and historically there is much moore :) of the author and his creation.
2024-03-18 00:04:06 <veltas      > lf94: You want  CREATE H0 6A C, 09 C, E6 C,   etc
2024-03-18 00:04:36 <veltas      > VARIABLE allocates a cell, CREATE leaves it empty
2024-03-18 00:05:36 <lf94        > oh nice
2024-03-18 00:06:06 <lf94        > wait, I thought variable *could* leave it empty also
2024-03-18 00:06:08 <veltas      > Tend to use CREATE for arrays, structs
2024-03-18 00:07:03 <veltas      > VARIABLE allocates one uninitialised cell
2024-03-18 00:07:58 <lf94        > isn't that ok
2024-03-18 00:08:12 <lf94        > just means I'll have 4 unused bytes per cell on this system I think?
2024-03-18 00:08:20 <veltas      > I'll use CREATE to initialise a var as well, e.g.  CREATE COLS 64 ,  instead of  VARIABLE COLS  64 COLS !
2024-03-18 00:08:39 <lf94        > https://gist.github.com/lf94/13e6955395a2db5a8f01cd656762c943
2024-03-18 00:09:09 <veltas      > Missing c, at end of lines
2024-03-18 00:09:16 <lf94        > ah whoops
2024-03-18 00:09:25 <lf94        > I'm trying to understand create vs variable
2024-03-18 00:09:52 <veltas      > VARIABLE X   ->  X is address of one cell
2024-03-18 00:10:05 <veltas      > CREATE X   ->  X is a unique address but nothing is allocated there
2024-03-18 00:10:17 <veltas      > CREATE X 5 , ->   X is address of one cell containing 5
2024-03-18 00:10:33 <veltas      > CREATE X 5 C, 10 C, -> X is address of two bytes
2024-03-18 00:11:27 <veltas      > VARIABLE X 5 C, -> X is address of 3/5/9 bytes, containing ?? ?? [?? ?? [?? ?? ?? ??]] 05
2024-03-18 00:11:35 <Al2O3       > ^^^ NICE
2024-03-18 00:12:19 <Al2O3       > nice buffered space of mostly whatever.
2024-03-18 00:12:40 <lf94        > Ah, I see the issue.
2024-03-18 00:12:46 <lf94        > thank you for drawing a picture :)
2024-03-18 00:14:18 <lf94        > I need to create a little cheatsheet
2024-03-18 00:15:00 <lf94        > n cells -> space n cells takes up; allot -> moves the here data stack pointer?
2024-03-18 00:15:48 <lf94        > So is C, doing something like : c, here 1 allot c! ; ?
2024-03-18 00:16:06 <lf94        > (my mind is a bit mixed up with all this new information in a short amount of time)
2024-03-18 00:17:13 <thrig       > get a good nights sleep then
2024-03-18 00:18:25 <veltas      > Yes lf94
2024-03-18 00:18:37 <veltas      > What gforth do you have?
2024-03-18 00:18:50 <lf94        > Gforth 0.7.3
2024-03-18 00:18:51 <veltas      > You can use SEE C, or LOCATE C, depending on which one
2024-03-18 00:19:02 <veltas      > to see the forth code it runs
2024-03-18 00:19:09 <veltas      > or assembly
2024-03-18 00:19:11 <lf94        > I like how the copyright stopped in 2008
2024-03-18 00:19:14 <lf94        > oh nice!
2024-03-18 00:19:23 <veltas      > gforth 0.7.3 is ver yold
2024-03-18 00:19:37 <lf94        > I guess the AUR version for Arch Linux is hella old
2024-03-18 00:19:41 <veltas      > They've just not done a 'release' in age
2024-03-18 00:19:46 <veltas      > ages*
2024-03-18 00:19:55 <lf94        > hm
2024-03-18 00:19:58 <lf94        > ah
2024-03-18 00:20:03 <lf94        > yeah I was going to say, says current here https://www.gnu.org/software/gforth/
2024-03-18 00:20:12 <lf94        > I think it's awesome
2024-03-18 00:20:13 <veltas      > If you've got gforth 0.7.3 installed you can build a later snapshot
2024-03-18 00:20:14 <lf94        > forth is timeless
2024-03-18 00:20:36 <veltas      > later versions have LOCATE which shows the actual source used to build the word
2024-03-18 00:21:07 <veltas      > And other features, a bit more stable for one thing
2024-03-18 00:24:29 <lf94        > How do I deallot
2024-03-18 00:24:47 <lf94        > I can just do `<data> ,` pretty much anywhere right?
2024-03-18 00:24:56 <lf94        > It'd be unnamed data stack data
2024-03-18 00:32:25 <lf94        > https://gist.github.com/lf94/7388802c6e7a5b1fd2c8f4f3660312a7 the start of my little cheatsheet
2024-03-18 00:39:22 <lf94        > something with my understanding of ! and allot
2024-03-18 00:39:25 <lf94        > is wrong
2024-03-18 00:39:36 <lf94        > does ! know the size of a cell or something?
2024-03-18 00:39:40 <lf94        > or... no
2024-03-18 00:40:00 <lf94        > ! is treating a number like 57 as a 8 byte value (64 bit int) filling the cell
2024-03-18 00:41:20 <thrig       > terrible things can happen if you use the wrong ! for the target
2024-03-18 00:57:07 <veltas      > lf94: -n allot deallocates n bytes
2024-03-18 00:57:38 <veltas      > ! is for storing a cell given its address
2024-03-18 00:57:47 <veltas      > C! is for storing a byte given its address
2024-03-18 04:05:58 <lf94        > guys
2024-03-18 04:06:12 <lf94        > Im starting to feel the "forth obsesion"
2024-03-18 04:06:43 <lf94        > like...
2024-03-18 04:06:48 <lf94        > why is the world not running on forth?
2024-03-18 04:12:41 <thrig       > parts of it are
2024-03-18 04:15:04 <iyzsong     > depends on the define of the world, running on and forth, maybe if try hard, can find one.
2024-03-18 04:17:05 <lf94        > I'm talking most of it.
2024-03-18 04:18:12 <lf94        > Like... the language is as powerful as lisp basically. And yes, I know lisp doesnt run most of the world either. But forth can run as fast as C, be as expressible as lisp, and have anything it needs added. It's crazy.
2024-03-18 04:18:22 <lf94        > Runs just as well on 8 bit cpus up to 64 bit cpus
2024-03-18 04:18:36 <lf94        > Can be understood and implemented by one person
2024-03-18 04:19:05 <lf94        > It very well may be all we've ever really needed.
2024-03-18 04:19:14 <lf94        > And if we need more? extend.
2024-03-18 04:20:54 <iyzsong     > practically forth dosen't run fast as C/C++, i think it dosen't play well with code cache and registers allocation.  sure you can do well with embeded assembly in forth, but you can do that even in BASIC.
2024-03-18 04:21:00 <lf94        > http://www.arestlessmind.org/2009/02/03/intro.html 2009. Type system in Forth.
2024-03-18 04:21:38 <lf94        > Forth doesn't run as fast as C or C++? That seems to be wrong based on what I've been reading from others
2024-03-18 04:21:54 <lf94        > Forth can be optimized to use registers 100%.
2024-03-18 04:22:30 <lf94        > "doesn't play well with code cache" from what I understand this is incorrect as well
2024-03-18 04:22:56 <lf94        > I would love to see evidence against this
2024-03-18 04:23:15 <lf94        > I want to be right about my understanding, so any evidence that guides me toward being right, I'm open to it
2024-03-18 05:09:16 <lf94        > https://codeberg.org/DW0RKiN/M4_FORTH this z80 forth doesn't seem to have C,
2024-03-18 05:09:22 <lf94        > makes me concerned
2024-03-18 05:11:59 <lf94        > https://github.com/ams-hackers/gbforth/blob/e131cc807b884b69f4512d1be6b223cfefd3a8ae/docs/memory.md?plain=1#L29
2024-03-18 05:12:05 <lf94        > Does have C,
2024-03-18 05:12:25 <lf94        > Is someone's Forth *really bad* if they don't have C, ?
2024-03-18 05:13:44 <lf94        > https://jkotlinski.github.io/durexforth/
2024-03-18 05:14:11 <lf94        > Ok good, at least zenv (z80), durexforth (c64) and gbforth (gameboy) all have C,
2024-03-18 05:27:01 <iyzsong     > lf94: suppose I want to write an emulator for a 6502 based system (eg: Nintendo NES), in forth a typical implementation for the cpu core would use 1 word for 1 instrution, like https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/emul/6502.fs .  is there a free availabled forth can do inline and register allocations optimizations like GCC for C/C++, with at least portable for x86 and ARM?  I don't think so...
2024-03-18 11:27:56 <veltas      > lf94: It's really bad or just non-standard
2024-03-18 11:29:50 <veltas      > Looks like M4_FORTH has a lot of standard words but is otherwise its own thing
2024-03-18 11:30:13 <veltas      > You've already demonstrated that writing C, is easy
2024-03-18 11:30:29 <veltas      > Don't worry about compatibility, you can write a small shim for forths that are almost-standard usually anyway
2024-03-18 11:32:10 <veltas      > > Oh no they don't have struct support!
2024-03-18 11:32:21 <veltas      > > : +FIELD  CREATE , DOES> @ + ;
2024-03-18 11:32:25 <veltas      > > Never mind
2024-03-18 11:33:39 <olle        > Hello
2024-03-18 11:36:54 <veltas      > That should be   : +FIELD  CREATE OVER , + DOES> @ + ;   but you get my point
2024-03-18 11:37:04 <veltas      > Hello olle
2024-03-18 11:38:30 <veltas      > And  : FIELD:  ALIGNED  1 CELLS +FIELD ;  : CFIELD:  1 +FIELD ;  to complete the set
2024-03-18 11:40:46 <veltas      > lf94: "Forth doesn't run as fast as C or C++?"  Yes, it doesn't run as fast as C or C++.  This oversimplifies the matter, but it's mostly true.
2024-03-18 11:41:13 <veltas      > Theoretically C, C++ and Forth are all as fast as possible because you can drop down to inline assembly
2024-03-18 11:41:29 <veltas      > Theoretically they all generate decent optimised code because all three have e.g. GCC and LLVM frontends
2024-03-18 11:41:49 <veltas      > In practice Forth designs have tradeoffs that generate slower high-level code than C or C++
2024-03-18 11:42:43 <veltas      > I would argue Forth is better equiped for optimising high-performance code as necessary than most other alternatives to C/C++
2024-03-18 11:45:18 <olle        > One should only judge idiomatic code when comparing langs I think
2024-03-18 11:46:32 <veltas      > Depends on what kind of performance comparison we're doing
2024-03-18 11:47:22 <veltas      > If you're writing high performance code, where it matters, then C, C++, and Forth all start to look similar: they will all need heavy vector intrinsics, or inline assembly, in the performance-critical sections.
2024-03-18 11:49:25 <veltas      > The best possible C code often uses vector extensions as well, in this case it's not standard C being written, it's GNU C or something.  Again, we can extend Forth to support vectors in this way too.
2024-03-18 11:50:39 <olle        > Hm
2024-03-18 11:51:42 <veltas      > Like C and C++, if you want the most performance from high-level code you need to change how you write stuff. THings like DOES> and spamming large non-constant automatic arrays on C's stack go out the window.
2024-03-18 11:52:23 <veltas      > But I wouldn't remove those features because they're all useful in the right context
2024-03-18 11:53:58 <olle        > :d
2024-03-18 12:07:50 <veltas      > lf94: "doesn't play well with code cache"  Forths written for systems where this matters often put machine code in a separate section to the main dictionary data
2024-03-18 12:08:05 <veltas      > Which resolves that specific issue without any serious drawbacks
2024-03-18 12:09:42 <veltas      > I think the biggest thing that affects is it makes DTC a bit worse, but DTC clearly has optimisation limitations anyway
2024-03-18 13:33:57 <lf94        > I don't mind if Forth is generally 2x slower than C
2024-03-18 13:34:04 <lf94        > Because you gain *a lot* in other areas
2024-03-18 13:34:10 <lf94        > and 2x slower is ... basically nothing
2024-03-18 13:35:25 <olle        > Depends
2024-03-18 13:35:34 <olle        > 2x slower can mean 100% more expensive :)
2024-03-18 13:52:52 <lf94        > That's ok. Like really, if it means going from 2hr of battery life to 1hr that's completely fine
2024-03-18 13:53:04 <lf94        > Again you gain a lot otherwie
2024-03-18 14:05:26 <olle        > Depends on your domain I'd figure
2024-03-18 14:07:39 <veltas      > Well when it does matter you can optimise, and likewise you'd have to optimise C anyway
2024-03-18 14:07:47 <veltas      > If it really matters
2024-03-18 14:07:55 <veltas      > Performance is complicated
2024-03-18 14:08:19 <olle        > Right
2024-03-18 14:08:28 <veltas      > I've had a flick through my second edition of starting forth, and this is definitely the best version. You can find them out there if you look, it's was released in the 80's
2024-03-18 14:09:33 <veltas      > I don't know if there's a scan but physical copies are not too expensive, I think the first editions are more coveted
2024-03-18 14:15:03 <veltas      > And the spine does look like K&R C so it can go next to your copy of that, if you have one
2024-03-18 14:23:37 <olle        > hehe
2024-03-18 14:40:44 <KipIngram   > :-)
2024-03-18 14:42:15 <KipIngram   > I got that Enigma emulator working correctly.  At least under light testing.
2024-03-18 14:50:23 <veltas      > lf94: Would advise this algorithm if you want performance https://github.com/openssl/openssl/blob/master/crypto/sha/sha256.c
2024-03-18 14:52:13 <KipIngram   > lf94: Neat seeing someone catch the Forth bug.
2024-03-18 15:42:36 <KipIngram   > In addition to all of the positive things you said about Forth, I'd just add the fact that it's simple enough for one person to implement from scratch on a new system in a reasonable period of time.
2024-03-18 15:42:45 <KipIngram   > That is the big draw for me.
2024-03-18 15:43:15 <KipIngram   > That and the fact that it's stack based - I learned to program on an HP-41 calculator, so "data stack" has always just felt natural and intuitive to me.
2024-03-18 15:43:35 <Al2O3       > RPN is you pal :)
2024-03-18 15:44:25 <Al2O3       > I learned stack stuff first in the late 70s on HP-41C in late 79 or early 80, and I too took that to the FORTH world.
2024-03-18 15:45:05 <KipIngram   > Initially it was my only reason for appreciating Forth, but when i eventually learned how Forth works under the hood I found many more reasons to love it.
2024-03-18 15:57:46 <thrig       > pal rpn yours is
2024-03-18 15:59:04 <KipIngram   > Yoda clearly used Forth.
2024-03-18 15:59:21 <thrig       > or it's a rare form... https://en.wikipedia.org/wiki/Object%E2%80%93subject%E2%80%93verb_word_order
2024-03-18 16:00:17 <Al2O3       > here is a bit of fun history about fig, forth inc, and all this curiosed me into finding polyForth in the garage in a box, with some other stuff.
2024-03-18 16:00:19 <Al2O3       > https://comp.lang.forth.narkive.com/tejgeZlO/fig-forth-vs-f83-vs-polyforth
2024-03-18 16:00:44 <Al2O3       > hard to believe its been 40+ years
2024-03-18 16:02:07 <Al2O3       > https://iili.io/JX7QGPR.jpg
2024-03-18 16:06:31 <veltas      > I quite like PolyForth
2024-03-18 16:08:49 <KipIngram   > The whole discussion of "pirated" Forths puzzles me.  There's no need to "pirate" Forth - it's not like it's that hard to write one.
2024-03-18 16:09:08 <KipIngram   > It's a little like stealing water.
2024-03-18 16:09:35 <Al2O3       > when you talk about Forth Inc., and business, it was pirated.
2024-03-18 16:09:58 <Al2O3       > when you talk about the standard, and doing forth from a standard, no issues at all.
2024-03-18 16:10:07 <KipIngram   > Sure - I'm not denying it as factual; just wondering why anyone took the risk of doing it that way.
2024-03-18 16:10:40 <veltas      > The concept of software being copyrightable was new in the 80's
2024-03-18 16:11:13 <Al2O3       > ^^^
2024-03-18 16:12:06 <veltas      > The law changed to make it possible in the US in ~1978 if I remember, and the case that created precedent involved Apple and was decided in ~1982, re a company copying portions of Apple II ROM
2024-03-18 16:12:09 <Al2O3       > and to read something about Chuck, one of the overwhelming reasons FORTH to me is so simple unless an effort is made otherwise, is from this phrase of his...
2024-03-18 16:12:14 <Al2O3       > "Do not speculate!" :)
2024-03-18 16:12:41 <Al2O3       > Might have been Laser
2024-03-18 16:12:52 <Al2O3       > or Franklin
2024-03-18 16:12:57 <Al2O3       > Laser 1000 and Ace
2024-03-18 16:13:06 <Al2O3       > they both were cloning the Apple II
2024-03-18 16:13:07 <KipIngram   > You mean don't speculate about future requirements?
2024-03-18 16:13:24 <Al2O3       > KipIngram, what chuck meant is this...  "The main enemy of simplicity was, in his view, the siren call of generality that led programmers to attempt to speculate on future needs and provide for them. So he added a corollary to the Basic Principle: “Do not speculate!”"
2024-03-18 16:13:32 <KipIngram   > Yes.
2024-03-18 16:13:52 <KipIngram   > I'm quite familiar with his feelings on that front.  And basically agree with them for the most part.
2024-03-18 16:14:14 <veltas      > Al2O3: Unfortunately comp.lang.forth is unreadable because of like 1-2 users that derail every thread
2024-03-18 16:14:26 <Al2O3       > sad
2024-03-18 16:14:37 <KipIngram   > Seems like there's almost always someone like that.
2024-03-18 16:14:40 <Al2O3       > but ##forth is usable I hope with my ramblings
2024-03-18 16:15:19 <Al2O3       > my years in USENET world was never imbedded with comp.lang.forth stuff, I was onto other things from the 80s to 00s, and google groups lost me quickly.
2024-03-18 16:15:41 <veltas      > For some reason comp.lang.forth attracted a handful of very bitter toxic people that like to complain about other users and generally history, and forth
2024-03-18 16:15:58 <Al2O3       > I love the history of forth, I do not like politics of it.
2024-03-18 16:16:02 <veltas      > I don't say that lightly, it's extremely bad
2024-03-18 16:16:16 <veltas      > I hate it when people complain about 'toxicity' over nothing, this is not that
2024-03-18 16:16:33 <Al2O3       > vim vs vi, vs emacs, vs ed, vs whatever
2024-03-18 16:16:37 <Al2O3       > could care less.
2024-03-18 16:16:46 <KipIngram   > there used to be a guy here that would do that, a number of years ago.
2024-03-18 16:16:48 <KipIngram   > Asau?
2024-03-18 16:17:04 <olle        > All forums need moderation
2024-03-18 16:17:07 <Al2O3       > I don't have to be right, but I am more than 50% of the time :)
2024-03-18 16:17:14 <KipIngram   > :-)
2024-03-18 16:18:02 <Al2O3       > Or to an REM song maybe ...   "I'm right 50% of the time, and I feel fine!"
2024-03-18 16:18:45 <Al2O3       > anyway, thought finding and sharing that box of goodies was a nice Monday image to share.
2024-03-18 16:18:58 <veltas      > Yeah sorry I do like that
2024-03-18 16:19:23 <veltas      > I've got an MPE PC PowerForth copy here
2024-03-18 16:20:02 <veltas      > Nice 5 1/4" disk and manual
2024-03-18 16:22:10 <Al2O3       > neat, care to share a photo if you dare :)
2024-03-18 16:22:32 <Al2O3       > I'm not sure if polyForth was ever implemented on other systems than x86.
2024-03-18 16:23:30 <veltas      > I'm pretty sure it was on some mainframes
2024-03-18 16:23:38 <veltas      > Or minicomputers anyway
2024-03-18 16:24:04 <Al2O3       > like CDC type mains, AS400, DECPDP?
2024-03-18 16:24:14 <veltas      > The polyforth manual describes systems where like 64 terminals were connected
2024-03-18 16:24:20 <veltas      > So sounds like some kind of larger computer
2024-03-18 16:24:21 <GeDaMo      > Apparently it was on an LSI-11
2024-03-18 16:24:32 <Al2O3       > yah, does.
2024-03-18 16:25:54 <Al2O3       > I need to take a weekend and go through all that stuff in that box :)   Hmmmm, gardening, beekeeping, making wine, and forth, who gets my time this weekend :)
2024-03-18 16:26:03 <GeDaMo      > And now it's on the Greenarrays chip too :|
2024-03-18 16:26:19 <Al2O3       > I saw that with a google here, kinda interesting.
2024-03-18 16:26:35 <veltas      > Al2O3: https://i.imgur.com/tGVuQlX.png
2024-03-18 16:27:25 <veltas      > Looks like they did use more than one segment, re that thread's first reply
2024-03-18 16:28:26 <veltas      > MPE powerforth seems to call the hiding operation SMUDGE
2024-03-18 16:28:29 <Al2O3       > sadly imgur and my system/s browsers don't work, even with a direct link to the jpg.
2024-03-18 16:28:44 <Al2O3       > no worries, I'm sure its cool :)
2024-03-18 16:28:49 <veltas      > Yeah imgur sucks
2024-03-18 16:28:53 <Al2O3       > yes it does.
2024-03-18 16:28:57 <Al2O3       > I use now freeimage.host
2024-03-18 16:29:05 <Al2O3       > works great, less filling, no issues, and FREE
2024-03-18 16:29:45 <veltas      > https://freeimage.host/i/JXY92Yx
2024-03-18 16:30:03 <veltas      > imgur was good originally
2024-03-18 16:30:14 <veltas      > A long time ago
2024-03-18 16:30:48 <GeDaMo      > I had to write a greasemonkey script to sort of get imgur working
2024-03-18 16:33:38 <Al2O3       > like so many things, biological or otherwise, time can or not be a friend.
2024-03-18 17:14:10 <_1player    > anyone know of a good resource on parsing in Forth? I enjoyed the BNF parser article at https://www.forth.org/literature/bnfparse.html but the code went way over my head
2024-03-18 17:14:25 <_1player    > : <BNF   SUCCESS @ IF  R> IN @ >R DP @ >R  >R ELSE  R> DROP  THEN ;
2024-03-18 17:14:35 <_1player    > that's just madness for me to understand
2024-03-18 17:14:58 <_1player    > even worse, : |    SUCCESS @ IF  R> R> R> 2DROP DROP ELSE  R> R> R> 2DUP >R >R IN ! DP !  1 SUCCESS !  >R THEN ;
2024-03-18 17:16:05 <veltas      > Forth isn't context-free
2024-03-18 17:16:15 <_1player    > I am basically looking to write a basic parser generator in Forth.. I made some decent progress but backtracking made stack management way too hard to deal with
2024-03-18 17:16:53 <_1player    > veltas, I am not trying to parse Forth. I'm looking to write a parser IN forth.
2024-03-18 17:16:53 <thrig       > save everything and rollback?
2024-03-18 17:34:20 <KipIngram   > Ok, so _lplayer, the ELSE clause up there is doing a "double return."  It's causing a return from the CALLER, to whoever called it.  The THEN clause looks like it is, among other things, causing you to return to HERE, so allegedly something has been placed there.  Some Forth compiled code.
2024-03-18 17:34:29 <KipIngram   > That was for <BNF
2024-03-18 17:35:01 <KipIngram   > I'm not sure what putting IN onto the return stack is all about; need more info on what's going on overall.
2024-03-18 17:35:07 <KipIngram   > Oh, wait.
2024-03-18 17:35:37 <KipIngram   > That THEN analysis isn't quite right - it's actually putting your return address back.  But it's putting a pointer to HERE UNDER it.
2024-03-18 17:35:46 <KipIngram   > So I still t hink there must be code at HERE.
2024-03-18 17:36:03 <KipIngram   > Unallocated code - DP needs to be moved past it, really.  Maybe it's temporary.
2024-03-18 17:36:38 <KipIngram   > So if the THEN path is taken, you will return to your caller, but the CALLER will then return to HERE.
2024-03-18 17:36:46 <KipIngram   > The else path just bails.
2024-03-18 17:38:39 <veltas      > _1player: Might look into the exception words like CATCH and THROW
2024-03-18 17:38:55 <veltas      > Seem useful for recursive descent parsing
2024-03-18 17:40:43 <veltas      > Also using BNF with Forth sounds like a misstep, Forth has parsing abilities baked in
2024-03-18 17:40:59 <KipIngram   > ^^
2024-03-18 17:41:06 <veltas      > PARSE WORD PARSE-NAME etc
2024-03-18 17:41:36 <KipIngram   > I assume _lplayer is interested in playing with parsing algorithms "formally."
2024-03-18 17:42:26 <KipIngram   > Those words you listed still ought to useful, unless the interest is at a lower level.
2024-03-18 17:42:32 <KipIngram   > ought to "be"
2024-03-18 17:42:58 <GeDaMo      > Not Forth but possibly interesting https://www.researchgate.net/publication/220828932_A_parsing_machine_for_PEGs
2024-03-18 17:43:54 <KipIngram   > This Enigma stuff is fun - now I find myself speculating on how they could have made it better, in that era.  The big weakness it had was that it never maps a letter to itself, and that should be done randomly some percentae of the time.  I'm mulling over how they might have added a "bypasser" that would randomly just skip around all of the mapping stuff and leave the letter untranslated.
2024-03-18 17:44:06 <KipIngram   > If they'd had that it's likely that it never would have been broken.
2024-03-18 17:44:43 <KipIngram   > But it would have to be accomplished with a *mechanism* of some kind.  The easy way we'd do it today was unavailable.
2024-03-18 17:56:33 <veltas      > If that's packrat, that PEG parser uses a LOT of memory for a parser, but guarantees linear parsing time wrt input size
2024-03-18 17:57:08 <GeDaMo      > It's about a virtual machine for parsing
2024-03-18 17:57:14 <veltas      > Fair enough
2024-03-18 17:57:22 <veltas      > IMO recursive descent is the easiest to understand and write, and in my highly subjective opinion is the forthiest way, apart from forth's actual parser
2024-03-18 17:57:49 <GeDaMo      > Recursive descent / PEGs are the only parsing algorithm I feel like I actually understand :P
2024-03-18 17:58:07 <veltas      > QED
2024-03-18 17:59:38 <veltas      > I did at some point memorise how the different basic kinds of parsers work, like top-down, bottom-up, how to normalise your grammars and check for LL(k), LR(1) etc
2024-03-18 18:00:05 <veltas      > But after uni I came to learn that the most important compilers don't bother with any of this, so why should I
2024-03-18 18:02:13 <veltas      > The weird thing about language theory is that even though I'm convinced 99% of it was useless, I'd still recommend it. Finite automata manipulation, grammars, parsers etc all a lot of fun.
2024-03-18 18:03:37 <GeDaMo      > This is a great paper I tend to link too often :P "PEG-based transformer provides front-, middle and back-end stages in a simple compiler" https://web.archive.org/web/20220627164843/http://www.vpri.org/pdf/tr2010003_PEG.pdf
2024-03-18 18:05:35 <veltas      > Sounds like a toilet PDF
2024-03-18 18:07:30 <lf94        > 13:06 <_1player> [16:14:25] : <BNF   SUCCESS @ IF  R> IN @ >R DP @ >R  >R ELSE  R> DROP  THEN ;
2024-03-18 18:07:32 <lf94        > 13:06 <_1player> [16:14:35] that's just madness for me to understand
2024-03-18 18:07:48 <lf94        > If that's hard for you to understand you need to learn a bit more before attempting this IMO
2024-03-18 18:08:27 <lf94        > It's just moving things in and out of the return stack
2024-03-18 18:09:32 <veltas      > Bear in mind that first R> moves the return address of the word onto the data stack
2024-03-18 18:11:11 <veltas      > And it's only put back in the first case, in second case it's popped off ... so you return to the caller's caller or whatever was there
2024-03-18 18:17:54 <veltas      > It's a popular advanced technique for structuring code, there used to be a guy in here called rdrop-exit
2024-03-18 18:32:37 <lf94        > Neat little technique
2024-03-18 18:45:09 <lf94        > I corrected my understanding of , and create
2024-03-18 18:45:25 <lf94        > In particular I was confused about , but it's very clear now
2024-03-18 18:45:36 <lf94        > I thought , took some sort of address. But it just continues to move `here`
2024-03-18 18:46:13 <lf94        > my partner is out for the night so ill get lots of hacking done on the sha256 today :)
2024-03-18 18:46:18 <lf94        > (after work)
2024-03-18 20:45:49 <zelgomer    > are you a cowboy?
2024-03-18 21:28:15 <KipIngram   > lf94: , puts the item on the top of the stack at here and advances here over it.
2024-03-18 21:28:52 <KipIngram   > <n> ALLOT will advance here by <n> bytes.
2024-03-18 21:29:07 <KipIngram   > Without initializing the newly allocated RAM in any way.
2024-03-18 21:42:23 <veltas      > This is the goal https://www.youtube.com/watch?v=KvNLr_AVTAM
2024-03-18 21:43:43 <veltas      > https://www.youtube.com/watch?v=2UNN5qB5L1A
2024-03-18 21:45:43 <GeDaMo      > https://archive.org/details/ataribooks-forth-on-the-atari-learning-by-using
2024-03-18 21:46:20 <veltas      > https://www.youtube.com/watch?v=lkoNKrBHWOo
2024-03-18 21:47:12 <veltas      > GeDaMo: But why that illustration though
2024-03-18 21:47:53 <GeDaMo      > That is an accurate representation of a Forth programmer at work :P
2024-03-18 21:48:53 <KipIngram   > lf94: The games Forth lets you play by exposing the return stack are really quite cool.  I have a whole flock of "conditional return" and "conditional double return" words in my own Forth.  I don't even have the usual IF THEN WHILE etc. stuff - I use those conditional return items exclusively.
2024-03-18 21:50:26 <veltas      > GeDaMo: It feels like someone was commissioned to do an illustration for some "Atari program" and assumed it was some sort of avent garde videogame
2024-03-18 21:50:37 <veltas      > avant*
2024-03-18 21:50:58 <GeDaMo      > The 80s was like that though
2024-03-18 21:52:43 <veltas      > To be fair game art didn't really have any bearing on the game either
2024-03-18 22:12:33 <veltas      > lf94: Thanks for posting zenv on lobsters, spent a little time in the sun there on hacker news too
2024-03-18 22:13:11 <veltas      > Only noticed it was on there scrolling with my wife earlier to see if there was anything interesting on HN :)
2024-03-18 22:13:57 <GeDaMo      > It's on https://twostopbits.com/ too
2024-03-18 22:15:04 <veltas      > Oh cool I've not seen that website before, looks interesting
2024-03-18 22:15:22 <GeDaMo      > Yeah, lots of retro stuff
2024-03-18 22:47:45 <veltas      > Has anyone here tried kitten?
2024-03-18 23:14:24 <Al2O3       > https://news.ycombinator.com/item?id=13345832
2024-03-18 23:14:26 <Al2O3       > nope.
2024-03-18 23:14:33 <Al2O3       > well, I haven't, maybe someone else has.
2024-03-18 23:15:39 <Al2O3       > but ai maybe has, just did a port (mac thing) search for kitten, and there is a robotfindskitten :)
2024-03-18 23:16:02 <Al2O3       > now looking around for source of kitten, for osx.
2024-03-18 23:17:02 <Al2O3       > and for those that care, https://kittenlang.org/
2024-03-18 23:18:24 <Al2O3       > veltas you may try #concatenative, that is where apparently the author of kitten suggests folks go on IRC
2024-03-18 23:18:50 <veltas      > I will try
2024-03-18 23:18:54 <veltas      > On libera.chat?
2024-03-18 23:19:27 <Al2O3       > I suspect so, and here are at least 3 examples.
2024-03-18 23:19:28 <Al2O3       > https://rosettacode.org/wiki/Kitten
2024-03-18 23:20:56 <Al2O3       > 99 bottles :)   https://rosettacode.org/wiki/99_bottles_of_beer#Kitten