2023-09-07 00:27:27 <KipIngram   > I just finished re-watching the 1990 mini series of The Stand.
2023-09-07 00:27:48 <KipIngram   > I think it's underrated - there are moments in there (especially in the last quarter of it) that are just pure gold.
2023-09-07 00:29:16 <KipIngram   > Oh, hey - I realized that if I give myself a group of call instructions, that use different bit widths for the operand, I can "optimally compact" my calls.
2023-09-07 00:29:51 <KipIngram   > Maybe I start with three bits, or four, which will let me go up to 8 cells or 16 cells back.  And then have a collection of them, with steadily increasing operand sizes.
2023-09-07 00:30:11 <KipIngram   > Finally you'd come to the end of those and have the "whole rest of the cell" call.
2023-09-07 00:31:37 <KipIngram   > My underlying code can shfit the instruction word over however many bits I want.
2023-09-07 00:32:56 <KipIngram   > Anyway, given how many calls Forth makes, it's likely worth optimizing them, especially when it doesn't impair performance at all.
2023-09-07 00:33:42 <KipIngram   > Just increase code size A LITTLE - small enough increase that it's almost certainly made up for in later savings.
2023-09-07 00:44:25 <KipIngram   > Another compaction possibility is to use more than one of the instruction slots for any particular call.  That would make the remaining bits of the seven opcode bits don't cares, and they could become part of the call target.
2023-09-07 00:45:08 <KipIngram   > Broad spectrum of possibilities.
2023-09-07 06:27:02 <Zarutian_iPad> I have a question regarding programming languages in general
2023-09-07 06:28:55 <Zarutian_iPad> there seems to be some sort of hindurvitni of wanting 'static types' by some folk and the annoying and brittle buildstep that results from that
2023-09-07 06:29:08 <Zarutian_iPad> the question is why?
2023-09-07 06:34:08 <rendar      > Zarutian_iPad, it depends on what are you doing, and at what abstraction level you're operating
2023-09-07 06:34:21 <rendar      > if you're in C, you want static types
2023-09-07 06:34:30 <rendar      > if you're in py, you don't
2023-09-07 06:38:33 <Zarutian_iPad> sure because C is a compile only language (/me stuffs csh into hole) and was meant for that. But those 'types' are mostly just record or bitfield layout types
2023-09-07 06:39:19 <Zarutian_iPad> not the 'fancy' stuff that haskellers or typescript folk seem to push
2023-09-07 06:42:21 <rendar      > Zarutian_iPad, well, lately there was a returning in love with types, even python added type annotations, which you can "enforce" with some linter
2023-09-07 06:44:26 <Zarutian_iPad> which befuddles me a bit. I am more used to use guards from E (wiki.erights.org) when I need to enforce a property
2023-09-07 06:45:38 <Zarutian_iPad> I do like jsdoc (with Agoric's extensions) for javascript code though for IDE accessible documentation
2023-09-07 08:19:46 <veltas      > C's typesystem is about the level of features I desire. You have type checking, which allows you to prevent a lot of misuse, and you can even 'force' type checking where it isn't there by default in C with some creativity
2023-09-07 08:20:42 <veltas      > But I've never found myself losing confidence in C because I don't understand how to get what I want to build without ugliness
2023-09-07 08:21:13 <veltas      > Or working through pages of compiler errors that struggle to explain where exactly the problem originates
2023-09-07 08:22:42 <veltas      > It's very "this is what I expect, this is what I got". Not "this should work but I don't understand the 10'000 line header file well enough to troubleshoot this"
2023-09-07 08:23:35 <veltas      > C++ is obviously the worst offender here but the 'safe' or lazy functional languages have this too
2023-09-07 08:24:55 <veltas      > I can't comment on the Rust situation, or how easy static errors are to diagnose. I'd hope better since that's really a lesson learned in C++
2023-09-07 08:46:48 <Zarutian_iPad> how that rustcon keynote fiasco played out has put me off bothering with rust
2023-09-07 08:49:21 <Zarutian_iPad> but yeah there seems to be cyclic infatuation with static types that arise then fade out again
2023-09-07 09:04:43 <Zarutian_iPad> bbl
2023-09-07 09:20:29 <veltas      > I was in a student society at one point where we had invited a speaker to talk, and later the speaker informed us they would be talking about something unexpected and controversial
2023-09-07 09:21:21 <veltas      > The president said they didn't want the talk to be about that and they would cancel the talk if necessary, whereas most of the society execs seemed to agree with the speaker's stance and wanted the talk
2023-09-07 09:21:52 <veltas      > Ultimately I think I disagreed with the stance but argued for the talk to go ahead, and it did, on the basis that it's unreasonable and rude to cancel someone's talk like this
2023-09-07 09:23:39 <veltas      > If you don't want them to talk about something then that needs to be agreed in advance, or you need more actual contact while they're planning it out to have that level of control before they write a whole talk
2023-09-07 09:24:31 <veltas      > Amazingly it seems the Rust project don't understand this, even regarding something uncontroversial they thought it appropriate to stop thephd doing the keynote
2023-09-07 09:29:13 <veltas      > See a council I expect to not do things like this on basis that there's multiple people so at least one person should be able to chime in and say "hey maybe this is kind of rude and unfair"
2023-09-07 09:29:31 <veltas      > So it doesn't look good when stuff like this happens anyway
2023-09-07 09:30:00 <veltas      > But I can't read into it any further. It seems dysfunctional but I can't know how without being in the council. So it's just more meaningless drama
2023-09-07 09:30:39 <veltas      > And I can't know whether what thephd said about this is reasonable without more info
2023-09-07 09:32:09 <veltas      > And Rust is somewhat mature now anyway, it's matured into something I don't want because I don't think I value execution time over compilation time enough.
2023-09-07 09:51:36 <KipIngram   > I find a lot of our "censorship mentality" these days disturbing.
2023-09-07 09:51:58 <KipIngram   > I mean, we're supposedly all grown-ups and we really ought to be able to have the occasional difficult conversation.
2023-09-07 09:53:00 <KipIngram   > We get way to wound up in the whole "Oh, someone's feelings might get hurt" thing.
2023-09-07 09:53:38 <KipIngram   > too
2023-09-07 09:54:50 <KipIngram   > What was the controversial topic?  Usually this kind of thing relates to "social discussions," but here it sounds like something technical.
2023-09-07 10:01:12 <rendar      > let's say i have a word for wildcard matching, e.g. "hello!" matches with "hel*", now my question: should i push into the stack before the string "hello!" or the wildcard "hel*" ? then, the word will push true or false, but popping away string+wildcard?
2023-09-07 10:07:02 <KipIngram   > I usually push the situation-specific item I'm "checking" on first, and then the value I'm comparing AGAINST second.
2023-09-07 10:07:49 <KipIngram   > Sometimes I want to compare X to several items - I'll push X first, then push each compare item one at a time with a ". prefix" word that does the comparison - that . prefix causes it to keep the X around for the next compare.
2023-09-07 10:08:02 <KipIngram   > In my case I'm usually comparing characters or numbers, but it's the same idea.
2023-09-07 10:08:30 <KipIngram   > So I would go with "hello!" "hel*" s== or something like that.
2023-09-07 10:09:08 <KipIngram   > Also, that order "fits' with the standard "implicit 0" words - like 0= being equivalent to 0 =
2023-09-07 10:09:42 <KipIngram   > If the 0 came first: 0 X = then having a 0= word doesn't work quite as well.
2023-09-07 10:12:13 <KipIngram   > I'm not 100% sure I understood your question properly.
2023-09-07 10:14:55 <KipIngram   > You know, I'm staring at this list of instructions I'm buidling up, and I'm noticing that there are two classes.  There are instructions that are "type agnostic."  Control flow, stack manipulation, etc.  And then there are instructions that relate directly to the fact that what you have on the stack is an integer or address.
2023-09-07 10:15:44 <KipIngram   > So I'm nosing around for a way to efficiently let the item on the stack "steer" the handling of that second class of instructions.
2023-09-07 10:16:22 <rendar      > KipIngram, yeah
2023-09-07 10:17:47 <veltas      > KipIngram: At the society the controversial topic was related to early #gamergate discussion, I won't bother saying what or which side I was on at the time since I think it's a bit irrelevant
2023-09-07 10:17:50 <rendar      > KipIngram, well, but once you have "hello" "hell*" would you pop the 2 strings and push a bool?
2023-09-07 10:18:03 <rendar      > or, would you pop only "hel*" and then push one bool?
2023-09-07 10:19:00 <veltas      > KipIngram: The topic for Rust Project was thephd was doing the keynote talk, and wanted it to be about a proposal he was making, and for that reason they decided to downgrade it to a normal talk after some behind-doors discussion he wasn't privvy to
2023-09-07 10:19:37 <veltas      > But the sentiment of the council was basically that his talk sounded inappropriate for a keynote, which i don't disagree with, but they handled it quite poorly
2023-09-07 10:22:58 <KipIngram   > Yes, popping both strings and replacing them with a bool would be the "standard" operation of an s== word.
2023-09-07 10:23:31 <KipIngram   > Then I also include a .s== word which keeps the deeper one, for use in cases when I'm going to want to compare it to a list of things.
2023-09-07 10:23:43 <KipIngram   > But that's non-standard.
2023-09-07 10:24:30 <KipIngram   > I also have words that don't leave a flag but rather take or don't take an action, immediately.  like "return on match" would be s==;
2023-09-07 10:24:43 <KipIngram   > It would leave nothing on the stack.
2023-09-07 10:25:06 <KipIngram   > Also conditional looping, s==me
2023-09-07 10:25:37 <KipIngram   > It would also leave nothing - it would just loop back to the start of the word or not, based on the compare outcome.
2023-09-07 10:26:03 <KipIngram   > I don't actually have all those words for strings, but it's how I handle numerical comparisons.
2023-09-07 10:26:13 <KipIngram   > I just have s= which leaves a flag.
2023-09-07 10:27:46 <KipIngram   > So< I think for these type-aware words vs. agnostic words, I'll just group them all into one subset of the instruction list - by default they'll just do their usual integer/address thing, and if I want to start supporting typed items I'll just re-write the table entries for those items to make them "smarter."
2023-09-07 10:28:23 <KipIngram   > That way I get the peak performance when I'm not trying to do fancy things, and only pay a "type checking cost" when I'm actually trying to work with types.
2023-09-07 10:31:55 <KipIngram   > Of course an option is just to use subroutine calls rather than "instructions" for all of the fancy stuff, but I'd like to see if I can retain the compactness benefits those short instructions bring to the table even when working with typed items.
2023-09-07 10:33:09 <rendar      > veltas, thephd ?
2023-09-07 10:38:01 <KipIngram   > Also, those thoughts yesterday about being able to access definitions as broken out strings - I'm pretty unsure about that.  Ultimately where a definition is in the dictionary matters quite a lot - even allowing it to be seen out of context might just be confusion.
2023-09-07 10:38:03 <KipIngram   > confusing
2023-09-07 10:38:30 <KipIngram   > Exactly what a definition means depends on when it's compiled.
2023-09-07 10:39:48 <KipIngram   > We've seen some of that confusion right here in the last couple of weeks; not long ao we had that : foo ... ; : bar ... ; ; foo ... ; example, where someone was expecting bar to behave differently after foo was re-defined.
2023-09-07 10:41:56 <KipIngram   > Oh, sorry - : bar ... foo ... ;
2023-09-07 11:02:14 <KipIngram   > There's just a difference between the source string defining a word and the word's actual existence in the system.
2023-09-07 11:03:05 <KipIngram   > There is a correspondence, of course, but the exact correspondence includes a temporal factor; the correspondence held at compile time and not necessarily later.
2023-09-07 11:08:15 <veltas      > rendar: That's the handle of the person in question, I think you can Google that
2023-09-07 11:08:29 <rendar      > i see
2023-09-07 11:08:33 <veltas      > He's done all sorts, I seem to remember he made a low overhead C++ wrapper for the Lua API back in the day
2023-09-07 11:08:51 <veltas      > That looked quite good, never actually tried it myself though because the Lua API isn't that bad
2023-09-07 11:08:57 <veltas      > I'm sure someone will scoff at that though lol
2023-09-07 11:09:22 <veltas      > Now he seems to mostly irritate me by saying he doesn't like C even though he's senior in the standard
2023-09-07 11:10:34 <veltas      > I can understand why he was annoyed at Rust Project though
2023-09-07 11:11:09 <KipIngram   > Funny how these particular personalities tend to rise to prominence in various areas.
2023-09-07 11:11:17 <KipIngram   > Kind of become lightning rods.
2023-09-07 11:13:08 <KipIngram   > Oh, another thing I'm noticing in these Forth/calculator comparisons is to do with "search order/vocabulary" issues.  In Forth we can establish whatever search order we want at any time.  However, that doesn't change any word's functionality unless we compile using that search order.
2023-09-07 11:13:50 <KipIngram   > On the HP-48 line of calculators, instead you have a directory hierarchy.  The hierarchy gets established as you create the directories, and doesn't change thereafter.  So anytime you're in a particular directory it has the same ancestors.
2023-09-07 11:14:25 <KipIngram   > So in that case you wouldn't really expect any dynamic operational changes.
2023-09-07 11:16:35 <KipIngram   > The directory based approach is more Buckaroo Bonzai compatible - whereever you go, there you are.
2023-09-07 11:17:39 <KipIngram   > That kind of combats the confusion - /path1/voc and /path2/voc are two entirely different locations in the structure, and would be expected to do different things.
2023-09-07 11:19:21 <KipIngram   > I think the directory-oriented approach is a little more compatible with Forth's "fixed functionality after compiled" operation.
2023-09-07 13:52:51 <siesta      > forth is like rap drink drink drive drink drink drive hahaha
2023-09-07 14:55:33 <KipIngram   > :-)
2023-09-07 14:56:09 <KipIngram   > Also, these non-agnostic instructions don't even have to be the same instructions for various types.  It's just a set of instructions that can be completely defined per type.
2023-09-07 14:57:23 <KipIngram   > Basically the way this thing works is to take the instruction and use it as an index into a jump table.  When I want to step up to supporting types, my stack items will become pointers with a type field (type field will be there in the stack element).  So I can change the table pointers for the non agnostic instructions.
2023-09-07 14:58:01 <KipIngram   > The new code bits they point to will grab the type field from the top stack element and use it as a pointer to a new table, and THAT table will have the code pointers for that type's non-agnostic instructions.
2023-09-07 14:58:43 <KipIngram   > So that's a bit of extra indirection - it won't be as fast as the default typeless setup.  But we'll only engage that extra work when we ARE doing types, and there's  no way for that kind of extra function to be free.
2023-09-07 14:59:12 <KipIngram   > So for each type I'll be able to select what I want those instructions to be.
2023-09-07 15:00:06 <KipIngram   > For example, if the top stack element is a string, then perhaps + sends me to code that confirms the second stack element is also a string and concatenates them.
2023-09-07 15:00:59 <KipIngram   > If I've got a matrix, * will send me to code that looks at what considers the type field of the second stack element - eventually I'll get to the right kind of multiplication code.
2023-09-07 15:01:02 <KipIngram   > Etc.
2023-09-07 15:01:33 <KipIngram   > It's all extra work, but I'm getting a feel from it that it's still "reasonably fast" for what's being accomplished.
2023-09-07 15:02:15 <KipIngram   > And of course compiled code might not do all that - the compiler might figure out at compile time what's going to be needed and just go straight for it.
2023-09-07 15:02:44 <KipIngram   > Well, or maybe not - I may not have that throught all the way through.
2023-09-07 15:03:36 <KipIngram   > But I'm thinking first about the interactive experience, where I just shove whatever I want to onto the stack.
2023-09-07 19:36:23 <vms14       > KipIngram:   : oh ( 1 2 3 ) ;   this creates a list, but is mutable
2023-09-07 19:36:52 <vms14       > do you think it should be mutable? or return a new list every time
2023-09-07 19:37:45 <vms14       > i dislike it to be mutable
2023-09-07 19:38:18 <vms14       > but i assume a similar thing to a list in forth would also be mutable
2023-09-07 19:38:36 <vms14       > and i wonder if its really a problem or not
2023-09-07 19:39:23 <vms14       > in my case i dislike it because most of lists will be taken as code and can be funny if that code mutates
2023-09-07 19:39:45 <vms14       > but there are also benefits
2023-09-07 19:40:01 <vms14       > like for example it can avoid the use of a variable
2023-09-07 19:40:37 <vms14       > oh is now a variable as it returns a reference to a list
2023-09-07 19:41:43 <vms14       > but somehow i prefer oh to make a new list every time
2023-09-07 19:42:09 <vms14       > i can save that to a variable if i want