00:00:00 --- log: started forth/16.07.30 00:14:32 --- quit: dys (Ping timeout: 252 seconds) 00:22:39 --- join: dys (~dys@ip-109-44-1-226.web.vodafone.de) joined #forth 01:17:17 --- quit: nal (Quit: WeeChat 1.4) 01:47:37 --- join: ASau (~user@netbsd/developers/asau) joined #forth 02:19:12 --- quit: MickyW (Quit: Verlassend/leaving) 03:02:35 --- quit: wa5qjh (Remote host closed the connection) 03:08:19 --- join: wa5qjh (~Thunderbi@203.111.224.54) joined #forth 03:13:34 --- quit: wa5qjh (Ping timeout: 276 seconds) 04:15:17 --- join: GeDaMo (~GeDaMo@212.225.94.7) joined #forth 04:16:49 What happened to http://www.colorforth.com/ ? 05:03:16 --- join: wa5qjh (~Thunderbi@203.111.224.54) joined #forth 05:10:38 --- join: leaverite (~Thunderbi@121.54.58.145) joined #forth 05:12:04 --- quit: wa5qjh (Ping timeout: 260 seconds) 05:12:11 --- nick: leaverite -> wa5qjh 06:24:56 reepca, what would be wrong with something like :NONAME [ HERE ] LITERAL ; ? 06:25:50 --- quit: karswell (Read error: Connection reset by peer) 06:27:08 --- join: karswell (~user@179.63.114.87.dyn.plus.net) joined #forth 06:42:57 If you want to do the equivalent of create without naming then you save HERE on the stack then just allot and store values 06:43:49 If you want the equivalent of create ... does> without naming then you do the same but also have a separate word for processing the data 06:57:35 I think the thing is he wants an XT that does the same thing as a CREATE'd word would 06:58:29 --- quit: wa5qjh (Remote host closed the connection) 07:03:16 Something like :noname aligned here 0 , ( or whatever data alloted ) ; 07:04:03 what, no, that's nothing like a created word 07:04:42 a created word's stack effect is just to push it's data field address on the stack 07:08:59 Without alloting space it would just be :noname aligned here ; 07:34:52 --- join: proteusguy (~proteusgu@183.89.124.141) joined #forth 07:34:52 --- mode: ChanServ set +v proteusguy 07:39:10 --- quit: proteusguy (Read error: Connection reset by peer) 07:39:39 --- join: proteusguy (~proteusgu@182.232.140.232) joined #forth 07:39:39 --- mode: ChanServ set +v proteusguy 07:46:04 --- quit: ASau (Ping timeout: 260 seconds) 07:47:48 --- quit: proteusguy (Read error: Connection reset by peer) 08:18:01 but here would change every time! 08:18:16 you'd need to compile in the current value of here 08:19:24 --- quit: pointfree (Remote host closed the connection) 08:20:56 --- join: pointfree (~pointfree@c-174-62-81-78.hsd1.ca.comcast.net) joined #forth 08:38:23 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 08:39:14 --- quit: Zarutian (Read error: Connection reset by peer) 08:39:37 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 09:54:55 --- quit: gravicappa (Ping timeout: 240 seconds) 10:44:18 --- quit: Zarutian (Quit: Zarutian) 11:02:58 If I do create a1 create a2 then a1 and a2 would give a different value every time 11:04:12 Your version would give the same value every time it was called because the here which is used is from when the word is being compiled 11:14:31 but yours would give a different value, and write to the data space, every single time the xt is run 11:14:43 that's not the same execution semantics as a created word 11:14:45 Which is what create does 11:15:20 if you do "create a1" then "a1 a1", the 2 values pushed to the stack will be the same 11:15:34 Yes 11:16:00 if I did yours, and executed that xt twice, it would push 2 different values to the stack 11:16:11 hence, your xt is not the same as the xt of a created word 11:16:25 Mine is equivalent to creating two different words but without names 11:17:05 no, it's giving you the address of a space in the data section 11:17:10 that's not the same 11:17:12 Sorry, mine is equivalent to calling create but without a name 11:18:20 Unless reepca says something we don't really know what it is they want :P 11:20:38 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 11:31:53 I understand what yours is trying to do but I can't think of a portable way of doing it right 11:37:13 ok, first off, aligned here makes no sense 11:37:20 you are killing the stack 11:37:28 here aligned might be better 11:38:11 Your right, align is what I meant 11:38:15 ^You're 11:38:25 lets just ignore address alignment though. If I run your xt twice, and I've defined code words inbetween, I'll get 2 different values 11:38:33 align would be illegal there 11:38:39 Why 11:38:40 ? 11:38:46 you can't mess with the data pointer in the middle of defining a word! 11:38:59 align adjusts the data pointer! 11:39:04 I'm not, the word is not immediate 11:41:09 ahh, interesting, this forth has no align word 11:41:13 seems broken 11:41:16 but moving on 11:41:48 it's still broken in that if you run your xt twice, with code words in between, you get 2 different values 11:41:58 that's not what the xt created by the create word does 11:42:20 Yes, mine is closer to running create twice 11:42:36 The problem with yours is that the value it returns is in the middle of the compiled word 11:47:54 --- join: hellcode (~hellcode@189.180.134.186) joined #forth 12:04:05 --- quit: Zarutian (Quit: Zarutian) 12:08:39 Vendan: bwahahaha! 12:08:39 variable (nameless) 0 (nameless) ! 12:08:39 : nameless here (nameless) ! 0 , :noname (nameless) @ s" literal @ ;" evaluate here (nameless) @ ! ; 12:09:42 Actually, you don't need to store 0 in (nameless) after creating the variable 12:37:40 --- part: DocPlatypus left #forth 13:11:24 Sorry for the long wait, summer afternoon naps and all - what I'm trying to do is to get an "anonymous" word that has data associated with it, a lot like a closure in other languages. When is the header created in the dictionary? Is it as soon as : parses the name? In that case, the only difference between what Vendan suggested and what I'm thinking of would be something about being the start of a new contiguous region or something like 13:11:26 that - something only CREATE does, I think? 13:12:10 reepca: I believe the code I posted above will do what you want 13:13:03 Calling nameless will give you an xt which when executed will give you an address 13:18:59 --- join: nal (~nal@adsl-64-237-232-29.prtc.net) joined #forth 14:13:09 --- join: byteflame (~byteflame@c-71-238-242-230.hsd1.ar.comcast.net) joined #forth 14:22:36 --- quit: GeDaMo (Remote host closed the connection) 14:34:25 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 14:40:40 --- quit: hellcode (Quit: leaving) 15:09:26 --- join: wa5qjh (~Thunderbi@203.111.224.48) joined #forth 15:41:32 --- quit: DGASAU (Ping timeout: 244 seconds) 16:13:00 --- join: hellcode (~hellcode@189.180.134.186) joined #forth 16:48:37 --- join: mnemnion (~mnemnion@2601:643:8103:f9d0:6d54:4d22:c6d3:7340) joined #forth 16:48:57 --- quit: mnemnion (Remote host closed the connection) 16:49:33 --- join: mnemnion (~mnemnion@c-98-207-249-139.hsd1.ca.comcast.net) joined #forth 16:53:54 --- quit: mnemnion (Ping timeout: 258 seconds) 16:58:17 --- quit: karswell (Remote host closed the connection) 16:59:34 --- join: karswell (~user@179.63.114.87.dyn.plus.net) joined #forth 17:24:42 --- quit: wa5qjh (Remote host closed the connection) 17:37:35 --- join: wa5qjh (~Thunderbi@203.111.224.48) joined #forth 17:39:02 --- quit: hellcode (Quit: leaving) 18:33:11 --- quit: byteflame (Ping timeout: 265 seconds) 18:47:47 --- join: byteflame (~byteflame@c-71-238-242-230.hsd1.ar.comcast.net) joined #forth 18:48:41 --- quit: byteflame (Client Quit) 18:49:14 --- join: byteflame (~byteflame@c-71-238-242-230.hsd1.ar.comcast.net) joined #forth 18:49:18 --- join: ASau (~user@netbsd/developers/asau) joined #forth 18:53:45 --- quit: byteflame (Ping timeout: 244 seconds) 19:24:41 --- join: hellcode (~hellcode@189.180.134.186) joined #forth 19:30:27 hello 19:30:57 hello 19:31:05 I am wondering, if I read Thinking Forth, instead of Starting Forth, will I be missing out on much? 19:31:45 on much of the magic of forth? I like Thinking because it applies to general concepts 19:32:20 if you don't know much about forth, a lot of stuff will be confusing, although i'd say at least half of Thinking Forth is concepts that could be applied generally 19:33:39 it's been said by some that forth is more of a philosophy than a language, and Thinking Forth tends to look at that aspect. 19:36:08 I guess I'll start by Thinking 19:36:11 thanks 19:36:53 if you see something that you don't understand, do feel free to look it up. the gforth manual's word index is a handy place to ctrl+f for information about various words http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Word-Index.html#Word-Index 19:40:07 cool! thanks 19:40:23 thinking forth has a very quick intro 19:40:59 it merely discusses words, so I don't know if there's other fancier stuff (probably so) that I should know about 19:41:07 you know, like how lisp has macros? 19:42:38 forth is really quite simple 19:43:01 but extremely flexible 19:45:21 forth metaprogramming is kinda more complicated than lisp's macros because you have direct access to the compiling process. So it's difficult to write words that have the same effect in a compiled word as in interpret mode. 19:46:02 forth metaprogramming is imperative ("compile this into the current definition") rather than lisp's functional metaprogramming ("return this new code") 19:46:04 that doesn't sound so simple! o_O 19:46:16 it's a different kind of simple 19:46:39 mmm I better read then 19:46:50 one of the things that first blew my mind was HYPE 19:47:08 which is a OO "extension library" written in forth 19:47:17 it's really simple to understand at a low level, but not necessarily as simple at a high level - at least, not when your mind is used to the way other languages do it 19:48:14 24 (rather terse) lines of code is enough to add a simple OOP implementation to a standard forth 19:50:45 kay, so.. I should learn the whole of forth first? 19:50:46 agh 19:50:51 Im confus 19:51:10 (by the whole I don't mean the whole but all those strange qualities) 19:54:28 it's... complex 19:54:40 the first step is to forget most of what you know about programming 19:54:41 I thought it was simple 19:54:48 cause most of it doesn't apply to forth 19:54:55 and will lead you down bad paths 19:55:32 forth is a simple language, at it's roots 19:55:52 and therein lies most of the issue, cause most languages nowadays are rather complex 19:55:57 to insanely complex 19:56:03 in comparison 19:56:35 heheh 19:56:37 you'll have to track stack effects, and get ready to mentally juggle the stack 20:01:09 well it's interesting 20:03:40 I can use the return stack for storing stuff with non-definite loops, right? 20:15:21 ... apparently not. 20:22:34 --- join: gravicappa (~gravicapp@h62-133-162-230.static.bashtel.ru) joined #forth 20:23:43 well, thanks for all the advice 20:23:55 I sleep , bye bye 20:24:03 bye hellcode 20:24:16 --- quit: hellcode (Quit: leaving) 20:32:51 --- quit: pointfree (Remote host closed the connection) 20:34:23 --- join: pointfree (~pointfree@c-174-62-81-78.hsd1.ca.comcast.net) joined #forth 20:38:09 --- quit: pointfree (Remote host closed the connection) 20:50:09 --- quit: Zarutian (Quit: Zarutian) 21:13:32 --- join: mnemnion (~mnemnion@c-98-207-249-139.hsd1.ca.comcast.net) joined #forth 21:14:05 hey Vendan, you still awake? 21:15:31 I'm wondering if there's a way for me to get rid of the "2drop 2drop" after this loop http://pastebin.com/yK5P59sk 21:24:59 wait, what's parse-word return, stringaddress count kind of thing? 21:25:23 and what do you feed this, an xt? 21:25:42 --- quit: wa5qjh (Remote host closed the connection) 21:26:41 --- join: wa5qjh (~Thunderbi@203.111.224.48) joined #forth 21:33:21 --- quit: mnemnion (Quit: Leaving...) 21:34:21 reepca, ^ 21:37:12 yeah, i feed it an xt 21:37:19 it occurs to me I should have put some stack comments in there 21:37:45 and yeah, parse-word returns a character-count on top and an address underneath it 21:37:48 seems interesting, is it applying the xt to the stringaddress count of each word in the "block" 21:38:19 --- join: mnemnion (~mnemnion@2601:643:8103:f9d0:9021:50ec:16da:73f7) joined #forth 21:38:35 the word as a whole is a way of generically taking some action on each word in some input stream terminated with ] 21:39:16 the idea is to make it easy to factor out parsing words 21:39:26 yeah, it's seems pretty powerful 21:39:47 I can't say I know of any "better way" of ordering the loop 21:39:53 --- quit: mnemnion (Remote host closed the connection) 21:40:24 so if I have some defining word named define-foo, instead of saying "define-foo foo1 define-foo foo2 define-foo foo3" I can say "define-foo[ foo1 foo2 foo3 ]" 21:41:19 and define-foo[ is : define-foo[ ['] define-foo postpone do-parsing[ ; or something? 21:41:42 I'll just hope that the inefficiencies get optimized out or are relatively insignificant 21:41:52 yeah, only do-parsing[ isn't immediate 21:42:05 ahh, k 21:42:06 so it doesn't have to be postponed 21:42:19 I might be stealing that :D 21:42:59 forth is even easier to load data / configuration stuff than lisp 21:43:21 as long as you can trust the input, but that's a problem they both have 21:43:23 I've got some places where I have a bunch of postpone'd words 21:43:36 and I'd love to replace that with some kind of postpone[ ] block 21:44:02 yeah I saw something like that in the gforth sources somewhere, that's probably where I subconsciously got the idea from 21:44:06 but yeah, you pretty much have to have 4 things on the stack at the end of that 21:44:16 so gotta drop 4 times 21:44:59 2drop should ideally be defined as some kind of "add 2 cells to stack pointer" in assembly, so it should be relatively fast 21:45:20 I can't make up my mind whether I like having the length as a separate parameter or included in the memory more 21:45:31 stack manipulation is relatively easy when you can treat each conceptual "thing" as a single cell 21:45:45 meh, but the benefit is massive 21:45:51 from a speed perspective 21:46:27 parse-word can just read and return the 2 values. Otherwise it needs a buffer and has to copy and all kinds of crap 21:46:38 yeah 21:47:24 maybe if I made some synonyms, like calling rot 1-2swap 21:47:48 would be cool to have an "object stack" extension, where you could put multiword "objects" on the stack and it'd be treated like a single item in the stack 21:48:04 would be complex though 21:48:33 Especially when objects of different sizes have to interact 21:49:28 well, one idea would be to just store "objects" on the stack as a pointer to the actual object 21:50:09 yeah, but it'd require an extra level of indirection. 21:50:18 yeap 21:50:53 you'd basically have to have some sort of static typing scheme to do it without the indirection 21:53:42 --- join: byteflame (~byteflame@50.25.160.41) joined #forth 21:54:33 do any non-subroutine-threaded forths do register allocation stuff? 21:55:02 no idea 21:55:07 but I kinda doubt it 21:55:29 part of the reason is it's massively easier for STC to do it 21:55:55 cause STC is call DUP call MUL call PRINT 21:55:57 that kind of thing 21:56:27 first optimization is to say "well, DUP is pretty darn simple, so just inline it" 21:56:31 and then inline mul 21:56:46 then peephole them and say "why is this going through the stack" 21:57:03 that's actually encouraging. if gforth has been constantly loading stuff from memory and it's still within a factor of 3 of C, subroutine-threaded forth should be quite fast indeed 21:59:53 I don't know what gforth's threading model is 22:00:06 direct / indirect 22:01:39 yeah, that's what it looks like 22:02:53 I personally write indirect threaded usually, but that's just for simplicity 22:03:43 one thing I don't understand is why other interpreters are so slow 22:03:53 is it the extra overhead of the language model? 22:04:15 python for example is wayyyy slower than even direct/indirect-threaded 22:04:40 well... forth is *not* an interpreter 22:04:46 it just *has* an interpreter 22:05:00 once it's been parsed, it's compiled 22:05:22 python and such get down to bytecode, and there's some stuff with JIT'ing it 22:05:29 but the language is also much much more complex 22:05:53 there are languages that get extremely insanely well optimized 22:05:56 like luajit 22:06:03 that thing is insane 22:06:21 True, but the compiled form is still executed with an interpreter (except subroutine threaded code). Wouldn't, for example, a python interpreter be much more simple using threaded code? 22:06:29 it'll take lua code down to almost as fast as c 22:06:54 hehehe, the "interpreter" in direct/indirect code is dead dead simple 22:06:58 --- quit: wa5qjh (Read error: Connection reset by peer) 22:07:12 it's really unfair to call it an interpreter, really 22:07:26 as far as python 22:07:27 that's true, but I don't see why python/others wouldn't use the same idea 22:07:38 "a.b" is an extremely complex operation 22:07:53 involving checking a hash table multiple times 22:08:01 and all kinds of other crap 22:08:19 just a single "get field b of object a" 22:08:51 --- join: wa5qjh (~Thunderbi@203.111.224.48) joined #forth 22:08:57 it's cause python is an extremely dynamic language, and also, imo, a badly designed one 22:10:12 for example, you could make a class that has a method __getattr__ 22:10:41 now, for the interpreter to actually evaulate a instance of that class to see if it has a field, it has to call that method 22:11:23 and so, the interpreter has to check to see if the object has a method __getattr__ before it knows it needs to call it 22:11:23 but wait a minute, isn't that metehod itself an attribute of that instance? Or no? 22:11:30 it is! 22:11:34 it's also magic! 22:13:05 it's also just poorly designed, imo, as lua has many of the same features 22:13:25 but luajit optimizes `a.b` type stuff down to 3 opcodes 22:14:39 wait, an entire search of a hash table and a load in 3 opcodes? 22:14:48 is one of the opcodes a procedure call? 22:16:00 nope 22:16:09 luajit is freaking godlike 22:17:50 I'm not sure whether that makes me want to give up any research into compilers and just say "just use luajit for everything" or whether it encourages me seeing how fast a dynamic, high-level language can be made 22:20:55 well, while luajit is amazing, LLVM isn't shabby either 22:21:28 building a language that outputs to LLVM IR or whatever can give you an immediate massive boost in optimization 22:22:18 another interesting thing: http://terralang.org/ 22:22:34 it's basically LLVM and luajit mixed together 22:24:35 At last, something I can smugly say "well lisp can do that better" to. 22:25:11 lol, well, probably so 22:25:16 Actually, I wonder how well lisp metaprogramming forth would work. Not forth-on-top-of-lisp, but metaprogramming forth with lisp 22:25:19 but I know lua, and I don't know lisp 22:25:33 yeah, that seems to be the common case 22:27:01 forth is about my "oddest language" 22:27:33 well, it's been fun talking, but it's 1:30 am 22:27:38 and I need to get some sleep 22:27:49 alright, good night 22:27:55 night 23:34:46 --- quit: wa5qjh (Remote host closed the connection) 23:42:44 --- join: wa5qjh (~Thunderbi@203.111.224.48) joined #forth 23:58:35 okay, so I just found out that parse-name (which I also just found out is a gforth-specific word) doesn't parse past line breaks. It just returns 0-length strings. *scratches head*. In fact, in gforth, you can't have the name of a colon-definition on a different line than the one the colon is on. I can't believe I never noticed that before. Maybe it's just used to reading from blocks? 23:59:59 --- log: ended forth/16.07.30