2025-01-04 00:33:21 <KipIngram   > I have no real idea what the design was.  I would expect that it would have chips on it that we actually wrote to and the outputs of which went to our circuits.  That way if we burned one out that chip could just be replaced.  If I were doing it I'd socket those.
2025-01-04 00:34:12 <thrig       > usb ain't good at surviving wiring errors
2025-01-04 00:34:36 <KipIngram   > This was WAY before USB.
2025-01-04 00:35:06 <KipIngram   > This was pre-IBM PC.
2025-01-04 00:35:30 <thrig       > lots of dell monitors and keyboard with burned out ports in an EE lab that used arduinos and had folks poking around with meters
2025-01-04 00:35:57 <KipIngram   > MrMobius: I'd just "buffer everything" that was going to make electrical contact with "user circuitry."
2025-01-04 00:36:43 <MrMobius    > right. I thought about opto coupling if you dont need speed
2025-01-04 00:37:33 <MrMobius    > but I was never sure if the chip would burn out reliably like a fuse or instead malfunction in some other way that would damage the system
2025-01-04 01:34:12 <xentrac     > optocouplers are pretty reliable at not passing voltage or current through, and they can be pretty quick
2025-01-04 03:13:14 <pgimeno     > curiously, the Jupiter allows IF ... ELSE ... ELSE ... THEN, and so does gforth, is that a feature of the language or just a bug?
2025-01-04 03:15:47 <xentrac     > it's codified in the standard: https://forth-standard.org/standard/core/IF
2025-01-04 03:16:52 <pgimeno     > oh I see, but I didn't see it in Forth-79 which the Jupiter claims to follow
2025-01-04 03:17:10 <pgimeno     > I guess it's just allowed
2025-01-04 03:17:17 <xentrac     > yeah, I'm not sure if Forth-79 requires it in an implicit way or not
2025-01-04 03:18:17 <xentrac     > I'm guessing not
2025-01-04 05:00:22 <KipIngram   > I'm just thinking about what ELSE normally does, and it doesn't seem exactly straightforward to me to have multiple of them.  What's the operational action supposed to be?  It seems like there would have to be another IF in there somewhere.
2025-01-04 05:01:38 <KipIngram   > And if that's the case then it seems like it would just be nested IF ... ELSE ... THEN structures, which is no problem.
2025-01-04 12:25:59 <KipIngram   > When there is one ELSE, THEN patches an address just prior to the ELSE with its own address.  Would it have to know where all of the ELSE's were if there were more than one?  Or just the last one?  If the last, then I gess each ELSE would patch the previous ne's address, and it feels like you'd get some kind of multi-jump execution.
2025-01-04 12:40:37 <GeDaMo      > Else only does the last one
2025-01-04 12:41:10 <GeDaMo      > I like this section of the standard on the control flow stack https://forth-standard.org/standard/rationale#paragraph.A.3.2.3.2
2025-01-04 14:57:07 <veltas      > pgimeno: First I've heard of it, I had assumed it needs e.g. IF .. ELSE .. IF .. ELSE .. THEN THEN
2025-01-04 14:57:45 <veltas      > It is certainly possible to support BOTH syntaxes, but adds a lot of unnecessary and unwanted complexity
2025-01-04 14:58:11 <veltas      > e.g. one THEN is required for every IF
2025-01-04 15:00:22 <pgimeno     > well, not a lot of complexity actually; in the case of the jupiter, the IF pushes a code for IF, and the ELSE and the THEN both check for it. The only necessary action is for ELSE to push a different code, and for THEN to recognize either of both; that way only one ELSE would be allowed
2025-01-04 15:02:00 <veltas      > I said to support BOTH syntaxes
2025-01-04 15:02:06 <pgimeno     > ah
2025-01-04 15:03:10 <pgimeno     > not much more anyway, the ELSE would just need to decide whether to push the code for IF or the code for itself
2025-01-04 15:03:37 <veltas      > In Forth terms this is basically like writing an OS from scratch :P
2025-01-04 15:05:08 <pgimeno     > wow
2025-01-04 15:05:31 <pgimeno     > I can write a short(ish) Forth implementation for the Jupiter as a PoC if you wish
2025-01-04 15:05:53 <veltas      > In a standard Forth you can usually write:  IF W1 ELSE W2 ELSE W3 THEN , and I think it would execute either W1 W3 or W2
2025-01-04 15:06:49 <pgimeno     > that's right
2025-01-04 15:07:01 <pgimeno     > that's what the Jupiter does, and it's Forth-79
2025-01-04 15:07:43 <pgimeno     > I can write an implementation of ELSE and THEN (the IF doesn't need to be modified) that only allows for one ELSE
2025-01-04 15:08:18 <pgimeno     > and making it optional
2025-01-04 15:15:49 <veltas      > What I mean is it's equivalent to  IF W1 W3 ELSE W2 THEN
2025-01-04 15:16:06 <veltas      > In a standard Forth that doesn't think too hard about it
2025-01-04 15:19:49 <KipIngram   > veltas: It feels to me also like it would add complexity.
2025-01-04 15:21:04 <KipIngram   > In your example, why wouldn't I just write IF W1 W3 ELSE W2 THEN ?
2025-01-04 15:21:37 <KipIngram   > I wouldn't see adding complexity to allow an alternate form of that as a win.
2025-01-04 15:27:51 <KipIngram   > The conditional before the IF just returns one bit of information, so I don't see how more than two options make any logical sense.
2025-01-04 15:32:03 <zelgomer    > i don't think there is a practical or desirable use case for this, it's just documenting a behavioral quirk of the typical implenentation
2025-01-04 15:33:56 <pgimeno     > KipIngram: the implementation of ELSE and THEN naturally allows multiple ELSEs and does the right thing
2025-01-04 15:35:48 <pgimeno     > think about it from the low level standpoint: the IF sets up a branch and pushes an IF indicator; the ELSE checks for the IF indicator, adds a branch, patches the IF to branch just past it, and pushes an IF indicator
2025-01-04 15:36:12 <pgimeno     > the THEN checks the IF indicator and patches the last branch to point here
2025-01-04 15:38:15 <pgimeno     > allowing a single ELSE would require to modify that logic to making ELSE push an ELSE indicator instead of an IF indicator, and making THEN accept either an IF indicator, or an ELSE indicator
2025-01-04 15:55:38 <veltas      > I think the dumb standard non-chaining version is a little simpler, and uses less RAM on a mainframe, so I can see why they didn't bother with this extension
2025-01-04 15:55:46 <veltas      > On a ROM it's a no-brainer, if there's room
2025-01-04 15:56:11 <veltas      > You can't win anything by shaving a few bytes off a ROM that comes in sizes like 4KB/8KB/16KB etc
2025-01-04 15:59:23 <veltas      > The Guardian only seems to publish articles about astronomical events *after* they happen, and with details on how to see the event ... had you a time machine and can go back and see it
2025-01-04 16:03:01 <KipIngram   > pgimeno: I do see that, but I see no usefulness at all in the behavior.
2025-01-04 16:03:39 <KipIngram   > I think that's made most clear by the limitation of the conditional clause to a single bit of information.  That makes two code paths useful, but not more.
2025-01-04 16:04:04 <KipIngram   > Once you choose one of the two paths, you've exhausted your information.
2025-01-04 16:04:10 <veltas      > Well the code you write is less cluttered and easier to read, assuming it allows IF/ELSE/IF/ELSE/THEN ?
2025-01-04 16:05:13 <KipIngram   > I'd think you'd need IF/ELSE/IF/ELSE/THEN/THEN, but I haven't really cogitated on the potential for a single THEN to cover all the open structures.  I can readily imagine cases when you wouldn't want it to.
2025-01-04 16:05:23 <veltas      > But as I would point out, extra THEN's don't increase the size of a binary, so there's no disadvantage to having to write THEN multiple times, other than shorter and more readable source code
2025-01-04 16:05:31 <KipIngram   > Right.
2025-01-04 16:17:21 <KipIngram   > Having one THEN clear multiple structures would, in the usual implementation, require it to dig into and make assumptions about the content of the stack, since each nested IF would have left the usual stack record docuenting its work.  Seems like that might require more assumptions / smarts than the alternative.
2025-01-04 16:17:53 <amby        > i wouldnt want THEN to close multiple conditionals
2025-01-04 16:18:13 <amby        > if you have lots of nested if/else then write a new conditional structure
2025-01-04 16:18:14 <KipIngram   > Usually it checks to make sure that what's on the stack qualifies as an IF setup - in this case it would need to be able to say "I'm SURE this is an additional IF."
2025-01-04 16:18:18 <KipIngram   > amby: Me either.
2025-01-04 16:19:08 <KipIngram   > Seems to me you'd need to pick a "magic number" which you promised not to have on the stack except when IF was in play.
2025-01-04 16:19:18 <KipIngram   > Lots of extra hoops, no real gain.
2025-01-04 16:19:43 <KipIngram   > Since as veltas points out, additional THENs cost nothing in the runtime.
2025-01-04 16:31:07 <veltas      > I think the main reason I don't want it is I lose ability to put something between what would be consecutive THEN's
2025-01-04 16:43:13 <KipIngram   > Yes - precisely.
2025-01-04 16:43:29 <KipIngram   > That's also why I said above I could imagine cases where you didn't want THEN to do that.
2025-01-04 16:44:56 <KipIngram   > I'd personally never run into a situation like that - I'm 100% sure I'd factor so that the nested IFs weren't in the same definition.  And if IF is in a particular definition, then there needs to be a THEN in there too, or the compiler will throw an error.
2025-01-04 16:45:05 <KipIngram   > And I don't really use IF ... THEN anymore anyway.
2025-01-04 16:45:27 <KipIngram   > I'd factor the body into a word of its own and put a conditional return at the start of it.
2025-01-04 16:46:51 <KipIngram   > For IF ELSE THEN there would be two factored words - first would call the second, and the second would either conditionally return to the first or run and then exit via a double return ;;
2025-01-04 16:48:49 <KipIngram   > : if_false  0!=; <false case> ;;
2025-01-04 16:48:51 <KipIngram   > : if_true  if_false <true case> ;
2025-01-04 16:48:53 <KipIngram   > ... <make flag> if_true ...
2025-01-04 16:50:03 <KipIngram   > That's just one of several "standard templates" I've grown accustomed to using.
2025-01-04 16:51:21 <KipIngram   > I don't wind up needing IF ELSE THEN functionality very often, though.  Usually just IF THEN covers me.
2025-01-04 18:08:05 <xentrac     > KipIngram: as veltas said, a if b else c else d then runs b d if a is true and c otherwise, precisely because (as you and pgimeno said) each else patches the previous one's address.  the standard page I linked sort of explains this but not very well
2025-01-04 18:09:51 <pgimeno     > yes, my point is that not supporting multiple ELSEs costs more than supporting them
2025-01-04 18:13:48 <xentrac     > I agree
2025-01-04 18:13:52 <KipIngram   > Well, I wouldn't "make an effort" not to support them.
2025-01-04 18:14:00 <KipIngram   > If they came for free I'd not have a problem with that.
2025-01-04 18:14:05 <xentrac     > (but that still doesn't explain why the standard requires them to do this)
2025-01-04 18:14:07 <KipIngram   > I just wouldn't go out of my way to get it.
2025-01-04 18:14:23 <KipIngram   > No, it doesn't, and I still maintain it adds no value to the language.
2025-01-04 18:15:02 <pgimeno     > xentrac: probably because it was widely supported enough as to some users depending on it
2025-01-04 18:15:54 <xentrac     > I suppose, but I don't know why you would ever write a if b else c else d then instead of a if b d else c then
2025-01-04 21:07:15 <veltas      > I think I was confused by the premise of this whole thing, unfortunately there are a lot of 'syntax errors' that aren't checked
2025-01-04 21:07:56 <veltas      > When I say Forths don't normally support more ELSE's, I meant the hypothetical aggregation of if/else/if/else/then
2025-01-04 21:08:14 <veltas      > So I think everyone's actually in agreement