00:00:00 --- log: started forth/21.06.05
00:27:46 --- join: epstein joined #forth
00:43:47 --- join: Glider_IRC_ joined #forth
00:46:43 --- quit: Glider_IRC__ (Ping timeout: 248 seconds)
00:55:59 --- join: morbidb1rd joined #forth
00:58:52 --- quit: epstein (Ping timeout: 252 seconds)
01:18:01 --- join: neuro_sys_ joined #forth
01:46:37 --- quit: morbidb1rd (Remote host closed the connection)
01:46:57 --- join: morbidb1rd joined #forth
02:10:07 --- quit: morbidb1rd (Remote host closed the connection)
02:11:22 --- join: epstein joined #forth
02:16:38 --- quit: epstein (Remote host closed the connection)
02:16:59 --- join: epstein joined #forth
02:18:39 <cbridge_> <amirouche> > jonesforth: check
02:19:02 <cbridge_> <amirouche> > POL: check
02:56:29 <cbridge_> <siraben> amirouche: POL?
02:56:46 <cbridge_> <siraben> jonesforth is fantastic
02:57:20 <neuro_sys_> POL: Problem Oriented Language
02:57:46 <neuro_sys_> Similar to jonesforth, there's also itsyforth.
02:58:06 <neuro_sys_> Every line commented, and 1K.
02:58:14 <neuro_sys_> 1KB*
03:54:26 <cbridge_> <amirouche> ty
03:56:54 --- join: morbidb1rd joined #forth
03:59:35 --- quit: epstein (Ping timeout: 258 seconds)
04:08:15 <cbridge_> <amirouche> What is the `input buffer` ?
04:08:32 <cbridge_> <amirouche> such as in: : - ( -- ) define a new Forth word, taking the name from the input buffer
04:09:10 --- quit: morbidb1rd (Ping timeout: 258 seconds)
04:09:42 --- join: epstein joined #forth
04:16:54 <cbridge_> <amirouche> oh input buffer is merely an address :/
04:19:53 <cbridge_> <amirouche> some other Forth (I think jonesforth) rely on WORD.
05:06:35 --- join: morbidb1rd joined #forth
05:07:43 --- quit: epstein (Ping timeout: 260 seconds)
05:22:43 --- join: rtdos joined #forth
05:22:43 --- join: proteanthread joined #forth
05:25:43 --- part: rtdos left #forth
05:25:44 --- part: proteanthread left #forth
05:26:38 <cbridge_> <amirouche> itsyforth: check
05:27:52 --- join: epstein joined #forth
05:31:38 --- quit: morbidb1rd (Ping timeout: 260 seconds)
06:32:37 <mark4> i dont like jonesforth x4 was here first and he is stealing allmy street cred :P
06:33:13 <mark4> worse. he does not hang out in here :P
06:41:11 <cbridge_> <amirouche> mark4 what is your forth?
06:58:34 --- quit: epstein (Ping timeout: 252 seconds)
07:00:41 --- join: epstein joined #forth
07:15:35 <mark4> x4 :)
07:15:57 --- quit: epstein (Quit: Leaving)
07:15:59 <mark4> and t4 and more recently x64 but that is not really complete yet
07:19:51 <cbridge_> <amirouche> url?
07:20:03 <mark4> sorry github.com/mark4th
07:20:21 <cbridge_> <amirouche> btw, are any of you active on forth-standard.org?
07:21:01 <mark4> what is it?
07:21:28 <cbridge_> <amirouche> I added x64 to my watch and feedreader (sorry, no star, because I do not want to scare my co-workers)
07:21:37 <cbridge_> <amirouche> https://forth-standard.org/
07:21:40 <cbridge_> <amirouche> idk..
07:22:01 <cbridge_> <amirouche> seems like a forum for forth... standard effort. not sure it is official or something.
07:22:04 <mark4> not a fan of the ans forth stnadard :)
07:22:12 <mark4> think they limp wristed a bunch of stuff 
07:24:43 <cbridge_> <amirouche> "Lunar Mission One Ambassador" only seens on for forthHub (https://github.com/ForthHub/discussion/issues/92)
07:36:32 --- join: wineroots joined #forth
07:38:18 <cbridge_> <amirouche> Again one forther : "After all I wrote it just for the hack value."
07:42:08 <cbridge_> <amirouche> I guess that is a regular Forth saying: "- As this Forth is more easily portable than most other Forths, having
07:42:11 <cbridge_> <amirouche>   to use another Forth system first before you can use this package,
07:42:14 <cbridge_> <amirouche>   would seriously hinder its usefulness.
07:42:14 <cbridge_> <amirouche> "
08:03:13 <cbridge_> <amirouche> (re my-coworker: sorry!)
08:20:37 --- join: proteanthread joined #forth
08:20:42 --- join: rtdos joined #forth
08:36:19 <mark4> do you code forth at work?
09:42:05 <cbridge_> <amirouche> no, that is the problem :)
09:42:59 <cbridge_> <amirouche> IMO, they have a very limited view of what computing is, and anything that is top5 of TIOBE is "theorical"
10:16:33 <veltas> mark4, amirouche: forth-standard.org is official but their version of the standard is really outdated now
10:16:58 <veltas> I don't know if they're going to 'release' another standard any time, reminds me of the sad state of the gforth websites
10:17:48 <mark4> well i never liked gforth
10:17:55 <mark4> never liked any forth written in c
10:18:36 <veltas> Real forthers don't use C and only eat rare meat
10:19:31 <veltas> When a real forther orders Indian he orders the Phall every time
10:20:33 <veltas> amirouche: I tried looking at the forth standard efforts and joined the mailing list but it's extremely tedious
10:20:44 <cbridge_> <nihilazo> REAL forthers use a j1 as their main CPU
10:20:50 <cbridge_> <nihilazo> and write their own entire OS from scratch
10:21:03 <veltas> It's only followed by certain kinds of people, and it's unsurprising to me how poor the additions of standard Forth have been over the years
10:21:23 <veltas> It sounds harsh but really you need to bully committees
10:21:29 <cbridge_> <nihilazo> why not C btw
10:21:38 <cbridge_> <nihilazo> like, I understand that forth should be written mostly in forth
10:21:42 <mark4> ans forth is a cammel.  a horse designed by a committee
10:21:45 <cbridge_> <nihilazo> but you need something non-forth before you start writing forth in forth
10:22:07 <cbridge_> <nihilazo> does a real forth have to start with asm in your opinion? or what
10:22:20 <mark4> yes in my opinion
10:22:24 <cbridge_> <Zarutian_HTC> machine code!
10:22:28 <mark4> all primitives should be hand coded in asm
10:22:35 <mark4> not compiled by a c compiler
10:22:53 <veltas> Why would Forth, a language that's characteristically low-level, rely on a systems language for bootstrapping and generally other functionality. I think that's the logic.
10:23:09 <mark4> if you are writing a forth in C you are not banned here :)
10:23:18 <mark4> i just dont like forths that are not written in FORTH
10:23:25 <veltas> I sort of agree but I'm (shelved) writing a C Forth. I don't think there's anything inherently wrong with it
10:23:54 <veltas> But then there is the attitude of gforth people who say "why bother writing optimizer when GCC exists, why write your own ALLOCATE when gdb malloc() exists"
10:24:10 <veltas> And then I wonder "why bother using Forth at all if you don't care"
10:24:25 <cbridge_> <Zarutian_HTC> 
ACTION only writes a small vm in c for forth to run ontop of

10:24:55 <veltas> I do not understand the gforth people at all, they're not doing anything illegal but I just don't understand why they even care about Forth given their other motivations
10:25:31 <veltas> My own C Forth the aim was to use C as the 'portable assembly' for the kernel and then do as much as possible like a real Forth, and implement as much as possible in Forth itself.
10:25:38 <veltas> That makes a bit more sense I think
10:25:59 <veltas> There are the kernel words, and then you mmap a large fixed region of memory and just play with it in Forth
10:26:27 <veltas> And then writing it in C I can also easily provide support for FFI
10:26:53 <veltas> If you want to do stuff like OpenGL or whatever C libraries you need to do stuff that's simply not possible otherwise
10:28:51 <mark4> i was doing an android native forth that fully supported JNI which means it had a built in java FFI and calling C functions from forth also is not that difficult
10:29:13 <mark4> linking the libraries just means implementing the same hooks C would have in the same way
10:29:15 <mark4> but with forth
10:29:56 <mark4> unfortunately google ripped the rug out from under me and that necessitated an rm -rf . and a start from scratch lol
10:29:58 <veltas> I can't really even remember why I wanted to do it with C, other than it being more portable
10:30:05 <veltas> I mean there are more computers than AMD64
10:30:21 <mark4> ya
10:30:28 <veltas> It's not unrealistic that I'd want to use a RISC V or ARM machine in the next decade
10:30:30 <cbridge_> <nihilazo> 
ACTION regularly uses an ARM computer

10:30:34 <mark4> my not liking it does not invalidate it :)
10:30:44 <cbridge_> <Zarutian_HTC> and another thing is that many 'why dontcha just write it in c?' folks do not realize is that there might not even exists a c compiler backend for the targetted architecture or that the code emitted is buggy
10:31:01 <cbridge_> <nihilazo> that's true especially of older platforms
10:31:07 <cbridge_> <nihilazo> I would never write C for a 6502
10:31:11 <mark4> also. theres no reason why a forth written in forth cannot be targeted to a new arch
10:31:17 <cbridge_> <nihilazo> bc the compilers I know all kinda suck
10:31:33 <veltas> Zarutian_HTC: That's more true with embedded, but I'm more interested in systems Forth
10:31:45 <mark4> just have your compiler compile byte code that is then assembled into opcodes for the specific arch being built for
10:32:01 <mark4> you dont rerally NEED c to do that.. but erm... might be faster to use C :)
10:32:02 <veltas> nihilazo: 8-bit is notoriously difficult to compile for
10:32:26 <veltas> The best C compiler output is worse than your worst assembly programmer's work
10:32:34 <mark4> you just need a set of rules similar to how a peephole optimier works
10:32:57 <veltas> For 8-bit?
10:33:14 <mark4> for any
10:33:21 <mark4> for each arch you are building for
10:33:40 <veltas> Stuff like a "peephole optimizer" works better for sensible architectures, no 8-bit architecture is sensible
10:33:53 <mark4> avr is pretty neat
10:34:03 <mark4> and actually 8051 was very simple to develop for
10:34:05 <cbridge_> <Zarutian_HTC> veltas: yebb, but ?Radon? cisc or Cybrek risc based processors show up in various electronics nearing 'systems' level
10:34:11 <mark4> very clean opcode map
10:34:14 <veltas> Yes I was going to say except 8051
10:34:26 <veltas> I forgot what it was called
10:34:51 <mark4> yea well its kind of almost completely dead now :)
10:35:05 <mark4> tho i suspect the DDC ace chip is an 8051 internally
10:35:48 <mark4> oh msp-430 is also a completely orthagonal instruction set
10:35:53 <mark4> so thats probably nice and clean too
10:36:14 <mark4> you want screwed up arch try nec 75x :)
10:39:21 <cbridge_> <Zarutian_HTC> then there are the soft-cores such as J1 and other Koopman's book inspired ones
10:41:02 <cbridge_> <Zarutian_HTC> been looking into one sketch of a design that has partial reconfiguration of the fpga depending on the 'mode' of the application
10:42:50 <cbridge_> <Zarutian_HTC> a bit like application specialized dsp/vector-acceloration/what-have-you
10:44:50 --- quit: cbridge_ (Remote host closed the connection)
10:45:04 --- join: cbridge_ joined #forth
10:45:38 <cbridge_> <Zarutian_HTC> lets say you are doing image processing by applying a convolutional artifical neuronal network followed by somolov baysian inferance
10:47:25 <cbridge_> <Zarutian_HTC> your silicon estate either baloons on one chip or you end up with multichip affair with bottlenecking interconnects
11:06:11 --- quit: rtdos (Read error: Connection reset by peer)
11:06:12 --- quit: proteanthread (Read error: Connection reset by peer)
11:11:33 --- join: rtdos joined #forth
11:11:33 --- join: proteanthread joined #forth
12:43:43 --- join: Glider_IRC__ joined #forth
12:46:54 --- quit: Glider_IRC_ (Ping timeout: 252 seconds)
13:06:38 --- quit: Bogen85 (Read error: Connection reset by peer)
13:06:42 --- join: Bogen85_0 joined #forth
13:06:48 --- nick: Bogen85_0 -> Bogen85
13:07:03 --- mode: ChanServ set +v Bogen85
13:31:18 <veltas> What would a stackly-typed language look like?
13:33:03 <cbridge_> <remexre> I think words are typed from stack to stack, something row-polymorphism-looking for the stack types
13:33:29 <cbridge_> <remexre> maybe dependent types to handle the common pointer+length pattern (as seen in e.g. TYPE)
13:36:30 --- quit: gravicappa (Ping timeout: 258 seconds)
13:46:06 <mark4> each item on the stack also includes a type indicator with it?
14:05:37 <cbridge_> <remexre> you could do the one I'm envisioning purely at compile-time, I think
14:06:24 --- quit: neuro_sys_ (Remote host closed the connection)
14:41:54 <cbridge_> <KipIngram> Afternoon folks.
14:42:02 <cbridge_> <KipIngram> Are we talking type stack?
14:42:31 <cbridge_> <KipIngram> I've thought about that a few times.  One long term goal is to have an environment that I can use similarly to Octave (vectors, matrices, etc.)
14:42:47 <cbridge_> <KipIngram> I think a compile time type stack and a smart compiler is the way to get there.
14:43:28 <cbridge_> <KipIngram> It will necessitate somehow telling the compiler what each word does, though in a lot of cases it might be able to figure it out itself, so long as the pre-existing words have effects defined.
14:45:28 --- quit: cbridge_ (Remote host closed the connection)
14:45:55 --- join: cbridge_ joined #forth
16:16:16 <cbridge_> <MrMobius> I think you pretty much need the type byte if you want something like generic + that works with any types
17:06:39 --- quit: rtdos (Ping timeout: 245 seconds)
17:06:39 --- quit: proteanthread (Ping timeout: 245 seconds)
17:20:45 --- join: proteanthread joined #forth
17:20:45 --- join: rtdos joined #forth
19:31:46 --- join: gravicappa joined #forth
19:44:25 --- quit: rtdos (Quit: Leaving.)
19:44:26 --- quit: proteanthread (Quit: Leaving.)
20:00:48 --- join: proteanthread joined #forth
20:00:48 --- join: rtdos joined #forth
20:18:45 --- quit: proteanthread (Read error: Connection reset by peer)
20:18:46 --- quit: rtdos (Read error: Connection reset by peer)
20:29:59 <cbridge_> <dave0> maw
20:30:55 <cbridge_> <crc> maw
20:31:10 <cbridge_> <dave0> maw crc 
21:28:30 <cbridge_> <siraben> remexre: coding the stack as a heterogeneous tuple has worked well for me when I wrote stacked-based language with polymorphism
21:29:09 <cbridge_> <siraben> and dependent types might be needed to encode certain patterns as you observe
21:31:32 --- join: crab joined #forth
21:34:43 --- join: mark4_ joined #forth
21:36:53 <crab> yo
21:37:31 --- quit: rprimus (Ping timeout: 240 seconds)
21:38:16 --- quit: mark4 (Ping timeout: 265 seconds)
21:38:16 --- quit: veltas (Ping timeout: 265 seconds)
21:38:16 --- quit: cmtptr (Ping timeout: 265 seconds)
21:38:33 --- join: veltas joined #forth
21:38:38 --- join: rprimus joined #forth
21:39:07 --- join: cmtptr joined #forth
21:56:48 <cbridge_> -!- ChanServ changed mode/##forth -> +o crc 
21:58:03 --- quit: crab (Ping timeout: 260 seconds)
22:22:03 --- part: rprimus left #forth
22:29:39 <cbridge_> <siraben> remexre: hm, not sure why one would need row-polymorphism, IIRC those make sense in the context of records, no?
22:47:05 <cbridge_> <remexre> siraben: I was thinking of the type of e.g. DROP being ( x -- ), so the row-polymorphism-like would be generalizing it to ( x y -- y ), etc
22:47:52 <cbridge_> <remexre> seemed useful to have row polymorphism instead of subtyping so it'd be possible to talk about effects that affect the whole stack
22:59:32 <cbridge_> <siraben> remexre: yeah I've done that before and the type was like, `x :. y → y`
22:59:41 <cbridge_> <siraben> (inferred)
22:59:57 <cbridge_> <siraben> if you want to drop all the items on the stack it would be `x :. y → ()`
23:00:16 <cbridge_> <siraben> or something isomorphic to unit
23:41:01 --- quit: mark4_ (Ping timeout: 258 seconds)
23:59:59 --- log: ended forth/21.06.05