00:00:00 --- log: started forth/20.12.27 00:01:00 --- quit: lisbeths (Read error: Connection reset by peer) 00:01:20 --- join: lisbeths joined #forth 00:04:01 --- quit: lisbeths (Read error: Connection reset by peer) 00:05:11 --- join: birdwing joined #forth 00:06:25 --- join: lisbeths joined #forth 00:06:25 --- quit: lisbeths (Read error: Connection reset by peer) 00:08:49 --- join: lisbeths joined #forth 00:08:49 --- quit: lisbeths (Read error: Connection reset by peer) 00:11:13 --- join: lisbeths joined #forth 00:11:13 --- quit: lisbeths (Read error: Connection reset by peer) 00:13:37 --- join: lisbeths joined #forth 00:13:37 --- quit: lisbeths (Read error: Connection reset by peer) 00:16:01 --- join: lisbeths joined #forth 00:16:01 --- quit: lisbeths (Read error: Connection reset by peer) 00:16:12 --- join: lisbeths joined #forth 00:20:50 --- quit: jsoft (Quit: Leaving) 00:23:10 --- quit: lisbeths (Read error: Connection reset by peer) 00:23:38 --- join: lisbeths joined #forth 00:27:24 --- quit: lisbeths (Read error: Connection reset by peer) 00:29:35 --- join: lisbeths joined #forth 00:29:35 --- quit: lisbeths (Read error: Connection reset by peer) 00:30:24 --- join: lisbeths joined #forth 00:32:49 --- quit: lisbeths (Read error: Connection reset by peer) 00:35:25 --- join: lisbeths joined #forth 00:35:25 --- quit: lisbeths (Read error: Connection reset by peer) 00:36:35 --- join: lisbeths joined #forth 00:38:55 --- quit: lisbeths (Read error: Connection reset by peer) 00:39:09 --- join: lisbeths joined #forth 00:41:15 --- quit: lisbeths (Write error: Connection reset by peer) 00:43:37 --- join: lisbeths joined #forth 00:43:37 --- quit: lisbeths (Read error: Connection reset by peer) 00:45:10 --- join: lisbeths joined #forth 01:02:15 --- quit: lisbeths (Read error: Connection reset by peer) 01:02:27 --- join: lisbeths joined #forth 01:05:49 --- quit: lisbeths (Read error: Connection reset by peer) 01:06:14 --- join: lisbeths joined #forth 01:08:25 --- quit: lisbeths (Remote host closed the connection) 01:10:17 --- join: lisbeths joined #forth 01:13:00 --- quit: lisbeths (Read error: Connection reset by peer) 01:13:12 --- join: lisbeths joined #forth 01:16:01 --- quit: lisbeths (Read error: Connection reset by peer) 01:18:25 --- join: lisbeths joined #forth 01:18:25 --- quit: lisbeths (Read error: Connection reset by peer) 01:18:36 --- join: lisbeths joined #forth 01:21:29 --- quit: lisbeths (Read error: Connection reset by peer) 01:22:35 --- join: lisbeths joined #forth 01:41:13 --- quit: lisbeths (Read error: Connection reset by peer) 01:41:49 --- join: lisbeths joined #forth 01:44:15 --- quit: lisbeths (Read error: Connection reset by peer) 01:44:52 --- join: lisbeths joined #forth 01:47:49 --- quit: lisbeths (Read error: Connection reset by peer) 01:48:00 --- join: lisbeths joined #forth 01:50:48 --- quit: lisbeths (Read error: Connection reset by peer) 01:51:37 --- join: lisbeths joined #forth 02:13:37 --- quit: lisbeths (Read error: Connection reset by peer) 02:16:19 --- join: lisbeths joined #forth 02:16:20 --- quit: lisbeths (Read error: Connection reset by peer) 02:16:31 --- join: lisbeths joined #forth 02:19:01 --- quit: lisbeths (Read error: Connection reset by peer) 02:20:24 --- join: lisbeths joined #forth 02:23:55 --- quit: lisbeths (Read error: Connection reset by peer) 02:26:13 --- join: lisbeths joined #forth 02:26:13 --- quit: lisbeths (Read error: Connection reset by peer) 02:28:34 --- join: lisbeths joined #forth 02:28:35 --- quit: lisbeths (Write error: Connection reset by peer) 02:29:54 --- quit: kori (Quit: WeeChat 2.8) 02:30:54 --- join: lisbeths joined #forth 02:30:54 --- quit: lisbeths (Read error: Connection reset by peer) 02:31:53 --- join: lisbeths joined #forth 02:35:00 --- quit: lisbeths (Read error: Connection reset by peer) 02:35:55 --- join: lisbeths joined #forth 02:39:05 --- quit: lisbeths (Read error: Connection reset by peer) 02:41:25 --- join: lisbeths joined #forth 02:41:25 --- quit: lisbeths (Read error: Connection reset by peer) 02:42:13 --- join: lisbeths joined #forth 03:00:05 --- quit: lisbeths (Read error: Connection reset by peer) 03:00:54 --- join: lisbeths joined #forth 03:25:12 --- quit: lispmacs (Read error: Connection reset by peer) 03:27:30 --- quit: lisbeths (Read error: Connection reset by peer) 03:27:45 --- join: lisbeths joined #forth 03:30:24 --- quit: lisbeths (Read error: Connection reset by peer) 03:31:09 --- join: lisbeths joined #forth 03:59:27 --- join: dave0 joined #forth 04:22:27 --- join: lispmacs joined #forth 04:46:49 --- quit: lisbeths (Ping timeout: 260 seconds) 04:53:04 --- quit: dave0 (Quit: dave's not here) 05:30:49 "That's a point in Forth's favor because, in embedded-systems development, an engineer who understands the hardware is often a more effective programmer than a computer-science graduate who would rather be writing compilers." 05:31:26 Do people actually think this? That CS grads who pursue embedded software just want to write compilers instead of the thing they pursued? 05:32:27 Also part of Forth is writing your own compiler so it's contradictory as well 05:32:32 https://www.electronicdesign.com/technologies/boards/article/21761390/forth-still-suits-embedded-applications 05:34:51 veltas: why not understand the hardware and understand how to write compilers? heh 05:35:16 Oh I do want to write compilers, I just wouldn't 'rather' be writing compilers 05:35:45 This was written in 1999 and I suspect I know a few hardware engineers who still feel this way... 05:36:26 I just noticed the date, ah 05:36:49 Feel what way? That you only need to know the hardware to be an effective programmer? 05:38:16 No that software background people care more about abstract problems than writing good embedded software 05:39:17 I am certainly not like that, and I come from a pure software background 05:40:20 But it also seems weirdly contradictory because Forth *is* an interesting tool for creating languages, as well as a good embedded programming environment 05:48:07 I actually bothered to get the latest snapshot of gforth and it's really nice 05:48:23 I like the status bar even if it's probably not very forthy 06:20:23 --- quit: cantstanya (Remote host closed the connection) 06:22:41 --- join: cantstanya joined #forth 06:32:15 siraben, I think combinators are interesting tools upon which you might realize some design but they are rarely an efficient way to implement a final solution. Forth tends to go for the throat in attacking a problem. 06:41:20 If combinators let you write code easier in forth, without a massive overhead and without horrific syntax, then it's an appropriate addition 06:42:00 It's my opinion but often I find myself writing code I know is less efficient but gets me to a result faster or in less forth 06:42:36 veltas, completely agree. it's just rarely the case. guess it depends on the problem set. 06:42:38 in fact forth wouldn't need certain combinators like compose that's just implied by the concatenation 06:42:57 I haven't tried writing more functional style forth, have you siraben ? 06:43:00 I know crc has 06:43:20 many combinators like repeatN would be compile-time and based on the last word compiled etc 06:44:01 veltas: not really, but I implemented a stack-based language with type inference in Haskell 06:44:06 I think this kind of stuff would probably be *more* appropriate than e.g. locals syntax, which I think is quite unforthy usually 06:44:34 When I ported meta-yacc I used locals initially because it was easier, then went back and removed some 06:44:38 but some still remain 06:45:00 https://github.com/siraben/meta-yacc/blob/master/meta.fs 06:45:18 this is the generated forth code by running the parser generator on itself 06:48:37 My conjecture is local probably wouldn't have much overheard if one compiles to code that uses a stack offset (see debruijn indices) to fetch the locals 06:48:51 no overhead, even 06:49:37 the problem is now you must fix the arity of your words and have them be known to properly compile the stack offset 07:01:27 siraben, hmm... if only you had a type-safe forth that enforced stack pictures... ;-) 07:02:05 proteusguy: yeah my haskell interpreter of a stack based language did that 07:02:25 siraben, so nothing stopping you from implementing it, right? 07:02:47 nope 07:02:55 i would probably do it in assembly again 07:03:02 haha. 07:03:08 easiest to control in/out arity by putting a little header 07:03:14 two extra bytes 07:03:17 well I'm with you - about to embark on rewriting ActorForth in C++. 07:03:31 best of luck, would be interesting 07:04:15 perhaps some combinators will be first order operands. ;-) 07:04:50 hm i just thought, knowing the arities would be of great use, no type checking needed and compound words could have their arities automatically calculated 07:05:00 and you can do locals without fear 07:05:08 yep could 07:32:52 I think better than using locals is the notation where if you don't want to clutter with stack ops you just do like "reorder abcd", I think retro has something like that 07:33:19 i.e. reorder abaa 07:33:56 I will sit down and try writing something like that but with digits, like 1234 reorder 07:34:32 forth.works:9999/377 07:34:43 yeah like specify in permutation form 07:35:02 'ab 'abaa reorder 07:35:07 I found out that you can do this with only R> >R and swap 07:35:26 Locals definitely make certain things neater, the biggest danger is overusing them and making code longer, if you're not doing that it's not really a heresy 07:35:32 i wrote a program to generate the permuters up to depth 4 then proved it up to N with induction 07:35:42 crc: That's the one 07:35:44 veltas: exactly 07:35:55 crc: oh cool 07:35:57 And I think that's a lot nicer than locals where locals might 'simplify' sometimes 07:36:58 it's useful occasionally to avoid a bunch of messy stack shuffling 07:37:40 --- quit: cmtptr (Quit: leaving) 07:39:04 It avoids the need to put anything in return stack or a locals area, for one thing, except perhaps for the duration of the word 07:40:56 The semantics of EXIT etc don't have to change as well 08:11:56 --- join: cmtptr joined #forth 08:24:41 --- quit: gravicappa (Ping timeout: 260 seconds) 08:38:24 --- join: gravicappa joined #forth 09:16:36 completely generic locals isn't necessary. having a single "temp register" to interact efficiently with the stack will generally give you what you want in a highly efficient manner. 09:21:15 but if you have a function that uses the temp register and it calls another function that uses temp registers, then you'll have to have register saving conventions again 09:21:23 OTOH locals compose without interference 09:26:42 if you consider combinators as atomic operations - how many "scratch registers" are needed if you consider them clear after each operation? 09:27:13 I'm not sure I understand what you mean 09:27:40 if f uses temp reg A, and calls g which uses temp reg A, f has to save and restore A before and after calling g right? 10:24:58 --- quit: gravicappa (Ping timeout: 240 seconds) 10:27:53 --- join: gravicappa joined #forth 11:46:49 --- quit: birdwing (Ping timeout: 260 seconds) 11:54:22 --- join: mark4 joined #forth 11:54:35 --- quit: gravicappa (Ping timeout: 264 seconds) 11:55:08 Would be interested if you could elaborate proteusguy 12:53:28 --- join: mark4_ joined #forth 12:57:24 --- quit: mark4 (Ping timeout: 260 seconds) 15:17:06 --- quit: mark4_ (Read error: Connection reset by peer) 15:17:36 --- join: mark4_ joined #forth 15:34:19 --- quit: proteus-guy (Ping timeout: 260 seconds) 15:38:31 --- quit: mark4_ (Read error: Connection reset by peer) 15:39:22 --- join: mark4_ joined #forth 15:46:11 --- join: proteus-guy joined #forth 18:19:07 --- join: dave0 joined #forth 18:22:05 --- join: birdwing joined #forth 18:48:12 --- join: boru` joined #forth 18:48:15 --- quit: boru (Disconnected by services) 18:48:18 --- nick: boru` -> boru 19:38:09 --- quit: proteus-guy (Ping timeout: 260 seconds) 19:50:28 --- join: proteus-guy joined #forth 19:53:52 --- join: mark4__ joined #forth 19:57:59 --- quit: mark4_ (Ping timeout: 260 seconds) 20:02:21 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. 20:03:09 Atomic as in the notion from concurrency? 20:03:54 Atomic as in act as an operation in the CPU. 20:05:08 So you now have to deal with callee-save register conventions 20:08:03 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. 20:08:36 If such a thing is complicated with combinators then maybe combinators aren't the right tools for a stack based system. 20:08:49 What do you mean by combinators? 20:09:22 Talking about your SKI/combinatory logic. The birds. ;-) 20:09:54 Forth has plenty of what I consider combinators, i.e. any sort of trivial, "pure" words like dup, swap etc. with a clear denotation 20:10:46 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 20:11:46 tangential point but compiling to combinators is getting renewed interest with http://okmij.org/ftp/tagless-final/ski.pdf , amazing read 20:24:00 --- quit: sts-q (Ping timeout: 265 seconds) 20:28:56 --- quit: dave0 (Quit: dave's not here) 20:33:33 --- join: sts-q joined #forth 20:40:27 --- quit: mark4__ (Read error: Connection reset by peer) 20:41:23 --- join: mark4_ joined #forth 20:46:10 --- join: gravicappa joined #forth 21:29:03 --- join: mark4__ joined #forth 21:29:03 --- quit: mark4_ (Read error: Connection reset by peer) 21:29:33 --- join: mark4_ joined #forth 21:33:39 --- quit: mark4__ (Ping timeout: 260 seconds) 21:34:03 --- join: mark4__ joined #forth 21:35:00 --- quit: mark4_ (Ping timeout: 272 seconds) 21:46:19 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. 21:46:24 --- quit: proteus-guy (Ping timeout: 272 seconds) 21:46:27 forth. 21:46:55 --- join: proteus-guy joined #forth 22:12:22 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) 22:12:25 LLVM* 22:17:27 --- join: mark4_ joined #forth 22:21:29 --- quit: mark4__ (Ping timeout: 260 seconds) 22:49:58 --- quit: proteus-guy (Ping timeout: 265 seconds) 22:51:54 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. 22:52:14 proteusguy: of course! 22:52:57 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. 22:53:08 But you're just moving the complexity of course. 23:08:01 --- join: proteus-guy joined #forth 23:09:17 --- quit: mark4_ (Read error: Connection reset by peer) 23:11:10 --- join: jedb_ joined #forth 23:11:39 --- quit: jedb (Ping timeout: 260 seconds) 23:46:36 --- quit: rann (Ping timeout: 264 seconds) 23:47:07 --- quit: ovf (Ping timeout: 246 seconds) 23:48:50 --- join: rann joined #forth 23:50:07 --- join: ovf joined #forth 23:59:59 --- log: ended forth/20.12.27