2022-05-30 09:01:45 <lopata      > hello fellow forthers
2022-05-30 09:02:58 <lopata      > I find somthing is illogical in forth conditional syntax
2022-05-30 09:03:26 <lopata      >  since forth logic is : each word interpret  what is before
2022-05-30 09:03:50 <lopata      > following this logic : it must have been :
2022-05-30 09:04:00 <lopata      > -1 IF ." false " ELSE ." true " THEN
2022-05-30 09:04:06 <lopata      > what do you think ?
2022-05-30 09:07:40 <Zarutian_HTC> lopata: forth doesnt have 'conditional' syntax
2022-05-30 09:09:28 <Zarutian_HTC> what forth does when interpreting text input is read a word (characters to next space), tries to look it up in the dictionary, and if that fails tries to interpret that as a number
2022-05-30 09:09:51 <lopata      > I mean the branching would have been made IF " false else " <= ELSE " true then " <= THEN
2022-05-30 09:11:21 <Zarutian_HTC> that flips the meaning around and precludes IF ... THEN constructs
2022-05-30 09:12:17 <lopata      > why so, its as illogical as the opposite
2022-05-30 09:13:33 <lopata      > and such on we could have been the possibility to reverse ELSE and THEN : IF (true) THEN (false) ELSE
2022-05-30 09:13:34 <Zarutian_HTC> you are probably confusing it with the ?: trinary operator from C and other Algol68 syntax languages
2022-05-30 09:14:21 <lopata      > probably
2022-05-30 09:15:31 <Zarutian_HTC> besides, iirc in many forth : IF ' 0=branch , HERE @ 0 , ; IMMEDIATE
2022-05-30 09:16:57 <Zarutian_HTC> : ELSE ' (jmp) , HERE @ 0 , SWAP ; IMMEDIATE
2022-05-30 09:17:10 <Zarutian_HTC> damn
2022-05-30 09:18:15 <Zarutian_HTC> : ELSE ' (jmp) HERE @ 0 , SWAP HERE @ SWAP ! ; IMMEDIATE
2022-05-30 09:19:06 <Zarutian_HTC> : THEN HERE @ SWAP ! ; IMMEDIATE
2022-05-30 09:21:41 <Zarutian_HTC> as you see the 0=branch word is what does the condutional branching
2022-05-30 09:22:14 <lopata      > ok
2022-05-30 09:22:18 <Zarutian_HTC> s/dut/dit/
2022-05-30 09:22:34 <lopata      >  so I could modify it !
2022-05-30 09:23:21 <Zarutian_HTC> so you would need a kind of INVERT in front of it or make a 0!=branch word
2022-05-30 09:23:33 <lopata      > niice thx
2022-05-30 09:24:07 <Zarutian_HTC> though that INVERT only inverts the bits of the TOS
2022-05-30 09:26:50 <Zarutian_HTC> : ?: ( cond conseq alt -- conseq | alt ) ROT SKZ SWAP DROP ;
2022-05-30 09:27:51 <Zarutian_HTC> SKZ is SKip if Zero btw
2022-05-30 09:30:31 <Zarutian_HTC> : SKZ orAllBits INVERT 1 AND R> + >R ;
2022-05-30 09:33:58 <Zarutian_HTC> bbl
2022-05-30 09:34:05 <dave0       > lopata: it's usually like    condition IF is-true ELSE is-false THEN      after you do is-true or is-false (but never both) it continues after the THEN
2022-05-30 09:35:06 <dave0       > it's different to basic which does    IF condition THEN is-true ELSE is-false ENDIF
2022-05-30 09:35:07 <lopata      > -1 IF ." false " ELSE ." true " THEN
2022-05-30 09:35:41 <lopata      > -1 IF ." true " THEN ." false " ELSE
2022-05-30 09:36:01 <lopata      > could be in forth preceding style
2022-05-30 09:36:12 <lilo_booter > normally, the condition closes with the THEN
2022-05-30 09:36:26 <dave0       > if that makes sense to you, you can certainly change forth to do it that way :-)
2022-05-30 09:37:07 <lilo_booter > i think it would force you to always supply both ELSE and THEN - a simple condition IF .. THEN wouldn't be supported
2022-05-30 12:04:52 <KipIngram   > lopata: You could arrange Forth's conditional stuff to work any way you wanted it to.  The typical operation is just what has "appeared" over the years.  But if you think about it, the structure that we use is pretty logical.  There is an opportunity to branch at IF, and there is a requirement to branch at ELSE, if you want to run either one block of code or the other.  It makes sense to me that the block
2022-05-30 12:04:53 <KipIngram   > following the IF would be the "if true" code, so the other block would then need to be the "if false" code.  <condition> if true: <true code>, otherwise <false code> seems sensible to me.
2022-05-30 12:05:35 <KipIngram   > So, I see what you're saying - IF actually branches on false, so if you think about the BRANCHING it seems backwards.  But if you think about the code blocks that get executed, it makes sense.
2022-05-30 12:06:26 <KipIngram   > The location of the THEN is a little odd compared to other languages, but in Forth it just "closes the whole thing out."
2022-05-30 12:06:45 <KipIngram   > <condition> IF <do this> ELSE <do this> THEN <move on>.
2022-05-30 12:07:26 <KipIngram   > THEN could easily have been named END or something, or FI like in bash, or whatever.
2022-05-30 12:08:14 <thrig       > ENDIF, OTHERWISE, ...
2022-05-30 12:08:32 <KipIngram   > In other languages the conditional test itself follows the IF, but Forth's RPN nature makes it sensible to put it before.
2022-05-30 12:09:40 <KipIngram   > The existing approach pretty much arose from "what is the simplest way to do this?"
2022-05-30 12:10:08 <thrig       > some have acused Moore of "savage minimalism"
2022-05-30 12:10:39 <KipIngram   > Indeed.  :-)
2022-05-30 12:10:49 <KipIngram   > I think he's grown more and more that way over the years.
2022-05-30 12:12:30 <KipIngram   > It's probably good that SOMEONE is exploring that path.
2022-05-30 12:12:46 <KipIngram   > Even if it leads to places a lot of us won't follow, it's still worth investigating.
2022-05-30 12:12:53 <thrig       > him, and those people living on their boat in the Pacific without much power
2022-05-30 12:13:48 <KipIngram   > I read somewhere that Israel always funds at least some investigation of the "crazy options" on things, just in case.
2022-05-30 12:14:19 <KipIngram   > I imagine a lot of countries do that, without talking much about it.
2022-05-30 12:14:33 <KipIngram   > A minimal amount of investigations even into things most folks think won't work.
2022-05-30 12:15:05 <KipIngram   > Like NASA has done wome research on that "Woodward EM drive," even though most scientists say it can't work because if it did it would violate conservation of momentum.
2022-05-30 12:15:19 <eris[m]     > thrig: 100rabbits
2022-05-30 12:15:25 <KipIngram   > s/wome/some/
2022-05-30 12:16:38 <KipIngram   > Woodward thinks that charging and discharging his capacitors affects their mass.  So the idea is to push against them while they're massive, and pull them back while they're less massive, and produce some net thrust.
2022-05-30 12:16:46 <KipIngram   > With no propellant ejection.
2022-05-30 12:17:15 <KipIngram   > It kind of seems clear to me that it either doesn't work or doesn't work enough.  But it still gets kicked around.
2022-05-30 12:17:30 <thrig       > bulging capacitors usually spells trouble
2022-05-30 12:17:49 <KipIngram   > No doubt.  The last phone I had to discard had that happen.
2022-05-30 12:17:55 <KipIngram   > Cracked the circuit board.
2022-05-30 12:18:21 <KipIngram   > To its credit, Google replaced it with a better phone than the original.
2022-05-30 12:18:48 <thrig       > ... and we are here to *clap* pump you up
2022-05-30 12:18:57 <KipIngram   > Though I had deliberately bought a Nexus, because they supposedly have the "cleanest" Android, and it got replaced with a non-Nexus.
2022-05-30 12:20:21 <KipIngram   > That Woodward stuff is at least interesting - gets into some far out physics on the nature of inertia and so on.  Mach's principle, etc.
2022-05-30 12:21:21 <KipIngram   > It does feel to me, though, that if it were going to pay off in any major way it would have done so by now.  They still argue over whether it works AT ALL - one lab will report net thrust, and the next lab can't replicate it.
2022-05-30 12:21:52 <thrig       > star trek timeline is looking pretty shakey
2022-05-30 12:22:04 <KipIngram   > I think what they need to do to put it to bed one way or the other is actually test it in space.
2022-05-30 12:22:15 <KipIngram   > The controversy is always around "undetected lab effects" tainting the results.
2022-05-30 12:22:26 <KipIngram   > So stick one out there where there aren't any such effects, and let's see.
2022-05-30 12:22:40 <thrig       > *any such effects that we know of
2022-05-30 12:23:03 <KipIngram   > Fair enough, though if it worked for any reason in space that would be interesting.
2022-05-30 12:23:26 <KipIngram   > And yeah, that poor trek timeline.  :-(
2022-05-30 12:23:37 <KipIngram   > They've got a warp drive program too.
2022-05-30 12:23:53 <KipIngram   > https://en.wikipedia.org/wiki/Alcubierre_drive
2022-05-30 12:27:54 <siraben     > GOL in APL in Forth https://github.com/chmykh/apl-life/blob/master/apl-life.fs
2022-05-30 12:40:48 <lagash      > siraben: yup! found that one through https://discu.eu/weekly/apl/2022/21/
2022-05-30 12:42:22 <lopata      > re!
2022-05-30 12:45:52 <lopata      > KipIngram,  IF false ELSE true THEN...  is bteer according to be than  IF true ELSE false THEN...
2022-05-30 12:46:55 <lopata      > because it follows the preceding logic, also than final Then is weird, so th ELSE has to follow the same reverse logic
2022-05-30 12:48:13 <lopata      > Im trying to implement it inverting the 0=Branch, problem : now IF  ... THEN is inverted
2022-05-30 13:15:20 <KipIngram   > Well, it's easy to make it that way, if you like.  Just reverse the jump conditional.  That's one of the nice things about Forth - it's easy to "have it your way."
2022-05-30 13:16:44 <KipIngram   > It's certainly possible that I gravitate toward the common method simply BECAUSE it's common and I've become used to it.
2022-05-30 13:16:54 <lopata      > yes I reversed jz => jnz, but IF THEN (without else) is reverse
2022-05-30 13:17:31 <KipIngram   > Well, yes - the stuff in THEN ... ELSE is... optional.
2022-05-30 13:17:56 <lopata      > ok.
2022-05-30 13:18:00 <KipIngram   > So you want it one way in the single clause case and the other way in the dual clause case?
2022-05-30 13:18:44 <KipIngram   > IF and THEN have no idea whether an ELSE clause even exists or not.
2022-05-30 13:19:15 <KipIngram   > You could arrange for THEN to know, I guess, but there's no way for IF to know what's coming further down the code stream.
2022-05-30 13:20:08 <lopata      > exactly
2022-05-30 13:22:32 <lopata      > Ill redefine IF to be ELSE...  ELSE ... THEN will be normal condition
2022-05-30 13:23:04 <lopata      > >_<
2022-05-30 13:31:52 <lopata      > can someone explain IF ' 0=branch , HERE @ 0 , ; IMMEDIATE
2022-05-30 13:32:29 <lopata      > thats definition Zarutian gave earlier for : IF
2022-05-30 13:37:11 <KipIngram   > So, IF doesn't know where it's going to need to jump TO.
2022-05-30 13:37:25 <KipIngram   > So it just allocates a spot for that jump target to go, and leaves a pointer to it on the stack.
2022-05-30 13:38:15 <KipIngram   > Either THEN or ELSE, whichever comes first, can tell where the jump target should be.  So it takes that target address and uses the pointer to "backpatch" the jump instruction that IF built the skeleton of.
2022-05-30 13:39:01 <KipIngram   > That's all THEN has to do, but ELSE also has an unknown jump target, so it backpatches the IF jump and builds the skeleton of an unconditional jump, leaving a pointer to its target slot on the stack.  Then later THEN will backpatch THAT one.
2022-05-30 13:39:35 <KipIngram   > So, IF builds a jump skeleton and leaves a pointer.  THEN backpatches a skeleton, using that pointer.  ELSE does both of those things.
2022-05-30 13:39:41 <KipIngram   > Does that make sense?
2022-05-30 13:40:06 <KipIngram   > HERE is getting the pointer to where the jump target, acquired later, will need to be stored to complete the skeleton.
2022-05-30 13:40:25 <lopata      > alright
2022-05-30 13:40:51 <KipIngram   > In some systems a control flow "code" is also left on the stack; later words can confirm that code is there and if it's absent they can throw a syntax error
2022-05-30 13:40:55 <lopata      > complicated
2022-05-30 13:40:59 <KipIngram   > Like if you had THEN without a preceding IF.
2022-05-30 13:41:14 <KipIngram   > Well, it's a bit tedious, but conceptually it's extremely simple.
2022-05-30 13:41:22 <KipIngram   > It's a great application of the stack data structure.
2022-05-30 13:41:58 <KipIngram   > Some languages probably use multiple passes over the source to do such things - first pass builds the skeletons, a later pass fills in the targets.
2022-05-30 13:42:15 <KipIngram   > By doing it the way it does, Forth can do the job in a single pass.
2022-05-30 13:42:31 <KipIngram   > I actually can't think of a simpler way to do it.
2022-05-30 13:42:37 <lopata      > very well done!
2022-05-30 13:43:46 <KipIngram   > Backward jumps work in a somewhat similar way - for example, in BEGIN ... AGAIN, BEGIN uses HERE to note the starting point of the loop, and AGAIN uses that value to compile its jump instruction.
2022-05-30 13:43:48 <Zarutian_HTC> well, I have written an assembler, in js, that used promises for symbols defined later
2022-05-30 13:44:48 <Zarutian_HTC> similar idea but way more mechanism to implement it in the runtime
2022-05-30 13:44:54 <KipIngram   > Yeah, I guess you could use data structures other than the stack to achieve these things - a symbol table of some kind.
2022-05-30 13:45:14 <KipIngram   > The stack is just a simple way, and as long as conditionals and loops are properly "nested" it all works out fine.
2022-05-30 13:46:00 <Zarutian_HTC> what of DO and LOOP ? how are they implemented?
2022-05-30 13:47:22 <Zarutian_HTC> does DO do the exact same thing as BEGIN ?
2022-05-30 13:47:56 <Zarutian_HTC> no, I think do adds a jump with a hole to patch
2022-05-30 13:51:42 <Zarutian_HTC> : DO ' (jmp) , HERE @ ; IMMEDIATE : LOOP DUP HERE @ SWAP ! CELL+ ' (next) , , ; IMMEDIATE
2022-05-30 13:53:04 <Zarutian_HTC> so DO THEN pretty much 'comments out' a block of code
2022-05-30 13:55:17 <Zarutian_HTC> sorry s/' (jmp)/' >R , ' (jmp)/ because I forgot the loop counter
2022-05-30 13:55:50 <KipIngram   > Yes, DO has to mark the beginning of the loop, and it compiles a run-time that sets up the counter and limit stuff on the return stack.
2022-05-30 13:56:03 <Zarutian_HTC> so the construct the would be DO ... THEN R> DROP
2022-05-30 13:56:24 <KipIngram   > LOOP and +LOOP use/update the return stack data to decide whether to jump back or not, and also clean off the return stack to end the loop.
2022-05-30 13:56:36 <KipIngram   > Or something like that.
2022-05-30 13:56:55 <Zarutian_HTC> ah, I only seen the variant of (next) that counts down
2022-05-30 13:57:03 <KipIngram   > One might implement a special (LOOP) runtime primitive that does it all faster.
2022-05-30 13:57:14 <KipIngram   > But it could be done in Forth, of course.
2022-05-30 13:57:54 <Zarutian_HTC> like my earlier definition of SKZ today
2022-05-30 13:58:18 <KipIngram   > But it's always the same - for backward jumps the first word just leaves a target address for the later jump; for forward jumps the first word compiles a skeleton that has to be "completed" by the later word that has the information needed to finish it out.
2022-05-30 13:58:27 <KipIngram   > All the rest is just "variations."
2022-05-30 13:58:43 <Zarutian_HTC> for when somebody forgot to provide you with an conditional branch primitive
2022-05-30 14:03:39 <KipIngram   > :-)
2022-05-30 14:04:02 <KipIngram   > Well, I guess I think of it as overlaying "structured programming" methods onto that basic conditional branch.
2022-05-30 14:04:43 <KipIngram   > That's why the stack method of implementing it works - you can nest those structures, but you can't "overlap them."  But overlapping them would be violating all kinds of structured programming guidance.
2022-05-30 14:05:17 <KipIngram   > BEGIN ... IF ... AGAIN ... THEN
2022-05-30 14:05:20 <KipIngram   > No workee.
2022-05-30 14:06:13 <KipIngram   > That's the kind of thing adding those "codes" to the process covers - AGAIN would find an incorrect code, because the IF buried the code that BEGIN left.
2022-05-30 14:07:21 <Zarutian_HTC> these are control flow structures we been talking about
2022-05-30 14:07:28 <KipIngram   > Without the extra checks that might actually compile something, but it wouldn't be anything you'd want.
2022-05-30 14:08:20 <KipIngram   > Without the error checks, I guess AGAIn would compile a jump into the middle of the conditional jump skeleton IF laid down.
2022-05-30 14:08:58 <Zarutian_HTC> when I started to think about how to do gui and gfx in forth I saw I needed some sort of object system
2022-05-30 14:09:06 <KipIngram   > And THEN would try to backpatch a skeleton that didn't exist, at the location BEGIN noted on the stack.  So it might compile with  no error and no stack imbalance, but it would vomit when you ran it.
2022-05-30 14:09:53 <KipIngram   > I don't actually have any of these structures in my current system.
2022-05-30 14:10:20 <KipIngram   > I've found the conditional returns / recursions obviate the need for them.
2022-05-30 14:10:27 <Zarutian_HTC> you use conditional early return instead?
2022-05-30 14:10:32 <KipIngram   > Yes.
2022-05-30 14:11:01 <KipIngram   > I went kind of hog wild on that front - I've got conditional return and conditional recurse primitives for pretty much every flavor of condition, default 0 argument, signed / unsigned, etc.
2022-05-30 14:11:06 <KipIngram   > A big pile of primitives.
2022-05-30 14:11:15 <KipIngram   > I wrote a Python script to generate their source.
2022-05-30 14:11:47 <KipIngram   > But "the one I want" is always there when I go looking for it, and they're named in a very structured way so it's easy to remember them all.
2022-05-30 14:12:13 <Zarutian_HTC> re obj sys: what I came up with was basically each object was laid out in memory as: header xt refsPart dataPart
2022-05-30 14:12:49 <KipIngram   > Oh, OO stuff?
2022-05-30 14:13:04 <Zarutian_HTC> the *Parts are zero to many cells in size, sizes kept in the header
2022-05-30 14:13:38 <Zarutian_HTC> not object oriented, as there is class hierarchy
2022-05-30 14:13:55 <Zarutian_HTC> there is no class hierarchy
2022-05-30 14:14:14 <KipIngram   > I see.  Yeah, the headers offer a lot of potential.  I haven't actually added anything to mine - they're pretty minimal, but I've "contemplated" a number of things that could go there.
2022-05-30 14:14:59 <Zarutian_HTC> the xt of each object points to a word implementing the 'methods' of the object
2022-05-30 14:15:25 <KipIngram   > Right.
2022-05-30 14:15:52 <KipIngram   > Something like a switch?  Selector passed on the stack?
2022-05-30 14:16:15 <Zarutian_HTC> basically stealing that idea from CREATE DOES>
2022-05-30 14:16:54 <KipIngram   > But I guess there's more than one action that might be taken, right?
2022-05-30 14:17:01 <KipIngram   > A "set of methods"?
2022-05-30 14:17:03 <Zarutian_HTC> the stack on method invocation ( ... verbSelector ptr2obj )
2022-05-30 14:17:09 <KipIngram   > Got it.
2022-05-30 14:17:32 <KipIngram   > I like calling them verbs.  :-)
2022-05-30 14:17:44 <Zarutian_HTC> so either a switch, jump table or series of ifs
2022-05-30 14:18:09 <Zarutian_HTC> terminology from E (erights.org)
2022-05-30 14:19:22 <Zarutian_HTC> means I can do transparent forwarders, object-decorators, etc
2022-05-30 14:21:13 <Zarutian_HTC> plus the switches wont be big, I foresee about dozens of methods per object kind
2022-05-30 14:23:34 <Zarutian_HTC> one common object interface in gfx is the one for pixmaps: getWidth ( -- w ), getHeight ( -- h ), getPoint ( x y -- colour ), putPoint ( colour x y -- )
2022-05-30 14:25:08 <Zarutian_HTC> which means I can do transforms via transform objects that each just point to a pixmap compatible thing and remembers a few parameters
2022-05-30 14:25:26 <KipIngram   > That sounds pretty cool.
2022-05-30 14:26:31 <Zarutian_HTC> translation, up and down scaling, sheering/slanting
2022-05-30 14:27:05 <Zarutian_HTC> and using three of the last of that enumeration, rotation
2022-05-30 14:29:24 <Zarutian_HTC> plus compositions such as using a mask to select betwixt the foreground or background pixmap, basically blitting
2022-05-30 14:30:49 <Zarutian_HTC> tilemaps using tileset which is basically an array of pixmap references
2022-05-30 14:31:04 <Zarutian_HTC> subrects too
2022-05-30 14:31:26 <Zarutian_HTC> oh and paletted images in same vane
2022-05-30 14:32:04 <Zarutian_HTC> but I do not expect it to be fast though
2022-05-30 14:33:05 <Zarutian_HTC> fast enough for vnc based gui though
2022-05-30 14:34:17 <KipIngram   > Yeah, image stuff is a good target application for that sort of methodology.
2022-05-30 14:34:30 <KipIngram   > Makes a lot of sense.
2022-05-30 14:36:52 <Zarutian_HTC> on top of this or to its side, the bresenham drawing primitives
2022-05-30 14:38:28 <Zarutian_HTC> and then using all that, the idea is to implement Themed Toolkit from Tcl/Tk
2022-05-30 14:40:21 <Zarutian_HTC> probably simplest to start with the old X windows Motif theme that MicroSoft is aping nowdays, or some elements of MacOS 9 and earlier
2022-05-30 14:47:05 <Zarutian_HTC> btw tilemaps are not only useful for game kind of stuff but also displaying bitmap font based text
2022-05-30 15:46:09 <KipIngram   > I think it's a great example of pulling together an "application lexicon," just like best Forth practices calls for.
2022-05-30 20:05:11 <Zarutian_HTC> one idea I heard was to establish a Forth libraries, commented code that is meant for reading and not blind loading like in other programming languages
2022-05-30 20:06:37 <Zarutian_HTC> a bit like application notes and example usage in electronics