2023-10-30 06:05:46 <veltas      > Grrr young people
2023-10-30 06:10:57 <dave0       > 
ACTION shakes cane at young people

2023-10-30 06:12:57 <veltas      > I don't get em
2023-10-30 09:20:47 <KipIngram   > Uh oh.  I know what you mean generally, but... details?
2023-10-30 10:10:11 <veltas      > I'm starting to realise I do my best work when I just spam out crap code and then refactor it until it doesn't smell
2023-10-30 10:10:22 <veltas      > If I try and write it 'properly' initially it goes over-engineered
2023-10-30 10:38:08 <olle        > Wonder if there's Forth that transpiles to PHP :d
2023-10-30 10:38:32 <olle        > You'd get a nice ecosystem and std lib that way.
2023-10-30 10:39:54 <veltas      > : FRAMEWORK ." <p>Hello" ;
2023-10-30 10:39:54 <veltas      > Done
2023-10-30 10:41:08 <olle        > Hehe naah
2023-10-30 10:41:20 <olle        > Forth words can be both prefox and postfix right?
2023-10-30 10:41:21 <veltas      > What else could you want?
2023-10-30 10:41:27 <veltas      > Yes
2023-10-30 10:41:35 <olle        > Neat
2023-10-30 10:41:44 <olle        > What else? Eeeh. https://packagist.org/explore/
2023-10-30 10:41:54 <veltas      > Give me requirements that isn't just a big wishlist of unnecessary stuff
2023-10-30 10:42:50 <olle        > Jeez no
2023-10-30 10:43:53 <veltas      > Or, rather, just write what you need, and be honest about the real requirements
2023-10-30 10:44:07 <veltas      > I'm confident forth can be used for your backend, whether it *should* ....
2023-10-30 10:44:21 <olle        > lol
2023-10-30 10:44:34 <olle        > Price just went up haha
2023-10-30 10:45:03 <veltas      > Ask not what Forth can do for you ...
2023-10-30 10:45:52 <olle        > But ask what the client is willing to pay hehehe
2023-10-30 10:46:00 <olle        > And the other devs are willing to maintain :D
2023-10-30 11:00:37 <KipIngram   > olle: Forth words are postfix re: the data stack, but prefix re: the input stream.
2023-10-30 11:00:48 <olle        > Hmmmm
2023-10-30 11:00:53 <olle        > KipIngram: Got any good link?
2023-10-30 11:01:11 <KipIngram   > For example, CONSTANT is postfix re: its numerical argument, but prefix re: the word it parses out of the input stream to use as the name.
2023-10-30 11:01:19 <KipIngram   > No, I don't have any links that talk about that.
2023-10-30 11:02:01 <olle        > Hm
2023-10-30 11:02:32 <KipIngram   > But generally speaking, a word can't know what's *going to be* on the stack, and if you tried to give it a prefix argument in the input stream, Forth wouldn't know what to do with that argument when it saw it (which it would PRIOR to seeing the main word we're talking about).
2023-10-30 11:02:39 <KipIngram   > So it kind of has to be the way it is.
2023-10-30 11:02:53 <KipIngram   > If Forth supported literal strings, then you could imagine something like
2023-10-30 11:02:56 <olle        > I can list the def of CONSTANT right?
2023-10-30 11:03:01 <KipIngram   > 23 "my-constant" CONSTANT
2023-10-30 11:03:06 <KipIngram   > and then it would be all postfix.
2023-10-30 11:03:26 <KipIngram   > Some Forths have a word SEE that will decompile a word to one degree or another.
2023-10-30 11:03:46 <KipIngram   > A problem there is that in some cases it can't figure out exactly how to decompile it.
2023-10-30 11:03:55 <KipIngram   > But for a constant it could, i'd say.
2023-10-30 11:04:56 <KipIngram   > and of course, you could implement a version of CONSTANT that was all prefix, i.e.
2023-10-30 11:05:02 <KipIngram   > CONSTANT ALPHA 23
2023-10-30 11:05:36 <KipIngram   > The definition of CONSTANT parse 23 out as a word, and then run NUMBER on it.
2023-10-30 11:05:50 <KipIngram   > But the interpreter will already do that for you if you put the 23 first, so it's an overcomplication.
2023-10-30 11:07:34 <KipIngram   > In his old book Chuck outlines a methodology for supporting infix arithmetic.
2023-10-30 11:07:51 <KipIngram   > And it's a method that would work in practically any Forth.
2023-10-30 11:08:09 <KipIngram   > It has an ability to "postpone" operations as needed to handle standard precedence rules.
2023-10-30 11:08:21 <olle        > Yea
2023-10-30 11:08:26 <olle        > Interesting
2023-10-30 11:08:50 <KipIngram   > If you come to an operator before you have all of its arguments, you push a record of that onto an "operation stack."  Then when you get that second argument onto the stack the operator gets popped and executed.
2023-10-30 11:09:05 <KipIngram   > And the different operators have different "levels" which lets you handle precedence.
2023-10-30 11:09:07 <olle        > ok cool :)
2023-10-30 11:09:13 <olle        > Sounds like it can become a mess tho
2023-10-30 11:09:31 <KipIngram   > I'm sure it's similar to the process code generators in languages like C go throuh.
2023-10-30 11:09:34 <KipIngram   > through
2023-10-30 11:09:50 <olle        > Maybe yea
2023-10-30 11:11:00 <KipIngram   > I think the whole business shows us kind of how Chuck changed over the years - later on his attitude was more "You shouldn't want to do that."
2023-10-30 11:11:26 <KipIngram   > But at the time he wrote that book he seemed eager to show people how they could do anything that was important to them.
2023-10-30 11:11:42 <KipIngram   > He wanted to "address" the likely things people would point to as "wrong with" his language.
2023-10-30 11:12:04 <KipIngram   > Later he decided they were all features.  :-)
2023-10-30 11:13:35 <KipIngram   > You know, we've talked a bit about "macros" in Forth.  I think when i've thought of that in the past, I've thought of it as being something supported by the interpreter.
2023-10-30 11:13:59 <KipIngram   > But I suddenly realize this morning that nothing is really stopping you from wrigint a word that simply modifies the upcoming input stream.
2023-10-30 11:14:10 <KipIngram   > Shoves its own text in as the next text to be fetched.
2023-10-30 11:14:32 <KipIngram   > That could be done on an entirely standard Forth, although you would need to know how the machinery of the tib and >in and so on worked.
2023-10-30 11:15:09 <KipIngram   > And I'm not sure how it would work when LOADing - I guess you'd have to jimmy in another level - like "simulate" a nested LOAD.
2023-10-30 11:15:19 <KipIngram   > In fact, that would work in interpreter mode too.
2023-10-30 11:15:40 <KipIngram   > If you did it that way you wouldn't have to tinker with TIB.
2023-10-30 11:15:57 <KipIngram   > So yeah - that can be done as an entirely self-contained feature.
2023-10-30 11:21:27 <KipIngram   > I think in the old Forth's i've generally used as my working models, the system uses the variable BLK to hold the block number of the block currently being loaded.  If I had a desire to support this macro thing, I'd change that a little, so that instead of remembering a block # the system would just have an address of the current buffer text is being taken from.  When you executed a macro word, it would save
2023-10-30 11:21:29 <KipIngram   > the current value of that on the return stack, just like LOAD does, and instantiate a new value that would point to the string  you'd compiled for that macro.
2023-10-30 11:22:02 <KipIngram   > So the system would go off and interpret that, and then would pop back to the previous buffer exactly the way it does when it finishes a LOAD.
2023-10-30 11:22:23 <KipIngram   > In other words, the macro handling would BE A LOAD operation - just not on a block but rather on a pre-compiled string buffer.
2023-10-30 11:23:09 <KipIngram   > MACRO <name> <everything else on the line is the expansion>
2023-10-30 11:23:46 <KipIngram   > It would be so easy to support this there's probably no good reason not to.
2023-10-30 11:24:43 <KipIngram   > Oh, wait - that wouldn't compile.  compiling a macro execution would take more effort.
2023-10-30 11:25:04 <KipIngram   > You'd have to be able to run INTERPRET on your string.
2023-10-30 11:25:32 <KipIngram   > And if you did, that would probably ALSO work from the interpreter.
2023-10-30 11:26:54 <KipIngram   > It would look a lot like ." - instead of printing out the precompiled string, it would call INTERPRET on it.
2023-10-30 11:29:06 <GeDaMo      > https://www.atariwiki.org/wiki/Wiki.jsp?page=Forth%20Macros
2023-10-30 11:36:23 <KipIngram   > :-)  That's not as fun as inventing myself.
2023-10-30 11:42:26 <rendar      > in my Forth i have: `#u8 1`, or special words which begins with special char "#" which are used to modify the internal interpreter, in such a case it tells the interpreter: the next integer interpret is an unsigned 8-bit instead of the standard integer type
2023-10-30 11:42:37 <rendar      > i think that those are some form of primitve macros
2023-10-30 11:44:16 <KipIngram   > rendar: I have a way to embed the base in my number format; basically it's <base>:<digits>.
2023-10-30 11:44:29 <KipIngram   > I do support "shortcuts" for hex and binary, though - x: and b:
2023-10-30 11:44:46 <rendar      > yeah i had that too, but in my system i found more useful the use of special words, also because types are many
2023-10-30 11:44:53 <KipIngram   > But I see no need to tell it whether it's signed or unsighed; that has to do with how it's interpreted later.
2023-10-30 11:45:18 <rendar      > also IF control flow is specified with special words, such as: >0? #if-true dup #else drop #fi
2023-10-30 11:45:19 <KipIngram   > But yeah, if you want to discriminate between signed and unsigned at the level of the number itself, you'd need that.
2023-10-30 11:45:58 <KipIngram   > Yeah, conditional compilation.  I don't have any real firmed up way to do that, but it would be easy enough to implement.
2023-10-30 11:46:39 <rendar      > i have invented the #if-true, #if-false, #if-nil thing, if you think about that, the condition is already into the stack in Forth, so you need simply to check if its true,false,nil or something very basic like that
2023-10-30 11:46:53 <KipIngram   > Right.
2023-10-30 11:47:01 <rendar      > :)
2023-10-30 11:47:38 <KipIngram   > Forth normally allows you to use [ and ] to switch out of and back into compile mode.  So you can do stuff like
2023-10-30 11:47:54 <KipIngram   > : foo ... [ <calc a value> ] LITERAL ... ;
2023-10-30 11:47:56 <rendar      > also, in such IF control flow, you don't need "else if", if you have #if-true, you'll get only #else to that condition
2023-10-30 11:48:05 <rendar      > oh
2023-10-30 11:48:07 <KipIngram   > It lets the value you want to make a literal from be calculated at compile time.
2023-10-30 11:48:10 <rendar      > that's pretty cool
2023-10-30 11:48:26 <KipIngram   > It is; I don't use it very often, though.
2023-10-30 11:48:34 <rendar      > well my Forth is always interpreted
2023-10-30 11:48:40 <rendar      > there is no compilation
2023-10-30 11:48:49 <KipIngram   > Oh yeah - I tend to forget.  :-)
2023-10-30 11:48:59 <rendar      > at least, there is compilation in some form of bytecode
2023-10-30 11:49:39 <KipIngram   > I'm going to use a tokenized "vm" structure in my next one.  So I have trouble deciding whether it's  going to be a token-threaded Forth or a code-threaded Forth.
2023-10-30 11:49:56 <KipIngram   > It will be token threaded in the operation of the vm, but "on" the vm it will be a code-threaded system.
2023-10-30 11:50:43 <rendar      > token-threaded? what you mean? is that related to multi-threading?
2023-10-30 11:51:13 <KipIngram   > No - sorry.  Forth uses the word "threading" in an entirely nonconventional way that has nothing to do with "multi-threading" threads.
2023-10-30 11:51:26 <KipIngram   > It's just a reference to how the Forth engine works its way through definitions.
2023-10-30 11:51:35 <KipIngram   > How it finds the code to run for each compiled definition item.
2023-10-30 11:52:03 <KipIngram   > There is "code threading," which means it basically just compiles processor machine code and uses the instruction set's "call" process to navigate.
2023-10-30 11:52:25 <KipIngram   > There is "indirect threading," where a compiled definition is a list of addresses that point to OTHER addresses which finally point to code.
2023-10-30 11:52:40 <KipIngram   > There is "direct threading," where the compiled definition cells point directly to executable code.
2023-10-30 11:52:54 <KipIngram   > Indirect threading is the "traditional original."
2023-10-30 11:53:24 <KipIngram   > You can use control over those various levels of indirection to do all the different pony tricks your system needs to do.
2023-10-30 11:53:39 <KipIngram   > In a direct threaded system you have one level less to work with, so it changes how certain features get implemented.
2023-10-30 11:54:39 <KipIngram   > And code threading takes away the rest of your "knobs," so again it makes certain things more tedious to implement.  But you can implement everything regardless - in the end as long as you aren't writing code that "looks under the hood" it all works the same.
2023-10-30 11:55:53 <KipIngram   > In the end the goal is always to make a certain sequence of machine code bits run - you can build any kind of data structure around that that you like.
2023-10-30 11:57:04 <KipIngram   > In direct and indirect threaded systems, your definitions don't actually produce any new machine code.  They produce data structures that some critical bit of pre-existing code uses as a roadmap for finding the code to run.
2023-10-30 12:05:20 <rendar      > oh i see
2023-10-30 12:05:37 <rendar      > yeah i remember code-threading it was a 80s thing
2023-10-30 12:05:46 <rendar      > also used in other languages
2023-10-30 12:06:19 <rendar      > isn't that very similar to C compiler which inlines some functions?
2023-10-30 12:07:47 <veltas      > I wouldn't say so
2023-10-30 12:08:00 <veltas      > The B runtime was threaded I think
2023-10-30 12:08:24 <veltas      > Because they wanted to run B on machines that weren't word-addressed, and B was designed for word-addressed arch's
2023-10-30 12:08:31 <GeDaMo      > Lots of languages used threaded code implementations
2023-10-30 12:12:01 <rendar      > i see
2023-10-30 12:12:13 <rendar      > and i also guess that now it's practically disappeared
2023-10-30 12:16:42 <veltas      > Actually I think JIT is essentially threaded, maybe STC
2023-10-30 12:17:33 <GeDaMo      > JIT basically concatenates machine code sequences
2023-10-30 12:18:11 <rendar      > but JIT also *creates* machine code sequences, no?
2023-10-30 12:18:32 <veltas      > As do some STC forths
2023-10-30 12:18:49 <veltas      > Well actually most forths can create machine code, but from an assembler vocabulary
2023-10-30 12:19:05 <GeDaMo      > I'm not sure what state of the art with JIT is
2023-10-30 12:19:56 <veltas      > Me neither
2023-10-30 12:34:24 <KipIngram   > rendar: A lot of modern Forth systems use code threading.  There's a perception that it just "has to be" the fastest, and it probably is, most of the time.
2023-10-30 12:34:32 <KipIngram   > There are exceptions, though.
2023-10-30 12:34:37 <rendar      > hmm i see
2023-10-30 12:34:57 <veltas      > Fastest would be a full compiler probably, or JIT if we include compilation time
2023-10-30 12:35:26 <veltas      > The only 'full compiler' I know is gforth which uses GCC I think?
2023-10-30 12:35:27 <KipIngram   > Yes, for sure.  At this point there has been so much optimization effort put into mainstream C compilers that there's almost no competing with them.
2023-10-30 12:35:42 <veltas      > Although your mileage may vary
2023-10-30 12:35:45 <KipIngram   > But the time it takes to write a Forth is trivial compared to all of those man years of work.
2023-10-30 12:36:08 <veltas      > I think someone's got LLVM working for Forth too
2023-10-30 12:36:25 <KipIngram   > Wouldn't surprise me.
2023-10-30 12:36:34 <veltas      > I would guess that's slower than gforth to compile, and not necessarily faster, based on other LLVM front-ends!
2023-10-30 12:36:36 <KipIngram   > But in my mind that kind of defeats the point of Forth.
2023-10-30 12:36:44 <veltas      > Exactly
2023-10-30 12:40:00 <KipIngram   > One way I like to present it is to imagine that it's 1985 again.  You've got an IBM PC with the plain vanilla DOS operating system (which includes the DEBUG program), and nothing else.  You face a programming task.
2023-10-30 12:40:26 <KipIngram   > You can bootstrap a Forth using DEBUG, and it wouldn't take too terribly long to do that.  And now you have a programming environment.
2023-10-30 12:40:42 <GeDaMo      > https://bootstrapping.miraheze.org/wiki/Main_Page
2023-10-30 12:40:43 <KipIngram   > I don't think there's any language that would let you get rolling as quickly.
2023-10-30 12:40:57 <KipIngram   > Any other language, that is.
2023-10-30 15:57:24 <KipIngram   > You know, given the size of RAM on most common computers these days,  very viable Forth platform would boot from a USB stick and read whatever number of blocks from the stick that there was room in RAM for it to read.  Then you'd work entirely in RAM, your whole session.  At any time you could FLUSH, snatch out the stick, and turn off the computer.  That would be the extent of it.
2023-10-30 15:58:57 <KipIngram   > Of course, if you needed to use more USB content than you had room for, Forth will already recycle recycle RAM disk buffers.  But I suspect that most of the time you wouldn't need to do that, common as RAM is.
2023-10-30 15:59:31 <KipIngram   > Hmmm.  "recycle recycle."  I guess that "really recycle well" or something.  :-)
2023-10-30 16:03:40 <KipIngram   > I actually ran Linux that way for a while back before IBM bought the office I'm at currently.  The previous owner was an ornery little guy who had to have everything exactly his way.  He issued me a Windows notebook.  I cooked up a USB-stick based Linux that would boot to RAM and also had a partition on it where I could keep non-volatile data.
2023-10-30 16:04:14 <KipIngram   > It was pretty neat - it used LUKS to encrypt it all, and a package that you get hold of back then called remaster-sys.
2023-10-30 16:04:29 <KipIngram   > Remaster-sys would let you create an iso based on a configured system.
2023-10-30 16:04:55 <KipIngram   > You could even log into your online accounts and stuff before you ran remaster-sys, and the resulting iso would boot up with you already logged in.
2023-10-30 16:06:18 <KipIngram   > So I got everything tweaked just right and burned the stick, and that's how I used that computer for quite a long time.  Meanwhile my Windows OS sat there completely idle.  As far as it was concerned I hadn't logged in in months.
2023-10-30 16:07:17 <KipIngram   > I did have to use a "lean" Linux, but Forth would face no such issue.
2023-10-30 16:07:35 <KipIngram   > I think that notebook had 4GB.
2023-10-30 17:21:58 <KipIngram   > Geez.  I am trying to re-program one of my garage door openers, and I've downloaded manuals for the opener and the remote and it just will not work.
2023-10-30 17:22:02 <KipIngram   > How frustrating.
2023-10-30 17:22:10 <KipIngram   > It's not like the instructions are... complicated.