04:01 <proteusguy> siraben, if the reg needs maintaining outside of the combinator then it's not atomic. So you'd be looking at moving it to the return stack before calling the dependency.

04:02 <siraben> Atomic as in the notion from concurrency?

04:03 <proteusguy> Atomic as in act as an operation in the CPU.

04:04 <siraben> So you now have to deal with callee-save register conventions

04:07 <proteusguy> siraben, this is one of those things you need to try a few times to see how it goes and adjust accordingly. I think that's a rare circumstance. Or you could just add another stack for that purpose if it becomes an actual common problem.

04:08 <proteusguy> If such a thing is complicated with combinators then maybe combinators aren't the right tools for a stack based system.

04:08 <siraben> What do you mean by combinators?

04:09 <proteusguy> Talking about your SKI/combinatory logic. The birds. ;-)

04:09 <siraben> Forth has plenty of what I consider combinators, i.e. any sort of trivial, "pure" words like dup, swap etc. with a clear denotation

04:10 <siraben> issue with combinators in FP is that compiling to them can blow up code size when an actual environment structure would be better in space and time

04:11 <siraben> tangential point but compiling to combinators is getting renewed interest with http://okmij.org/ftp/tagless-final/ski.pdf , amazing read

05:45 <proteusguy> re:blow up code size - this is what I was referring to when I said perhaps these aren't the most appropriate building blocks for fort.

05:46 <proteusguy> forth.

06:12 <siraben> Not just for Forth, but any modern functional language no longer uses compiling to combinators as the approach, usually opting for generating C or LLVm (after closure conversion, lambda lifting and CPS)

06:12 <siraben> LLVM*

06:51 <proteusguy> siraben, well for other languages with more complex compilers such as LLVM, they can do a lot of complex implementation optimization. This being a forth channel, however, forces me to point out that such complexity is the antithesis of forth.

06:51 <siraben> proteusguy: of course!

06:52 <proteusguy> Although making a forth that targets LLVM IR might still be viable. I recall a guy who did that and created an LLVM target that was better optmized for a stack oriented architecture.

06:52 <proteusguy> But you're just moving the complexity of course.

10:35 <veltas> Don't want to sound stupid but I'd be using the return stack rather than registers since I'd have to save things anyway on most implementations

10:35 <veltas> Maybe there should be words like R1@ R2@ R3@ R4@ etc to get what's after R@

10:37 <veltas> Could even *name* those temporarily within the wo-... oh right that's just locals whoops

10:40 <veltas> Has there been any effort to standardise multi-task forths?

10:40 <veltas> i.e. with suspend/wait/user or whatever they use

10:41 <veltas> It feels like that should be a word set in the standard

11:00 <sts-q> veltas: Not sure, do you mean something like this ?

11:00 <sts-q> Chapter 4.0 MULTITASKING

11:00 <sts-q> http://www.greenarraychips.com/home/documents/greg/DB005-120825-PF-REF.pdf

11:11 <veltas> Yes

11:15 <veltas> I I' J are documented as getting the first, second, and third things on the return stack in starting forth

11:15 <veltas> Makes sense, unfortunately not standard

13:05 <siraben> veltas: haha, that's just locals indeed

13:56 <proteusguy> veltas, concurrency is definitely not part of any forth standard. I can't imagine one model ever being something forthers would adopt in general. It took C++ 30+ years to define a standard concurrency model and they still ended up with two.

15:38 <lispmacs> hi, I was just wondering if there had been any progress anywhere towards an inexpensive GA144 development board

15:38 <lispmacs> https://hackaday.io/project/163652-ga144-evaluation-board

16:33 <proteusguy> I'm not aware of one. Would enjoy playing with such a thing as well.

16:43 <MrMobius> lispmacs, have you seen this? https://schmartboard.com/schmartboard-ez-qfn-88-pins-0-4mm-pitch-2-x-2-grid-bundled-with-a-greenarrays-ga144-ic-202-0048-02/

16:52 <proteusguy> MrMobius, my understanding is that there's still an issue getting hold of the ga144 chips themselves. Hopefully that's no longer the case.

17:01 <MrMobius> oh hmm

17:01 <MrMobius> looks like you get the chip too if yoy buy that board

17:32 <MrMobius> in the forth day update this year it sounded like they still dont have any customers :(

17:34 <veltas> Always a danger when you create something that solves problems the way you envisage them, there might be nobody else who thinks the same way

17:34 <veltas> Definitely the case with people like Chuck Moore

17:36 <veltas> If I get a chance I will propagandise the board at work to a design engineer

17:38 <veltas> I have been reading comp.lang.arguing-with-hugh-aguilar

17:39 <MrMobius> someone called it "a problem looking for a solution"

17:40 <MrMobius> you have to admit there isnt much of anything where you need 144 cores working in parallel

17:41 <MrMobius> especially with tiny memories that all have to be individually programmed. I think that's the main thing that kills it, not only lack of a C compiler

17:44 <MrMobius> woops, make that a solution looking for a problem...

18:41 <patrickg> veltas: clf is as quiet as other newsgroups once the killfile is properly seeded

19:12 <birdwing> "Always a danger when you create something that solves problems..." https://medium.com/swlh/good-technology-bad-investment-7e0d6bfa08dc

20:58 <veltas> wordlists...