2022-01-08 10:08:44 <lagash      > veltas: intriguing style!
2022-01-08 15:22:50 <veltas      > What is a "Fully Functional Forth"?
2022-01-08 15:37:43 <lagash      > A FORTH that's fully functional :)
2022-01-08 15:41:25 <remexre     > how do (e.g. STC) Forths support cross-compilation? does it make sense to have, like, two different code pointers in word headers, one for if the word needs to be run while compiling, one for the "output binary" version?
2022-01-08 15:43:17 <veltas      > lagash: What kind of 'functional', as in it works or is 'functional' in the sense of functional programming languages?
2022-01-08 15:47:21 <spoofer     > I'm guessing that refers to the link to bashforth and that functional in this case means that you can define new words.
2022-01-08 15:49:46 <veltas      > remexre: What kind of cross compiling? Like to a remote device or building another FORTH on the same device?
2022-01-08 15:50:21 <remexre     > building a binary for another CPU architecture on one device
2022-01-08 15:52:24 <veltas      > I wrote a load of special words for the job, compiled into a fixed size buffer I pre-allocated
2022-01-08 15:52:56 <veltas      > I used the local dictionary to define useful macros/words to help building the other FORTH
2022-01-08 15:53:55 <remexre     > local dictionary?
2022-01-08 15:54:52 <veltas      > The dictionary of the FORTH I was building the other FORTH with
2022-01-08 15:55:06 <veltas      > I'm not sure I understand your question though really
2022-01-08 15:55:47 <veltas      > I don't understand why two different code pointers would help for cross-compiling to a different arch
2022-01-08 15:56:18 <remexre     > let's say I do like
2022-01-08 15:57:11 <remexre     > : hello ." Hello, world!" ;    hello    ' hello dump-image
2022-01-08 15:57:30 <remexre     > and I'm on amd64, and I want to compile to aarch64
2022-01-08 15:57:42 <remexre     > I need a version of hello for each architecture, don't I?
2022-01-08 16:00:13 <veltas      > That's one way of doing it
2022-01-08 16:02:45 <remexre     > is there another way that doesn't require that sort of "hacky" change to support this though?
2022-01-08 16:12:34 <remexre     > "that" being my two-code-pointers thing; I'm not completely sure I understand your approach
2022-01-08 16:13:15 <veltas      > My approach:
2022-01-08 16:13:28 <veltas      > 1. Have a working FORTH
2022-01-08 16:14:14 <veltas      > 2. Write a special word like C: to create cross-compiled colon def, and CCODE to cross-compile code
2022-01-08 16:14:57 <veltas      > 3. Have a special wordlist that lets you write words that do 'immediate' work when compiling, to search while cross-compiling a colon def
2022-01-08 16:15:41 <veltas      > 4. When you have enough words to compile other words then do the rest natively on the new FORTH, if appropriate
2022-01-08 16:15:55 <veltas      > "if appropriate" i.e. if it's not a remote FORTH
2022-01-08 16:16:31 <veltas      > The step I don't understand for your approach is how you would write the kernel or core words if they already exist
2022-01-08 16:19:05 <remexre     > like DROP and things? they'd either be built in, or defined as code words, and I'd reload+recompile pretty much the whole system once I started cross-compiling, I guess
2022-01-08 16:20:53 <veltas      > I really don't understand your approach but if you do then that's all that matters
2022-01-08 16:21:38 <remexre     > eh, my approach is based on how I'd do it for a Common Lisp compiler, and Forth and CL are two very different languages :)
2022-01-08 16:23:05 <sennomo     > Is it time to wheel out that language that mixes Forth and Lisp again?  XD
2022-01-08 16:23:36 <remexre     > Haskell? /me hides
2022-01-08 16:23:51 <remexre     > point-free Haskell*
2022-01-08 16:25:06 <f-a         > yeah the clarity of forth with the speed of lisp
2022-01-08 16:41:02 <veltas      > lol
2022-01-08 18:54:23 <veltas      > I just realised true carry is worse than carry=borrow
2022-01-08 20:11:24 <veltas      > I think I'm repeating mistakes I made in Z80 in x86-64
2022-01-08 20:23:33 <imode       > fraglets are a neat concept that I feel warrants more exploration. data-as-mobile-code is probably the next "phase" of computing.
2022-01-08 20:23:51 <imode       > there's some precedent in forth circles for it.
2022-01-08 20:23:58 <imode       > such as SOFTNET.
2022-01-08 23:32:56 <imode       > for anybody unfamiliar with fraglets.. here's a neat sample. http://okturing.com/src/12938/body