2022-05-10 03:56:31 <veltas      > That's only like the tenth time I've forgotten REFILL leaves a flag on the stack
2022-05-10 09:11:07 <KipIngram   > What does REFILL do?
2022-05-10 09:14:15 <KipIngram   > Oh, I found it.
2022-05-10 09:14:53 <KipIngram   > That's what QUERY did in older systems?
2022-05-10 09:16:29 <KipIngram   > I notice that its description carefully refers "the input source" rather than "the keyboard."  In my system QUERY loads tib from the keyboard, always - LOAD brings source in from the disk into a disk buffer, and it gets interprted directly from there.
2022-05-10 09:16:44 <KipIngram   > In a standard system is there a flow through the tib even with disk source?
2022-05-10 09:17:39 <KipIngram   > If so, it would mean that you could safely tinker with the input if you wanted to, since you wouldn't be tinkering with the actual disk data.
2022-05-10 09:18:09 <KipIngram   > I'm not sure offhand why that would be useful, but it would be possible.
2022-05-10 09:27:06 <KipIngram   > Not sure I understand what that flag is for.  My QUERY just doesn't return until a tib full of input is ready.
2022-05-10 09:29:24 <KipIngram   > Oh, I see.  Looks like it was intended to support stuff like evaluating strings and so on - you get false when you've exhausted the string.  That seems sensible enough.
2022-05-10 09:32:51 <KipIngram   > I handle that by arranging for the null word to be "parsed out" when there's no further actual input.  WORD won't advance past a null, and if that's all ti sees, it return the empty string as the word found.
2022-05-10 09:33:08 <KipIngram   > And that is in my dictionary - it's an immediate word that precipitates a "double return."
2022-05-10 09:33:26 <KipIngram   > The idea being that breaks you out of the infinite parse/execute loop.
2022-05-10 10:22:52 <dave0       > KipIngram: having an empty word is tricky ;-)
2022-05-10 10:24:47 <dave0       > but in sectorforth it's a single jump instruction for an empty word ie length=0
2022-05-10 11:11:52 <thrig       > a wizard with the empty name might be mighty powerful in Earthsea
2022-05-10 11:18:22 <veltas      > KipIngram: TIB is not part of Forth 200x
2022-05-10 11:18:48 <veltas      > TIB and/or SOURCE could be redirected if the input source changed, so I don't think you need to copy stuff into a specific buffer
2022-05-10 11:37:28 <KipIngram   > I see.  Sounds better, actually.  I've always tended toward somewhat old fashioned machinery of that sort.  I'd say my system is more like FIG than anything else, except for some specific changes like a separate region for headers and so on.
2022-05-10 11:38:49 <KipIngram   > My word set has deviated from FIG a fair bit, but underlying "system structure" is still very FIG-ish.
2022-05-10 11:39:34 <KipIngram   > Different header layout; one of you guys keyed me into the desirability of changing that.
2022-05-10 11:40:17 <KipIngram   > It just makes a lot of sense for the name field to be the last thing in the header.  Removes the need to scan over a variable length item.
2022-05-10 11:40:56 <KipIngram   > And I decided to put the PFA pointer before the CFA  pointer, and to have that CFA pointer be the "pointer point" for the header.  The PFA pointer is optional - primitives don't have one.
2022-05-10 11:41:38 <KipIngram   > So I wound up settling on PFA, CFA, link, name.
2022-05-10 11:42:05 <KipIngram   > With pad after the name to 32-bit align the next header.
2022-05-10 20:37:21 <vms14       > this is how my not so forth is: https://termbin.com/ozxl
2022-05-10 21:04:05 <vms14       > there's something you dislike from that or that I should do it in another way?
2022-05-10 21:05:13 <vms14       > it's very different from how forth does the stuff, so it's likely you don't like it at all
2022-05-10 21:06:42 <vms14       > I'd like to add locals, I know chuck dislikes them, but I use words as variables
2022-05-10 21:07:33 <vms14       > I'd like to have some words defined temporarily inside the scope of a word and not pollute the namespace
2022-05-10 21:34:58 <KipIngram   > vms14: I have a convenient way to define words that I can use to compile other words and then remove from the dictionary.
2022-05-10 21:35:28 <KipIngram   > The parts required for runtime remain, but the parts related to the "namespace" get rendered inaccessible.
2022-05-10 21:40:59 <vms14       > yes in part it seems like what I want is FORGET
2022-05-10 21:41:53 <vms14       > I suppose I can create let
2022-05-10 21:42:34 <vms14       > (bindings) (code) let
2022-05-10 21:43:01 <vms14       > I struggle a bit when deciding the order of the arguments for a word
2022-05-10 21:43:44 <vms14       > I try to think in the concatenative feature of a rpn + stack language
2022-05-10 21:44:25 <vms14       > depending the order I decide I can avoid a lot of swap rot etc
2022-05-10 22:11:32 <vms14       > : let package-name let-counter :let-counter ++ :let~a package :return-package set eval-list package-name return-package package package-remove ;
2022-05-10 22:12:23 <vms14       > this is let, it just creates a temporary package, executes code and removes the package returning to the previous current package
2022-05-10 22:12:44 <vms14       > xD
2022-05-10 22:13:34 <vms14       > (1 :oh set oh .) let
2022-05-10 22:13:53 <vms14       > I suppose will be enough
2022-05-10 22:14:34 <KipIngram   > Well, FORGET can only take away EVERYTHING back to some point - you can't leave later stuff and take away earlier stuff.
2022-05-10 22:15:10 <KipIngram   > The dictionary is almost like another stack - you can push new words into it, pop the latest word(s) off of it.
2022-05-10 22:15:15 <KipIngram   > But you can't "edit" it.
2022-05-10 22:15:35 <vms14       > KipIngram: but you can compile a dummy word as a marker for forget
2022-05-10 22:15:41 <KipIngram   > My feature doesn't "move" anything - it just unlinks the undesired names from the linked list forming the dictionary.
2022-05-10 22:15:56 <KipIngram   > Sure, but you still remove everything back to that point.
2022-05-10 22:15:58 <vms14       > would be like a restore point
2022-05-10 22:16:07 <KipIngram   > Yes.
2022-05-10 22:16:13 <vms14       > that would act as a temporal binding
2022-05-10 22:16:31 <KipIngram   > Mine works like so:
2022-05-10 22:16:35 <KipIngram   > .: foo ... ;
2022-05-10 22:16:39 <KipIngram   > .: bar ... ;
2022-05-10 22:16:44 <KipIngram   > : bam  foo bar ;
2022-05-10 22:16:47 <KipIngram   > .wipe
2022-05-10 22:16:58 <KipIngram   > And at that point foo and bar are no longer recognized, but bam is.
2022-05-10 22:17:26 <KipIngram   > The compiled definitions for foo and bar still exist, so that the compiled definition of bam can reference them.
2022-05-10 22:17:37 <KipIngram   > But the names can no longer be found in the dictionary search.
2022-05-10 22:17:41 <vms14       > then words compiled with .: are temporary
2022-05-10 22:17:49 <vms14       > and .wipe kills them
2022-05-10 22:17:56 <KipIngram   > Yes.  .: is the same as :, except it sets a flag in the header.
2022-05-10 22:18:06 <KipIngram   > .wipe scans the dictionary and unlinks words with that flag set.
2022-05-10 22:18:33 <KipIngram   > The RAM is still consumed.  It's only the namespace that is affected by .wipe.
2022-05-10 22:19:13 <KipIngram   > In an earlier version of this I did it in a way such that the RAM occupied by the NAMES foo and bar would be recovered.
2022-05-10 22:19:14 <vms14       > making your own language is so plain fun
2022-05-10 22:19:20 <KipIngram   > I put those names in a temporary area.
2022-05-10 22:19:49 <KipIngram   > I didn't bother with that this time - I keep the names too, mainly so a "decompile" word can print them out.
2022-05-10 22:20:11 <KipIngram   > I.e., SEE BAM would still show : BAM  FOO BAR ;
2022-05-10 22:20:28 <KipIngram   > Whereas if I recover the RAM those names were in, I'd have no way of printing them out.
2022-05-10 22:20:52 <KipIngram   > I'd get something like : FOO noname(adr) noname(adr) ;
2022-05-10 22:21:11 <vms14       > I've added some sort of documentation
2022-05-10 22:21:44 <vms14       > :some-word "This is the documentation of some-word..." add-doc
2022-05-10 22:21:59 <vms14       > this would go to a database and be stored permanently
2022-05-10 22:22:25 <vms14       > :some-word doc   this will return that stored string
2022-05-10 22:23:48 <vms14       > sad is I have no heredocs (multiline strings)
2022-05-10 22:26:17 <KipIngram   > "Strongly traditional" Forth systems organize the disk into blocks (fixed size) rather than files.  Just numbered blocks.  And now and again you bump into a system that provides a field in the header specifying the block where the definition of a compiled word lives.
2022-05-10 22:26:32 <KipIngram   > so it's easy to have a source editor just pop that block open so you can look at the definition.
2022-05-10 22:31:05 <vms14       > this is nice in part
2022-05-10 22:31:29 <vms14       > I'd like to have some reflection and some debugging stuff
2022-05-10 22:31:37 <vms14       > atm I have a word named trace
2022-05-10 22:31:50 <vms14       > 1 trace   sets debug to 1
2022-05-10 22:32:41 <vms14       > (function names to watch) trace    this sets the functions you want to trace
2022-05-10 22:33:11 <vms14       > my functiions call a function called debug that will work only when trace is 1
2022-05-10 22:33:40 <vms14       > and debug knows who is calling so you can set which words you want to see and will only work when called from those
2022-05-10 22:37:09 <vms14       > I'm fine as long as I don't think in efficiency
2022-05-10 22:37:26 <vms14       > won't be efficient anyways, so I won't care
2022-05-10 22:38:13 <vms14       > I'll care more about how I want things to be done and I hope it's fast enough to be useful for some stuff
2022-05-10 22:38:59 <vms14       > actually I can nest loops and conditionals, have recursion and variables packages, etc
2022-05-10 22:40:13 <vms14       > I can add sql access and file functions, I've also tried to bind Xlib from C to perl and I've done some bindings, I want to put xlib functions to this language
2022-05-10 22:50:55 <vms14       > actually is not so bad idea to use perl to implement forth (even if this is not a forth)
2022-05-10 22:51:25 <vms14       > but my main drawback with forth is: forth is awesome, but you won't find a forth with libraries
2022-05-10 22:51:41 <vms14       > no sql gui sockets etc
2022-05-10 22:52:29 <vms14       > with perl or any other high level language I can add all this stuff in a very easy way
2022-05-10 22:53:20 <vms14       > also my stack is able to hold any kind of type, so the words which are variables and functions at the same time
2022-05-10 22:54:29 <vms14       > won't be efficient but it can have all the cpan available
2022-05-10 22:54:35 <vms14       > and ffi to C
2022-05-10 23:30:38 <KipIngram   > It's part of the core philosophy of Forth to eschew libraries.
2022-05-10 23:31:33 <KipIngram   > Because a library is an attempt to solve a problem before you know what the problem is.  The idea is that you sit down with your problem in front of you, you achieve a deep understanding of it, and then you implement a solution that is *precisely tailored* to your problem.  Zero excess baggage.
2022-05-10 23:33:19 <KipIngram   > And, looked at another way, Forth *is* a library.  It's a library of words that you can call forth and use to solve problems.  But it's a library of *simple* functions - trying to push too much sophistication into the "pre-built" stuff skews you away from that optimum solution.  You will start compromising your solution to "make library X work."  You'll use data structures that library X supports just so you
2022-05-10 23:33:21 <KipIngram   > can use library X, whereas what you SHOULD be using is the data structure that is PERFECT FOR YOUR PROBLEM.