2022-06-20 02:32:26 <eris[m]     > as established, it runs on uxn/varvara, a virtual machine
2022-06-20 02:43:10 <siraben     > Zarutian_HTC: when was this written?
2022-06-20 04:35:27 <lopata      > do Templates exist in forth ?
2022-06-20 04:36:38 <lopata      > I guess not because in C its written from the compiler
2022-06-20 04:37:44 <lopata      > I m looking to build a Template T <Builds Does> that acts object's style
2022-06-20 04:41:35 <eris[m]     > templates are generic programming
2022-06-20 04:41:42 <eris[m]     > as in, programming that works independent of data type
2022-06-20 04:42:12 <eris[m]     > why do you need templates?
2022-06-20 04:50:00 <lopata      > I would like to have a definition of <Builds Does> generic
2022-06-20 04:51:19 <lopata      > so one can use "template" T < > with any word but with a common set of "commands"
2022-06-20 04:52:23 <lopata      > one must just type myB USE T ... or myB RES T
2022-06-20 04:53:11 <lopata      > but one can also define myA with the same Template and do myA USE T similary
2022-06-20 04:57:17 <lopata      > < myA myB > COMPARE T
2022-06-20 05:10:15 <eris[m]     > how are builds and does not generic?
2022-06-20 05:10:57 <eris[m]     > sounds like you're approaching forth wrong, if im being honest
2022-06-20 05:11:08 <eris[m]     > what are you actually trying to do?
2022-06-20 05:16:17 <lopata      > a super-<builds does> : T  that acts like an object
2022-06-20 05:16:48 <lopata      > with generic commands myObjectB USE T
2022-06-20 05:17:38 <eris[m]     > but why do you want objects
2022-06-20 05:17:47 <lopata      > (would execute the definition of DOES)
2022-06-20 05:21:18 <lopata      > for re-useable
2022-06-20 05:23:31 <lopata      > Instead of rewritting CReate stuff 3 times, one could just instantiate a single BUILDS DOES template and reuse the set of commands
2022-06-20 05:25:04 <lopata      > I ve 2 similar objects that needs the same extention of the a RESET definition so its needs to be rewritten for each Build
2022-06-20 05:25:18 <eris[m]     > but why are you using so many builds and does
2022-06-20 05:25:28 <eris[m]     > you're writing OO code in a non OO language
2022-06-20 05:29:28 <lopata      > Yeah you prbly right, I'll extend the forth language, well see
2022-06-20 05:35:46 <eris[m]     > why?
2022-06-20 05:36:07 <eris[m]     > whats wrong with doing things the forth way?
2022-06-20 07:59:57 <lopata      > ok.
2022-06-20 08:00:07 <lopata      > I reask my question
2022-06-20 08:02:04 <lopata      > Templates-like <Builds Does>
2022-06-20 08:02:29 <lopata      > that acts like objects
2022-06-20 08:03:17 <lopata      > with a default method USE that executes
2022-06-20 08:03:45 <eris[m]     > why are you trying to do OO in forth?
2022-06-20 08:04:15 <veltas      > lopata: Can you give a more fleshed out demo of what this would look like in pastebin or something?
2022-06-20 08:04:34 <veltas      > Probably what you're asking can be done with IMMEDIATE words and POSTPONE or something
2022-06-20 08:05:04 <eris[m]     > yea ^
2022-06-20 08:05:36 <lopata      > OO is needed for re-using a <builds does> definition with specific Method for 2 differents "objects"
2022-06-20 08:06:35 <lopata      > So one coult write ObjA USE T   ... would executes the Obja T based class template
2022-06-20 08:07:10 <veltas      > Can you explain how this is different from DOES> ?
2022-06-20 08:08:28 <eris[m]     > but why do you need objects is what im saying
2022-06-20 08:10:02 <lopata      > USE would be similar to Does> but it would have other methods such as RES or COMPARE
2022-06-20 08:10:14 <veltas      > Some people like them, multiple major Forth implementations come with OOP libraries, I'm not going to judge
2022-06-20 08:10:27 <veltas      > lopata: So instead of DOES> which gives you just the one method, you want more than one method?
2022-06-20 08:10:44 <lopata      > so one could compare vector objects with User implemented COMPARE methdo
2022-06-20 08:11:04 <eris[m]     > but like
2022-06-20 08:11:19 <eris[m]     > you could just write a compare method for vectors yourself
2022-06-20 08:11:23 <eris[m]     > without the overhead
2022-06-20 08:11:26 <lopata      > ie : objA USE T    objB RES T     < objA objB > Compare T
2022-06-20 08:13:33 <lopata      > yeah but it would be simpler to have a specific "class" T  that can be used Postfix to agree to its methods
2022-06-20 08:15:01 <lopata      > one makes a <BUIlDS DOES> definition
2022-06-20 08:15:04 <eris[m]     > would it?
2022-06-20 08:15:20 <lopata      > Template myT
2022-06-20 08:15:33 <lopata      > myT USE DOES> ...
2022-06-20 08:15:38 <eris[m]     > or are you trying to save yourself typing two characters at the cost of an entire object system
2022-06-20 08:16:45 <lopata      > myT RES DOES> ....
2022-06-20 08:16:57 <lopata      > < myT obj1 >
2022-06-20 08:17:03 <veltas      > I still don't understand specifically what you're asking for
2022-06-20 08:17:04 <lopata      > obj1 USE myT
2022-06-20 08:17:36 <veltas      > Please give a full example using this, without stuff <bracketed out>, and link to it on pastebin or something
2022-06-20 08:17:44 <lopata      > the ability to define multiple DOES methods for a single object
2022-06-20 08:18:08 <veltas      > I'm not going to guess and write code for something you don't want
2022-06-20 08:18:59 <veltas      > Maybe have a look at https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Basic-OOF-Usage.html#Basic-OOF-Usage
2022-06-20 08:19:03 <lopata      > not asking for code, just want some thought about iut
2022-06-20 08:19:44 <veltas      > For me code is the thinking
2022-06-20 08:20:09 <veltas      > 9 times out of 10 anyway
2022-06-20 08:26:18 <lopata      > it's sort of that in the link but with DOES> methods
2022-06-20 08:26:54 <lopata      > an unspecified Type object could be declared and use one class or another USE method
2022-06-20 08:27:21 <lopata      > undtermined Obj
2022-06-20 08:29:28 <lopata      > is it a plane is it a bird is it superMan ?
2022-06-20 08:30:05 <lopata      > FlyTrajectory USE PLANE
2022-06-20 08:33:01 <lopata      > but then it could be reused :  Flight USE FlyTrajectory USE PLANE
2022-06-20 08:54:50 <lopata      > well that's it! a DOES> method redefinition at no cost
2022-06-20 10:52:02 <KipIngram   > Different categories of words in Forth are differentiated by having different code that is triggered when you execute them.  Basically that code is passed a parameter - the "parameter field address" of the specific individual word that was run that led to that code being executed.  The code is the same for all members of that category, but each has its own PFA.  So : definitions have a particular bit of
2022-06-20 10:52:04 <KipIngram   > "handling" code, variables have something different, constants something else, etc.
2022-06-20 10:52:26 <KipIngram   > BUILD/DOES> allows you to create a word in which you specify that "handling functionality" using Forth instead of using machine code.
2022-06-20 10:53:03 <KipIngram   > And I've found that it usually involves "hacking" the core design very slightly - especially in direct threaded systems.  It's somewhat easier to put together in indirect threading.
2022-06-20 10:53:27 <KipIngram   > But that's how I think of the difference: machine code being triggered vs. Forth code being triggered.
2022-06-20 10:54:23 <KipIngram   > Nothing stops you from writing DOES> code that uses additional stack parameters - you could have a parameter specify an item from a list of possible functions.
2022-06-20 10:55:01 <KipIngram   > And then use some kind of conditiona structure / switch functionality to let that parameter select the actual code to execute.
2022-06-20 10:55:29 <KipIngram   > That said, I've really never had a need to do anythiing like that - there's almost always a simpler way to do whatever it is I'm trying to do.
2022-06-20 10:55:44 <KipIngram   > It's awfully rare for me to use BUILD/DOES>.
2022-06-20 10:55:45 <Zarutian_HTC> something like CASE or some such
2022-06-20 10:55:49 <KipIngram   > Right.
2022-06-20 10:56:18 <KipIngram   > The parameter field address gets put on the stack automatically when you execute the word.
2022-06-20 10:56:35 <KipIngram   > So variables don't need to "do" anything extra - that address is precisely the result they want to return.
2022-06-20 10:56:38 <Zarutian_HTC> I did not see <BUILDS and DOES> in eForth which I am most familiar with
2022-06-20 10:56:55 <KipIngram   > Early on it was called CREATE/DOES>
2022-06-20 10:57:34 <Zarutian_HTC> i think both were omitted from eForth for some reason or other
2022-06-20 10:57:57 <KipIngram   > What kind of threading is eForth?
2022-06-20 10:58:16 <Zarutian_HTC> indirect iirc
2022-06-20 10:58:30 <Zarutian_HTC> nl
2022-06-20 10:58:34 <Zarutian_HTC>  no
2022-06-20 10:58:49 <KipIngram   > I've never written a "seriously complete" code threaded Forth, but I have done both direct and indirect, and I found BUILD/DOES> to be a pain in the ass in the direct threaded system.  Felt very klunky and hacky.
2022-06-20 10:59:06 <Zarutian_HTC> the x86 version uses jsr docolon in colon words
2022-06-20 10:59:45 <Zarutian_HTC> followed by the colon definition list of words
2022-06-20 11:00:55 <Zarutian_HTC> I take that both <BUILDS and DOES> are immediate words, no?
2022-06-20 11:02:27 <KipIngram   > I've thought a LITTLE about OO in Forth, and it seemed to me that for part of it you'd like to be able to use ANY defining word as the "starting point, so that you could make "modifications" of other things.  But I never saw any really clean way of doing that.  Even that first step of BUILD/DOES> is slightly cumbersome, and it just gets worse.  Plus you'd lose performance with each additional level.
2022-06-20 11:02:48 <KipIngram   > Something like
2022-06-20 11:02:59 <KipIngram   > : foo build ... does> ... ;
2022-06-20 11:03:02 <KipIngram   > And then
2022-06-20 11:03:10 <KipIngram   > : bar foo ... does> ... ;
2022-06-20 11:03:22 <KipIngram   > : bam bar ... does ... ;
2022-06-20 11:03:42 <KipIngram   > And you'd somehow want that to behave sensibly, and I never saw any clean way of putting it all together.
2022-06-20 11:03:44 <Zarutian_HTC> I see, I think you have fallen into the inheritence trap of OO
2022-06-20 11:03:53 <KipIngram   > Yes, exactly.
2022-06-20 11:04:05 <KipIngram   > That was the part of it I was trying to suss out, and largely failed.
2022-06-20 11:04:28 <Zarutian_HTC> I dispense with that completely
2022-06-20 11:04:37 <KipIngram   > Sounds wise.  :-)
2022-06-20 11:04:56 <Zarutian_HTC> I rather use composition than inheritence
2022-06-20 11:04:58 <KipIngram   > I lost interest in it when it proved to be so "un-graceful."
2022-06-20 11:05:17 <eris[m]     > doing most parts of OO in general feels like a mistake esp in forth
2022-06-20 11:05:22 <KipIngram   > I just decided it wasn't something Forth was oriented toward.
2022-06-20 11:06:09 <KipIngram   > I agree with that.  I eventually decided it just wasn't a path to pursue.
2022-06-20 11:06:28 <KipIngram   > It's not like I really "knew what I was doing" in the general OO arena anyway.
2022-06-20 11:06:30 <Zarutian_HTC> in the object system I described here some weeks ago, an object is made up of four things: the header, the xt, the refs part, and the data part
2022-06-20 11:07:33 <Zarutian_HTC> the xt just points to the method invocation handler code for that kind of object
2022-06-20 11:08:05 <KipIngram   > The BUILD parts - those stacked together fairly well.  Simple to have that first word allocate what it allocates, and then allocate some more.
2022-06-20 11:08:16 <KipIngram   > It's the DOES> chaining that doesn't work out nicely.
2022-06-20 11:08:25 <Zarutian_HTC> which is a bit like how DOES> defined code gets control
2022-06-20 11:15:45 <Zarutian_HTC> hmm : <BUILDS compile (BUILDS) HERE @ 0 , ; immediate : DOES>  compile EXIT HERE @ SWAP ! ; immediate : (BUILDS) CREATE R> dup cell+ >R @ , ; \ i think
2022-06-20 11:17:03 <Zarutian_HTC> though it leaves the address of the built word on the return stack and not on the data stack
2022-06-20 11:19:27 <Zarutian_HTC> btw this assumes an canonical dual stack machine arch from Koopmans book
2022-06-20 11:20:02 <Zarutian_HTC> but should work on eForth x86 too I think
2022-06-20 11:22:19 <Zarutian_HTC> : DOES> compile EXIT HERE @ SWAP ! compile R> ; immediate \ should fix that
2022-06-20 11:25:03 <Zarutian_HTC> for my object system I am thinking of <MAKES or <CONSTRUCTS but I like the former more
2022-06-20 11:29:12 <Zarutian_HTC> : <MAKES ( -- objptr ) ... ;
2022-06-20 11:30:10 <Zarutian_HTC> s/thinking of/thinking of using/
2022-06-20 11:30:25 <Zarutian_HTC> oprah'ed a whole word there
2022-06-20 11:32:13 <Zarutian_HTC> due to garbage collection objptr should only be saved in objects' refs part or the obj_root variable and no where else
2022-06-20 11:33:26 <Zarutian_HTC> gc is btw ever only called explictly and not triggered by memory pressure
2022-06-20 11:34:31 <Zarutian_HTC> in an event loop system it is good idea to call gc at the end of an event loop turn (or at every x such)
2022-06-20 12:44:38 <lispmacs[work]> hi, I was just curious if there where any
2022-06-20 12:44:43 <lispmacs[work]> Forth programmers here
2022-06-20 12:44:49 <lispmacs[work]> who are Factor programmers also
2022-06-20 16:05:33 <veltas      > lispmacs[work]: Do you program in it or after support?
2022-06-20 16:08:14 <lispmacs[work]> I haven't tried Factor yet, just curious about it
2022-06-20 16:08:55 <lispmacs[work]> and what Forth users think of it
2022-06-20 16:11:49 <veltas      > Fair enough
2022-06-20 16:11:57 <veltas      > Can't say I've tried it