00:00:00 --- log: started forth/16.11.01 02:29:21 --- join: true-grue (~true-grue@176.14.222.10) joined #forth 02:50:15 yunfan: that only works if the system dictionary is a domain specific langauge for the problem set being solved, otherwise you would have flooded the namespace for no real benefit. For example if all 100K vms are to be working on html generation, you could very easily add a dozen or so primatives that would make the code that operates in that problem space dense and efficient. But adding arbirary precision math and graphic functions 02:50:15 while useful for other problem spaces, would actually be a net harm to user productivity. eg Does append add some text or a blocked graphics data segment 02:52:32 --- quit: nighty (Quit: Disappears in a puff of smoke) 02:52:43 OriansJ: well i guess you have never used nginx and redis 02:53:13 OriansJ: if i want to use them inside nginx and redis, which implicit that's a domain specific case 02:57:12 --- quit: karswell (Ping timeout: 268 seconds) 02:58:33 yunfan: Have used them but I never felt like they required a more efficient interpreted language 03:00:04 yunfan: If I was going for massive performance wins, I would have gone with a handful of compiled functions. 03:02:01 OriansJ: well since you have used redis, do you know why they embeded lua ? 03:02:37 yunfan: flexibility and rapid prototyping 03:02:42 OriansJ: they have many composed features commands which is just a combination of many simple command 03:02:57 so they have to import lua to do many other complex query 03:03:46 i think in future, they could just implement a cpu like arch, which provide micro-code like function, and import a language to implement all the other features 03:03:57 i prefer forth to be this language 03:05:38 yunfan: that line of logic leads to only one place, the client side byte compiles instructions and uploads them to the server for execution, no language but a brittle and forever stuck bytecode 03:06:54 OriansJ: nope, server side could have a core and many interface. like socket interface which accept redis protocol from socket connection and compiling them 03:12:26 yunfan: bytecode would give you a massive memory reduction [256 Bytes per vm], is simpler to implement and turing complete 03:13:59 10:03 < yunfan> i think in future, they could just implement a cpu like arch, which provide micro-code like function, and import a language to implement all the other features 03:14:06 yunfan: that would be a RISC machine 03:15:26 gordonjcp: yes and to OriansJ you could use a retro like design for your sepcial forth 03:15:28 gordonjcp: the only problem is that flexibility has a real memory cost to it 03:15:31 bytecode and forth 03:16:31 yunfan: retro and works well beats new and poorly thought out everytime 03:17:26 OriansJ: but lua itself have a vm too 03:17:50 yunfan: if you go the bytecode route, then the language can be anything you want as they will all just end up compiled down to the bytecode 03:17:54 people have accept that cost for flexibility 03:18:24 OriansJ: of course, its just my wish to use a forth like lang on it 03:19:30 yunfan: ultimately if you want optimial performance, you are going to have to compile because flexibility always ends up having more runtime costs. 03:20:50 OriansJ: of course i need performance , but i need flexibility too. so i choose a balance solution. lua was used and got success, so i want to have forth running on it 03:21:09 OriansJ: so i could get a equally performance but much more flexibility 03:22:07 yunfan: you don't have to chose one or the other, simply select flexibility first to figure out what is needed and then replace it with a compiled result when things get settled 03:23:30 --- quit: M-jimt (Remote host closed the connection) 03:24:54 yunfan: simply choose languages that have a first class FFI and then mix them as deemed appropriate 03:40:53 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 03:51:08 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-myrtujudlkphvcpl) joined #forth 04:04:11 --- quit: cantstanya (Ping timeout: 245 seconds) 04:08:48 --- quit: M-jimt (Remote host closed the connection) 04:11:41 --- join: cantstanya (~chatting@unaffiliated/cantstanya) joined #forth 04:20:05 --- join: M-jimt (jimtmatrix@gateway/shell/matrix.org/x-tptrszhuirpumkai) joined #forth 04:27:55 --- quit: mnemnion (Remote host closed the connection) 04:30:13 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:458d:93c0:1e9:1282) joined #forth 04:35:02 --- quit: mnemnion (Ping timeout: 260 seconds) 04:39:41 --- join: ricky_ricardo (~rickyrica@2601:240:4203:ecb0:5dbb:755c:97a0:a220) joined #forth 05:19:18 --- join: rgrinberg (~rgrinberg@24-246-56-85.cable.teksavvy.com) joined #forth 05:26:02 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:458d:93c0:1e9:1282) joined #forth 05:30:34 --- quit: mnemnion (Ping timeout: 260 seconds) 05:40:32 --- join: karswell (~user@124.209.208.46.dyn.plus.net) joined #forth 06:27:39 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:8d6a:ddcf:d5fc:c62e) joined #forth 06:30:11 --- quit: karswell (Read error: Connection reset by peer) 06:30:58 --- join: karswell` (~user@124.209.208.46.dyn.plus.net) joined #forth 06:31:40 --- quit: mnemnion (Ping timeout: 245 seconds) 06:55:46 I understand the forth philosophy is to factor as much as possible, producing simple definitions of 5 or so words. I don't understand how you handle errors this way, though. for example, in c a very simple function might be int doit(void) {int fd = open(...); if (fd < 0) return fd; ssize_t n = write(fd, buf, len); if (n < 0) return n; return close(fd); } 06:56:12 how do you factor that down to small five-or-so-word-long words in forth? 06:59:03 like that write alone, for example, would be "dup write dup 0 lt if exit then drop" 06:59:29 or rather, "dup write dup 0 lt if exit then drop" 07:26:25 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:148f:6352:e107:fefc) joined #forth 07:30:38 --- join: nal (~nal@adsl-64-237-236-159.prtc.net) joined #forth 07:30:58 --- quit: mnemnion (Ping timeout: 260 seconds) 08:06:48 --- join: dcs (~moby@189-105-251-179.user.veloxzone.com.br) joined #forth 08:12:26 --- join: neceve (~ncv@86.125.241.206) joined #forth 08:12:26 --- quit: neceve (Changing host) 08:12:26 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 08:16:11 zy]x[yz, you should adopt a policy of failing fast. If you adopt a more functional/concatenative approach you won't see a lot of checking for result codes and treating them as predicates driving different code paths. There's the happy path and there's report and panic. 08:27:56 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:750b:8c4a:a339:32be) joined #forth 08:32:34 --- quit: mnemnion (Ping timeout: 260 seconds) 08:43:48 --- join: desolator (~quassel@broadband-188-255-97-129.nationalcablenetworks.ru) joined #forth 09:09:12 --- quit: rgrinberg (Ping timeout: 265 seconds) 09:12:59 --- join: ASau (~user@netbsd/developers/asau) joined #forth 10:13:21 --- join: mnemnion (~mnemnion@71.198.73.193) joined #forth 10:39:34 proteusguy, so how do I do that in forth? 10:39:51 what is the construct to report and panic? 10:47:56 --- join: rgrinberg (~rgrinberg@24-246-56-85.cable.teksavvy.com) joined #forth 11:05:34 --- quit: nal (Ping timeout: 260 seconds) 11:12:40 --- quit: ASau (Ping timeout: 256 seconds) 11:22:58 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 11:23:48 --- quit: Zarutian (Read error: Connection reset by peer) 11:23:50 --- join: ASau (~user@netbsd/developers/asau) joined #forth 11:24:52 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 11:49:51 yunfan: but a RISC machine is essentially a machine in which you write very very vertical microcode 11:54:05 It's an idealistic definition. ARMs have microcode, for example :) 12:45:20 true-grue: mmmm, kind of 12:45:24 more nanocode really 12:45:46 gordonjcp, http://www.righto.com/2016/02/reverse-engineering-arm1-processors.html :) 12:51:20 true-grue: I've seen it :-) 13:14:43 it seems from irc logs that i neglected to mention my interview, sorry about that. http://embedded.fm/episodes/172 ... about Forth, about OLPC. probably has errors of memory and understanding. ;-} 13:18:19 --- quit: desolator (Read error: Connection reset by peer) 13:34:53 --- quit: neceve (Quit: Konversation terminated!) 14:30:24 --- join: X-Scale (~ARM@188.140.121.157) joined #forth 14:32:22 --- quit: rgrinberg (Ping timeout: 260 seconds) 14:55:15 --- quit: dcs (Quit: Leaving) 15:20:00 --- quit: ricky_ricardo (Ping timeout: 245 seconds) 15:26:16 I asked this a couple of days ago and never got an answer: what exactly is ['] for? just but the concatenative nature of how forth compiles words, isn't "['] foo" exactly the same thing as writing "lit foo" ? 15:27:56 s/but/by/ 15:29:32 Concatenative is a wrong term. 15:30:08 xy]x[yz: both ' and ['] can be used inside a colon definition. The difference is ['] will get the word name at compile time (inside the colon definition) and ' will get the word name at run time when you run the compiled word. 15:30:17 If you want to describe Forth grammar then "context-sensitive" is a better one. 15:32:43 pointfree, I understand the difference between ' and [']. what I don't understand is the difference between "['] foo" and "lit foo" in a colon definition 15:33:15 true-grue, I get the impression that you were responding to the same thing pointfree was, immediate versus compiled 15:34:51 zy]x[yz, : foo [ ' drop ] literal ; 15:35:09 Compare with : foo2 ['] drop ; 15:35:30 It seems in some forths xt's and lit's are not the same. See m3forth https://bitbucket.org/cbiffle/m3forth/src/4be4eedf57b8013fa48547de3b43818b6cec6168/macros.s?at=subroutine-threading&fileviewer=file-view-default#macros.s-119 15:38:06 pointfree, thanks 15:43:16 although maybe I'm missing something, but in that example it looks to me like those macros would expand to exactly the same thing 15:43:25 but your point still stands 15:55:57 --- quit: true-grue (Read error: Connection reset by peer) 16:02:08 So, my current approach to parsing files of a particular format with forth is to extend the Forth to support that input file as code: if I were to parse a csv I might use the comma compiler. If I were to parse this irc log, your irc nicks would be words that parse until the newline character. 16:02:29 The only thing that foils this plan is non-whitespace delimited formats. Does anyone know how I might change the word delimiter? I'm thinking about including the starting or trailing space as part of the word name...in my own forth. 16:11:11 I just closed the last major bug in stage0 forth, it may still be spartan for a forth but thanks to its vm. It now can run on every computing platform created in the last 38 years 16:12:16 I've been wondering if it would be beneficial to have "hyper-immediate" words that get executed during parsing. Kind of like reader macros in lisp, only for certain sequences instead of just characters. Of course, there could be some issues if a prefix of a certain sequence was defined as "hyper-immediate" at the same time as the sequence itself was... 16:15:59 reepca: well it could be beneficial for several exotic tasks, It just doesn't seem to benefit the forth core 16:17:10 --- quit: Zarutian (Quit: Zarutian) 16:22:17 --- join: nal (~nal@adsl-64-237-236-159.prtc.net) joined #forth 16:27:31 --- quit: nighty (Quit: Disappears in a puff of smoke) 16:48:14 reepca: I like that idea. Forth already exposes compiling as words in the language. Why not decompose the outer interpreter into a lexicon thus exposing that too? 16:48:32 I've used Matthias Trute's recognizers which make the interpreter extensible, but somehow it still feels to rigid. I'd like these parser words to be as simple as a comma compiler at their core. Parser combinators perhaps? 16:48:57 too* 17:12:18 : " here [char] " parse tuck here over allot cmove state @ if postpone literal postpone literal then ; parse-immediate 17:12:25 would that work? 17:12:41 (as an example of a "parsing-immediate" word) 17:30:01 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 17:56:49 --- join: dcs (bd69fbb3@gateway/web/freenode/ip.189.105.251.179) joined #forth 18:03:42 --- quit: dcs (Quit: Page closed) 18:04:59 --- join: dcs (~moby@189-105-251-179.user.veloxzone.com.br) joined #forth 18:21:37 --- nick: karswell` -> karswell 18:31:58 --- nick: dcs -> pobrema 19:15:01 --- join: ricky_ricardo (~rickyrica@2601:240:4203:ecb0:5dbb:755c:97a0:a220) joined #forth 19:55:30 --- part: OriansJ left #forth 19:57:54 --- quit: karswell (Quit: ERC (IRC client for Emacs 25.1.1)) 20:07:05 --- quit: ricky_ricardo (Ping timeout: 245 seconds) 20:34:26 --- quit: pdewacht (Ping timeout: 260 seconds) 20:42:19 --- join: pdewacht (~repent@kulon.2k38.be) joined #forth 21:05:26 --- join: neceve (~ncv@unaffiliated/neceve) joined #forth 21:32:47 --- quit: nal (Quit: WeeChat 1.4) 21:45:22 --- join: DocPlatypus (~skquinn@c-73-6-60-72.hsd1.tx.comcast.net) joined #forth 22:05:54 --- quit: neceve (Quit: Konversation terminated!) 22:22:15 pointfree, that means forth is homoiconic which is its biggest strength and similarity to lisp. That's also why it's almost always used to build DSLs instead of "apps". 22:23:47 DSLs? 22:24:44 https://en.wikipedia.org/wiki/Homoiconicity -- Forth is prominently missing here. is it just that they felt there were enough examples? 22:24:59 and it is possible, I think, to write Forth in a non-homoiconic manner if I understand the Wikipedia article correctly 22:25:12 it's not a terribly smart idea, but possible 22:29:38 DSL = domain specific languages 22:29:47 I have to run to office now. bbl 22:34:15 --- quit: proteusguy (Ping timeout: 260 seconds) 23:22:00 --- join: proteusguy (~proteusgu@14.207.2.2) joined #forth 23:22:00 --- mode: ChanServ set +v proteusguy 23:42:02 --- quit: lucasaiu (Quit: ERC (IRC client for Emacs 25.1.50.2)) 23:49:10 --- quit: ASau (Ping timeout: 256 seconds) 23:49:33 --- join: ASau (~user@netbsd/developers/asau) joined #forth 23:56:21 --- quit: ASau (Quit: ERC (IRC client for Emacs 24.5.1)) 23:59:59 --- log: ended forth/16.11.01