2023-09-18 03:27:06 <siesta      > hello guys
2023-09-18 03:27:07 <siesta      > whos online?
2023-09-18 05:38:21 <veltas      > Not me
2023-09-18 05:48:24 <dave0       > kinda
2023-09-18 06:00:27 <hello-operator> ~I am
2023-09-18 08:56:18 <KipIngram   > I'm here.
2023-09-18 09:06:10 <crc         > I'm also here now
2023-09-18 10:49:05 <KipIngram   > siesta: How've you been?  I'm on vacation this week.  :-)
2023-09-18 10:51:20 <vms14       > vacation? i thought you were retired
2023-09-18 10:51:29 <KipIngram   > No, not yet.
2023-09-18 10:52:15 <KipIngram   > Youngest daughter started college this fall - need to get her done and then I can start thinking about that.
2023-09-18 10:52:51 <KipIngram   > I suspect I'm going to like retirement quite a lot.
2023-09-18 10:53:20 <vms14       > poor keyboard
2023-09-18 10:53:21 <vms14       > hahhaha
2023-09-18 10:53:54 <vms14       > well actually typing code is not a big part of programming
2023-09-18 10:54:11 <vms14       > but i expect you will type a lot of code
2023-09-18 10:54:38 <KipIngram   > "Official" retirement age in the US is 67 these days.  I'll be 61 in January.  So by then that last daughter will be "launched" - maybe I'll just do the "standard approach."
2023-09-18 10:54:45 <vms14       > i assume it will be then when you start/focus with the operating system
2023-09-18 10:55:07 <KipIngram   > Ugh.  I hope I get some stuff done before then, but yeah - you may wind up right.
2023-09-18 11:01:53 <KipIngram   > I agree re: typing code - I've always felt that the "thinking about it phase" is quite important too.  But yeah - sooner or later you get around to needing to type.
2023-09-18 11:02:34 <KipIngram   > I don't like "figuring things out" at the keyboard - by the time I get there I want to KNOW how I'm going to do everything.
2023-09-18 11:22:04 <KipIngram   > We were talking over the weekend about run-time vs. compile-time.  The thing is, regardless of what is done at run-time, the compiler still is going to need to have an "awareness" of the types of the stuff on the stack, just in order to handle its job properly.
2023-09-18 11:22:20 <KipIngram   > I'm sure that will allow some decisions to happen at compile time.
2023-09-18 11:23:32 <vms14       > KipIngram: in my case i do figure a lot of things at the keyboard, cause i'm in a learning process and what i mainly do is to check random ideas like the ones i always expose here
2023-09-18 11:23:34 <vms14       > xd
2023-09-18 11:23:51 <vms14       > but yes, mostly i'm always thinking and taking decisions
2023-09-18 11:24:02 <KipIngram   > Yes - when you're engaged in a learning process you often want to "tinker" at the keyboard.  That's just a whole different activity.
2023-09-18 11:24:13 <KipIngram   > I was doing that over the weekend with Geogebra.
2023-09-18 11:24:38 <KipIngram   > It's really neat to be able to make those "ruler and compass" type drawings and tinker with them.
2023-09-18 11:24:49 <vms14       > but there's a lot to think before touching the keyboard
2023-09-18 11:25:05 <KipIngram   > Exactly the sort of thing you would DO with a ruler and compass in the old days, but the computer handles the tedious details.
2023-09-18 11:25:08 <vms14       > that's in part why i like so much to have a phone as my dev platform
2023-09-18 11:25:23 <vms14       > at any moment the editor is opened
2023-09-18 11:25:43 <KipIngram   > Yeah, you never know when a thought might occur to you.
2023-09-18 11:25:47 <vms14       > at any moment i can try random ideas or whatever, no matter where i am
2023-09-18 11:25:59 <vms14       > this is mainly why i wanted it
2023-09-18 11:26:32 <vms14       > emacs is open 24/7 with evil mode
2023-09-18 11:26:50 <vms14       > and in another session my abomination running in a repl
2023-09-18 11:27:13 <vms14       > https://imgur.com/a/jkkz7gI
2023-09-18 11:28:03 <vms14       > althought i guess i'll make prompt return a string instead of printing
2023-09-18 11:29:18 <vms14       > i don't have the dot word to print yet, cause i want to wrap it with stuff
2023-09-18 11:32:38 <KipIngram   > There's no law that says . has to print a number.  That's just a "Forth cultural thing."
2023-09-18 11:34:05 <KipIngram   > Like, the simple act of storing someting in a variable.  Forth calls it !, APL uses ←, other languages use =, etc.
2023-09-18 11:45:11 <vms14       > ! in scheme is also used to denote mutation
2023-09-18 11:45:50 <vms14       > and ? for predicates, where in lisp is a 'p'
2023-09-18 11:46:07 <vms14       > (number? x) (numberp x)
2023-09-18 11:47:01 <vms14       > there's a post or a list of forth conventions?
2023-09-18 11:47:20 <vms14       > http://www.forth.org/forth_style.html
2023-09-18 11:47:22 <vms14       > oh
2023-09-18 11:52:10 <vms14       > https://github.com/ForthHub/discussion/issues/73
2023-09-18 12:01:07 <KipIngram   > I really think of the explicit "customary names" as not terribly relevant.  Just choices that got made somewhere along the line.
2023-09-18 12:02:02 <thrig       > onboarding new people is trickier if your DSL is totally different
2023-09-18 12:07:16 <KipIngram   > vms14: So, once you start working with the idea that your compiler is going to have to know stack item types, then that forces you to incorporate some way of having the source code specify that.  I.e., you need to give each word an effects comment - "takes these types, makes these types."  So that will immediately complicate the language if you initially didn't need that (which you don't in Forth).
2023-09-18 12:07:55 <KipIngram   > Forth stack comments are really ideal for that, but I've never been in the habit of using them pervasively, so it would be a pretty big change for me.
2023-09-18 12:08:07 <KipIngram   > I'd have to acclimate myself to how it would change the appearance of the source code.
2023-09-18 12:10:34 <vms14       > you can infer them
2023-09-18 12:10:36 <KipIngram   > We're used to seeing those only immediately after the word name in a : definition, but really you could inject one anywhere in the code.
2023-09-18 12:11:06 <KipIngram   > so, if two paths joined up and the compiler couldnt suss out what the stack would look like there, you could "inform it."
2023-09-18 12:11:29 <KipIngram   > That's what I'm talking about here.
2023-09-18 12:11:37 <KipIngram   > You can create situations in which you can't infer them.
2023-09-18 12:11:49 <vms14       > if al words have a return type you can
2023-09-18 12:12:14 <vms14       > even if not you could
2023-09-18 12:12:20 <KipIngram   > : foo  ... IF SWAP THEN ... ;
2023-09-18 12:12:28 <KipIngram   > What's the type situation in the second ...?
2023-09-18 12:12:43 <KipIngram   > You don't know until run-time when you know whether or not the IF fired.
2023-09-18 12:13:09 <KipIngram   > Or, for that matter, just ?DUP.
2023-09-18 12:13:27 <KipIngram   > The type picture of the stack depends on which way it acts.
2023-09-18 12:13:35 <vms14       > hmm
2023-09-18 12:13:48 <vms14       > no idea how others do
2023-09-18 12:14:08 <KipIngram   > I'm just saying that in any such situation the compiler could demand that you insert a stack picture.
2023-09-18 12:14:17 <vms14       > supposedly foo would have to mark what type returns
2023-09-18 12:14:23 <KipIngram   > Or, you might need to tell it how to handle either situation.
2023-09-18 12:15:04 <KipIngram   > At run time all becomes clear, but you can't necessarily anticipate those things at compile time.
2023-09-18 12:15:17 <KipIngram   > This is  WHY you may need some run-time choice capability too.
2023-09-18 12:15:35 <KipIngram   > If you could infer EVERYTHING, then you wouldn't need any run-time choices.
2023-09-18 12:15:41 <KipIngram   > And that's "ideal."
2023-09-18 12:15:47 <vms14       > it's harder, but they do achieve type inference in compilers somehow
2023-09-18 12:15:53 <KipIngram   > But I just don't think you can assume you'll always be able to do it.
2023-09-18 12:16:25 <vms14       > but usually on those langs you specify what the function takes and returns
2023-09-18 12:16:32 <vms14       > ah no xd
2023-09-18 12:16:45 <KipIngram   > Yeah, but IF ... THEN isn't a function.
2023-09-18 12:16:53 <vms14       > well no idea how they do, i assume they have a way to follow a chain
2023-09-18 12:17:19 <KipIngram   > Or, here:
2023-09-18 12:17:36 <KipIngram   > ... SQRT <here> ...
2023-09-18 12:17:44 <vms14       > squirt here
2023-09-18 12:17:45 <KipIngram   > At <here>, is the item on the stack real or complex?
2023-09-18 12:18:15 <KipIngram   > Imagine a polynomial root solver.
2023-09-18 12:18:35 <KipIngram   > For, say, a cubic.  You know you'll have one real root, but the other two might be real or might be complex conjugates.
2023-09-18 12:19:02 <KipIngram   > You could just say you were going to treat all numbes as complex, and that will solve the problem.
2023-09-18 12:19:16 <KipIngram   > But there are downsides of that performance-wise, output readability wise, etc.
2023-09-18 12:19:23 <vms14       > supposedly if you don't change types in a variable or 'value'  you can add their type info
2023-09-18 12:20:21 <vms14       > can also keep track of their casts to other values or whatever
2023-09-18 12:20:51 <vms14       > i have no idea, compiling is something i can't talk about
2023-09-18 12:21:06 <KipIngram   > The main point I'm trying to make is that sometimes the end result depends on the VALUE of the data - not just on its type.
2023-09-18 12:21:22 <KipIngram   > Square root of a real number just isn't always a real number.
2023-09-18 12:23:27 <KipIngram   > The product of two matrices might be a matrix, or it might collapse to a scalar, depending on the dimensions of the input matrices.  Do you really want different types for every distinct dimensionality?
2023-09-18 12:24:29 <KipIngram   > A 5-row, 1-column matrix times a 1-row, 5-column matrix is a 5x5 matrix.  But a 1-row, 5-column times a 5-row, 1-column product is a NUMBER.
2023-09-18 12:25:35 <KipIngram   > Now in that case you could have a  "row vector type" and a "column vector type' and those * operations would just be different operations.  But the more you try to go to "general support" the harder it all becomes.
2023-09-18 12:27:32 <Zarutian_iPad> this is one of the things what I do not like about types,  the 'generalization' attempts that often fail miserably
2023-09-18 12:28:33 <Zarutian_iPad> the other is only typing variables, arguments and returns
2023-09-18 12:30:37 <Zarutian_iPad> here is a thing, I can have a variable that has a guard that only allows/coerces-to certain values that it can hold.
2023-09-18 12:31:42 <Zarutian_iPad> these values could themselfs by typed (having a tag or such) saying for instance that it is a ponter into a spefic ROM
2023-09-18 12:33:02 <Zarutian_iPad> I probably can go on and on
2023-09-18 12:34:58 <KipIngram   > Yes, I can imagine just typing 17+j3 and having the system know that there is now a complex value on the stack.
2023-09-18 12:35:09 <KipIngram   > This definitely applies to things that may never be stored in a variable.
2023-09-18 12:36:09 <Zarutian_iPad> another thing is operator overloading. C++ is notorious for this missuse
2023-09-18 12:36:45 <KipIngram   > Yeah, I'm pretty sure I want operator overloading.  I just want to be able to say * and have that multiply whatever the top two items on the stack are.
2023-09-18 12:36:58 <KipIngram   > Integers, floats, complex, vectors, matrices, etc.
2023-09-18 12:37:13 <KipIngram   > Chuck would strongly disapprove.
2023-09-18 12:37:53 <KipIngram   > And I understand his reasoning - for some very specific problem it's very likely I could code the whole thing more efficiently by writing "app specific" algorithms.
2023-09-18 12:38:16 <KipIngram   > He just hasn't really done a lot of work on "generic tools."
2023-09-18 12:38:25 <Zarutian_iPad> I rather go the Lua 5.4 or E way of translating such into object method calls
2023-09-18 12:38:29 <KipIngram   > He'd likely say you shouldn't even want them.
2023-09-18 12:39:17 <thrig       > later historians would come to debate whether Chuck was a historical figure or not
2023-09-18 12:39:28 <KipIngram   > It's just hard for me to imagine a FRIENDLY scientific computing package where I can't just multiply whatever's on the stack.
2023-09-18 12:39:50 <Zarutian_iPad> then again I rather dislike contemporary equations notation
2023-09-18 12:41:14 <Zarutian_iPad> when I was learning about alternating current stuff I deliverately used the MS Word equation editor to translate the equations into MathML that is used in docx
2023-09-18 12:41:16 <KipIngram   > As I go down this APL road, I don't want to be thinking about 2x2 arrays, 2x2x3 arrays, etc. - or even 2D arrays, 3D arrays, etc.  I want "arrays."
2023-09-18 12:41:35 <KipIngram   > Which means that the data structure will have to specify everything: the number of dimensions, the size in each dimension, etc.
2023-09-18 12:41:47 <Zarutian_iPad> no, you want matrixes
2023-09-18 12:41:51 <KipIngram   > And the algorithms will have to use that information to know what to do.
2023-09-18 12:42:00 <veltas      > KipIngram: Rather than invoking the name of Chuck, I will say the Forthy way to do this is to have * etc be whatever the most app-appropriate def of * is
2023-09-18 12:42:14 <veltas      > i.e. don't use generic names, name things for the current app
2023-09-18 12:42:16 <KipIngram   > Yes.
2023-09-18 12:42:26 <veltas      > And that doesn't require not having generic code
2023-09-18 12:42:41 <veltas      > But you might need some kind of renaming maybe to make things nicer
2023-09-18 12:42:41 <KipIngram   > No doubt about that -  Forth would say that I need to know what my data looks like and CHOOSE the specific word that is right for that case.
2023-09-18 12:43:03 <KipIngram   > * F* C* dot* cross* M* etc.
2023-09-18 12:43:09 <veltas      > So I could have Forth use * for matrices if it made sense, by doing : * MATRIX* ;
2023-09-18 12:43:24 <veltas      > And I've made a dialect
2023-09-18 12:43:46 <veltas      > But tomorrow I do something where I don't want * as matrices, well if it's a different app it doesn't need the same names
2023-09-18 12:43:49 <KipIngram   > I know.  I guess my whole point is that I just don't regard that approach as adequate for the sort of general scientific environment I'm wanting.
2023-09-18 12:43:58 <Zarutian_iPad> having an algorythm 'know what to do' is an ask, like in the 'Dont ask, tell' principle, which is to me an design/code smell. (Having something asking what something else is and changing the behaviour based on that)
2023-09-18 12:44:12 <KipIngram   > But i am thinking about a general tool, and not a program for any one specific application.
2023-09-18 12:44:50 <KipIngram   > Chuck would tell me that I shouldn't write such a tool.  I should wait until I'm faced with a specific problem and then solve that problem.
2023-09-18 12:44:55 <veltas      > 'Forth' as most of us know it is itself a general tool and not application-specific
2023-09-18 12:45:03 <veltas      > Although it certainly does some apps better than others
2023-09-18 12:45:17 <veltas      > I hope you wanted a dot matrix printed report and command line data entry
2023-09-18 12:45:32 <Zarutian_iPad> yeah, but having an objsys where the 'arrays', 'matrixes' are objects makes more sense to me
2023-09-18 12:45:38 <KipIngram   > That's probably one reason Chuck winds up writing much more compact code.  I think his whole thought process is in that "case specific mode."
2023-09-18 12:46:45 <KipIngram   > If you think about it, though, this is the whole reason we all have operating systems on our computer to start with.
2023-09-18 12:46:58 <KipIngram   > so we can readily chase after a lot of different problems.
2023-09-18 12:47:47 <Zarutian_iPad> hmm... I think Chuck is more like an MCU programmer than anything else
2023-09-18 12:47:54 <KipIngram   > Zarutian_iPad: to me an "object" is something that sits in RAM.
2023-09-18 12:48:05 <KipIngram   > I want to be able to type in a literal vector or matrix.
2023-09-18 12:48:37 <KipIngram   > I think sometimes when I use these terms I'm not being as specific as a computer scientist might be.
2023-09-18 12:48:52 <KipIngram   > to some extent i do think of these things as objects.
2023-09-18 12:49:14 <KipIngram   > When I type in a literal vector, I see that as an "object" that gets put on a heap with a pointer to it on the stack.
2023-09-18 12:49:36 <KipIngram   > And if I then type *, well, it's going to use that info in the heap to figure out what to do - that feels like a "method" to me.
2023-09-18 12:49:45 <Zarutian_iPad> KipIngram: what you typed in gets allotted into RAM and then if nothing refers to it at the end of the calculation, gets gc'ed
2023-09-18 12:49:46 <KipIngram   > That literal vector would have a "method" named *.
2023-09-18 12:49:56 <KipIngram   > Yes.
2023-09-18 12:50:03 <KipIngram   > One way or another.
2023-09-18 12:50:31 <KipIngram   > I'm just not promising that I use terms like "object" and "method" and so on in what might be considered a strictly correct way, by a purist.
2023-09-18 12:51:23 <Zarutian_iPad> in that objsys I described I do not have a vtable like in c++ or such. Just an xt that gets the method invocation and can decide which method to use based on the selector, etc
2023-09-18 12:52:06 <KipIngram   > But to make that decision it's going to need SOMETHING LIKE a table or something SOMEWHERE.
2023-09-18 12:52:14 <Zarutian_iPad> basically using the same-ish idea that CREATE and DOES> are
2023-09-18 12:52:17 <KipIngram   > The decision information has to be placed somewhere.
2023-09-18 12:53:06 <KipIngram   > And when I type a 'literal somethin' directly into the system, the system has to be able to decide what that thing is, so that it can associate the right type info with it.
2023-09-18 12:53:20 <Zarutian_iPad> in a jumptable in the code that the xt points to. This allows for more flexibility and possible composition of traits
2023-09-18 12:53:50 <KipIngram   > I don't think we're disagreeing.
2023-09-18 12:53:56 <KipIngram   > We're just talking past each other.
2023-09-18 12:54:27 <Zarutian_iPad> or it can be a one if statement that handles a particular method and delegates the rest to another word
2023-09-18 12:56:15 <Zarutian_iPad> hmm... usually what I have seen regarding using types is there often is something like js`typeof(a) == "number"` or js`instanceof(specimen, constructor)` used as part of a condition of an if statement
2023-09-18 12:57:40 <Zarutian_iPad> that approach is brittle as hell
2023-09-18 13:00:45 <Zarutian_iPad> how Lua does operator overloading or how the numerical tower in Scheme/CommonLisp does the same is worth looking at as ideamine
2023-09-18 13:02:19 <thrig       > jenga tower
2023-09-18 13:20:12 <KipIngram   > Generally speaking I'd expect "performance" and "brittleness" to go together, and I'm just now sure yet exactly where I want to land.  "High performance, zero brittleness" is unlikely to exist.
2023-09-18 13:20:59 <Zarutian_iPad> there are enough ambious pzumas in the world already
2023-09-18 13:21:13 <KipIngram   > When a human being works problems like the ones I'm thinking about by hand, we just gracefully morph from one type to another in whatever way makes sense.   But computers can't just "know to do" such things - one way or another they have to be told.
2023-09-18 13:21:49 <KipIngram   > I'm not "choosing" or "ruling out" any specific way of doing that yet.
2023-09-18 13:21:53 <heath       > why does 3 2 1 swap swap result in 1 2 3 in gforth? 3 2 1 dup nip makes more sense to me
2023-09-18 13:22:15 <KipIngram   > It wouldn't.
2023-09-18 13:22:21 <KipIngram   > It would result in 3 1 2
2023-09-18 13:22:36 <heath       > 3 2 1 swap swap . . . 1 2 3  ok
2023-09-18 13:22:57 <KipIngram   > Oh, I was describing the "stack," not the output you'd get from . . .
2023-09-18 13:23:08 <heath       > Ah, that's where I'm confused
2023-09-18 13:23:09 <KipIngram   > 3 1 2 . . . would print 2 1 3
2023-09-18 13:23:30 <KipIngram   > Usually when you write a Forth stack state you put deeper items to the left, items nearer the top to the right.
2023-09-18 13:23:47 <KipIngram   > : SWAP  ( a b -- b a) ... ;
2023-09-18 13:24:12 <KipIngram   > Anything deeper than the stuff shown in such a "stack effect comment" is just left unaffected.
2023-09-18 13:25:49 <heath       > That helps, thank you
2023-09-18 13:25:58 <KipIngram   > Sure thing.
2023-09-18 13:26:32 <KipIngram   > Your Forth may have a .s word that prints the whole stack, and it will likely print it the way I described, deeper left, shallower right.
2023-09-18 13:26:58 <heath       > yeah, I do see that
2023-09-18 13:27:42 <heath       > I'm trying to come up with a one liner for creating a stack state of 3 2 1 and then reversing it. That's my end goal. I'm hoping it doesn't take me an entire day to do this :)
2023-09-18 13:28:13 <KipIngram   > :-)
2023-09-18 13:28:35 <KipIngram   > Look into words OVER and ROT and -ROT.  Shouldn't take you too long.
2023-09-18 13:29:06 <heath       > 3 2 1 dup swap nip (pretty sure that's it)
2023-09-18 13:29:27 <KipIngram   > dup swap doesn't actually do anthing more than just dup.
2023-09-18 13:29:37 <KipIngram   > The swap will be swapping two equal items.
2023-09-18 13:29:51 <KipIngram   > Then nip will just discard one of them.
2023-09-18 13:29:55 <heath       > oh, I keep getting confused with the `.`
2023-09-18 13:30:05 <KipIngram   > So dup swap nip does nothing at all.
2023-09-18 13:30:09 <heath       > .s shows <3> 3 2 1
2023-09-18 13:30:23 <heath       > looking into rot and -rot
2023-09-18 13:30:50 <KipIngram   > You'll get it.  I'm refraining from helping - you're trying to learn here, so I'll leave the experience for you.  :-)
2023-09-18 13:33:16 <thrig       > viking swimming lessons
2023-09-18 13:41:24 <heath       > 3 2 1 -rot swap (seems to have done it)
2023-09-18 13:43:46 <heath       > 3 2 1 (.s <3> 3 2 1 ok) -rot swap (.s <3> 1 2 3 ok)
2023-09-18 13:51:03 <KipIngram   > Nice.
2023-09-18 13:51:37 <KipIngram   > You get good at such dances with some practice.
2023-09-18 13:51:48 <KipIngram   > you start to just get a "feel" for it all.
2023-09-18 13:52:19 <KipIngram   > Of course, in a real Forth program you'd try to write earlier code so that you didn't need something like that - plan it so the numbers wind up the way you want them.
2023-09-18 13:52:32 <vms14       > it's funny cause supposedly being good at stack manipulation means you are a bad forthwright
2023-09-18 13:52:47 <KipIngram   > It does send a mixed signal, yes.
2023-09-18 13:53:04 <KipIngram   > You should be good at stack noodling, but then again you shouldn't NEED to be good at it.
2023-09-18 13:53:44 <KipIngram   > If I had to guess I'd say most people's experience curve took them through the "good at noodling" phase on their way to "don't need to noodle."
2023-09-18 13:54:02 <vms14       > heath: how it is going your forth experience?
2023-09-18 13:54:18 <vms14       > it's cool to see people interested in forth
2023-09-18 13:56:16 <vms14       > this reminds me about similar stuff when the novice uses the simplest option cause it is the simpler, while others do elaborate tricks and alike, and at the end the pro chooses to do the same as the novice because it is the simplest option
2023-09-18 13:56:50 <vms14       > he does not need to show anyone what he knows
2023-09-18 13:57:30 <vms14       > i kind of like it, cause i try to avoid "smart code"
2023-09-18 13:58:32 <vms14       > i prefer to code like a noob even when an option is shorter, cause this option does not give any benefit and makes reading more difficult as a novice can't understand it
2023-09-18 13:59:08 <vms14       > but i like to learn shorter ways to do stuff and use them
2023-09-18 14:27:53 <heath       > vms14: it's fun! I have To Mock a Mockingbird lying around, and I'd like to go through that with gforth, but first, I'm reading the info pages
2023-09-18 14:41:17 <veltas      > There are certain patterns that you see a lot and learn and get more proficient with regarding the stack
2023-09-18 15:39:06 <vms14       > and you can always make your own words
2023-09-18 15:39:17 <vms14       > actually you are encouraged to do that
2023-09-18 15:48:09 <veltas      > The info pages for gforth are actually alright
2023-09-18 15:48:26 <veltas      > heath: Also get the latest version of gforth, it's not available on most distros
2023-09-18 15:48:32 <veltas      > If yours says 0.7.3 it's not the latest
2023-09-18 15:48:58 <veltas      > Although having 0.7.3 installed is a prerequisite for building the latest
2023-09-18 15:49:04 <veltas      > seems to be anyway
2023-09-18 15:51:51 <veltas      > https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/
2023-09-18 16:01:50 <veltas      > I'm getting close to being able to share a Forth I've written over the last week or so
2023-09-18 17:16:29 <vms14       > :O
2023-09-18 17:17:44 <vms14       > that server has modperl mod python and ph
2023-09-18 17:17:48 <vms14       > php
2023-09-18 17:18:11 <vms14       > veltas: you never talk about your forth :/
2023-09-18 17:31:12 <thrig       > the first rule of forth club...
2023-09-18 17:31:31 <Zarutian_iPad> ...is beeing retro?
2023-09-18 17:35:39 <vms14       > it's you don't talk about your forth
2023-09-18 17:40:48 <veltas      > I've got one for the ZX Spectrum but I've been writing one for x86 recently
2023-09-18 17:44:13 <vms14       > are you going to document it?
2023-09-18 17:45:05 <veltas      > Well first I need to write it, but I'm almost at a state where it's worth sharing the in-progress code
2023-09-18 23:39:38 <KipIngram   > This is apt to sound a little loony, but I'm starting to think maybe there's some kind fo a fusion possible here between the array related stuff I've been talking about and Wildberger's rational number emphasis and the projective geometry way of looking at things that lets one clear fractions.  I'm starting to think maybe I could do some very general computing using just arrays of integers.
2023-09-18 23:40:35 <KipIngram   > Practically speaking, the projective stuff "jumps you up a dimension."  to do a two-dimensional analysis, you use three dimensions - the third one absorbs what would be the "constants" in the 2D equations and is key to allowing the integer representation for everything.
2023-09-18 23:40:48 <KipIngram   > A 3D analysis would involve 4D geometry.
2023-09-18 23:41:11 <KipIngram   > So it's like you "pay" by taking on an additional dimension, but you get all kinds of benefits from doing so.