00:00:00 --- log: started forth/13.06.27 00:00:01 write tests ? 00:02:26 tangentstorm: What do you mean? 00:03:18 and the beauty with jtag and gcc is the easy debugging one can do 00:07:57 ttmrichter: like instead of debugging write challenge response tests for what you want the output to be given certain input. 00:08:26 i mean you'll still have to debug stuff but testing up front seems to make things jump out at you 00:08:37 tangentstorm: Sorry, I'm not a TDD devotee. 00:08:49 like if you run the test suite constantly. you catch the bugs immediately. 00:09:03 And what I like JTAG for is seeing the dynamic behaviour of the system live as it happens. 00:09:09 Something that doesn't happen with tests. 00:09:13 why not? 00:09:33 Because I'm a DDT devotee. 00:10:52 aee they the guys with long white robes and tousled beards ? 00:11:05 those DDT devotees ? 00:11:27 No, those are wizards in Middle Earth from Lord of the Rings. :) 00:11:56 (Yes, I realize Gandalf was "the Gray" but that's just because people were too polite to tell him that his personal hygiene was terrible.) 00:12:01 ok 00:12:01 when i write my virtual machines the first thing i do is write debuggers and things to visualize what's going on in the system 00:12:01 but i still tend to reach a point where i've got bugs that i would have avoided could find easier if i'd just written tests.. and then i go back and write tests :) 00:12:01 but that's just me 00:12:13 hahahah, fast .... 00:12:33 I write tests of things that I'm pretty sure are going to be problematical. 00:13:11 The whole "write all your tests first, then code" meme, however, is something that could only have come from the mind of someone who made Yet Another CRUD Application (or its modern incarnation: the eCommerce site). 00:13:17 I think ttmrichter likes the thrill of one on one combat with new cpus 00:13:57 As an example of where TDD utterly and completely fails: setting the clocks on one of these F4 chips. 00:14:11 That code is going to be REALLY hairy and no amount of testing is going to help me beyond "yep, it failed". 00:14:28 Terrible Dastardly Documentation = "TDD" ? 00:15:04 That's where being able to peer inside the chip to see what's actually going on has few credible alternatives (even if that "peering inside" is done via instrumentation rather than debugging). 00:15:24 i don't write -all- my tests up front, and i do more like spec tests than unit tests... i look at input and output of the whole system. 00:16:01 like if i'm testing a compiler i write a program in the language and run the generated code and test the output of the program that ran... 00:16:16 Ah, well then that's not TDD. Good. 00:16:19 That's closer to DDT. 00:16:23 my tests don't know anything about what's in the compiler 00:16:41 sometimes i write unit tests too 00:16:52 Of course. When you need to. 00:17:07 I object to the mindless meme, not to unit tests (or integration tests (or system tests)) in general. 00:22:16 * tp lurks in the shadows, watching software titans clash 00:24:52 I'm more a Gimli the Dwarf. 00:24:53 i think i just misunderstood your statement about debuggers 00:25:31 i thought you meant you saw the appeal of a proper debugger because you were in a nightmare debugging situation and wished you had one 00:27:51 --- quit: goingretro (Ping timeout: 248 seconds) 00:32:26 Gimli was fearless! 00:35:20 --- quit: jyf (*.net *.split) 00:36:01 --- quit: bluekelp (*.net *.split) 00:36:41 --- quit: cfjdet (*.net *.split) 00:36:51 --- quit: cataska (*.net *.split) 00:37:05 --- quit: tathi (*.net *.split) 00:37:14 --- quit: djinni (*.net *.split) 00:37:15 --- quit: nottwo (*.net *.split) 00:37:28 --- quit: Tod-Work (*.net *.split) 00:37:45 --- quit: ttmrichter (*.net *.split) 00:40:10 --- join: cfjdet (~androirc@pD9E2572E.dip0.t-ipconnect.de) joined #forth 00:40:10 --- join: cataska (~cataska@210.64.6.233) joined #forth 00:40:10 --- join: Tod-Work (~thansmann@50-202-143-210-static.hfc.comcastbusiness.net) joined #forth 00:40:10 --- join: tathi (~josh@216.227.91.75) joined #forth 00:40:10 --- join: djinni (~djinni@li125-242.members.linode.com) joined #forth 00:40:10 --- join: nottwo (~trannie@nottwo.org) joined #forth 00:40:10 --- join: jyf (~root@42.96.194.66) joined #forth 00:40:10 --- join: ttmrichter (~ttmrichte@gertm.eu) joined #forth 00:40:10 --- join: bluekelp (~bluekelp@bluekelp.com) joined #forth 00:40:10 --- mode: calvino.freenode.net set +v tathi 00:43:58 tangentstorm: That's possible. I have the unusual opinion that in general debuggers are useless. 00:44:21 I so rarely fire up a debugger that when I do I have to crack open the manual for them even to do basic operations. 00:44:30 For me to find something NICE about a debugger is rare. :) 00:44:36 :) 00:45:10 But being able to see the registers, the disassembly, etc. of a system in operation is a nice feature. 00:45:54 For small 8-bit CPUs (my major area of embedded work in the past) it's not as valuable; instrumentation is faster and can give you a more accurate picture. 00:46:08 But with the ARM ... it's a bit big to instrument. 01:12:29 --- quit: tangentstorm (Quit: WeeChat 0.3.2) 01:25:16 "The Internet portal is developed using a combination of Java (J2EE) / .Net and Mainframe (COBOL and PL1) technologies." :O 01:27:37 Which Internet portal is this? 01:28:30 Skandinaviska Enskilda Banken's portal 01:28:46 * c00kiemon5ter going through job ads 01:29:01 http://www.vedelit.com/WorkForUs/tabid/83/jpid/147/language/en-US/Default.aspx19:28:28 01:29:03 That particular job sounds like almost a personification of Hell. 01:29:23 it is mobile app dev position :P 01:29:31 A mobile app. 01:29:33 With COBOL. 01:29:35 And PL/I. 01:29:58 I think it'd be fun 01:30:40 :P :P :P :P :P :P :P :P : P: P :P :P :P :P :P :P :P :P :P :P :P:p:P:P:P:p:p:P:p:P:p:p:P:P:P:p:P:p:P:p:P:P:p 01:31:07 PL/I can be fun. 01:31:15 Nothing done in COBOL ever could be called fun. 01:31:26 COBOL was designed by a committee specifically to suck the fun out of EVERYTHING. 01:31:39 You could write porn in COBOL and it would not be fun. 01:32:04 * ttmrichter quickly checks to make sure that prickly, pompous twit isn't here to be offended. 01:51:56 lol 02:08:25 --- join: epicmonkey (~epicmonke@host-224-58.dataart.net) joined #forth 03:04:29 --- join: proteusguy (~proteusgu@ppp-58-8-107-13.revip2.asianet.co.th) joined #forth 03:53:00 --- quit: yiyus (Ping timeout: 245 seconds) 03:59:28 --- join: yiyus (1242712427@je.je.je) joined #forth 04:38:07 --- quit: yiyus (Read error: Operation timed out) 04:46:17 --- join: yiyus (1242712427@je.je.je) joined #forth 05:08:12 --- nick: itsy -> John_Metcalf 05:21:45 --- quit: Bahman (Remote host closed the connection) 05:31:56 --- join: nighty^ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth 05:50:07 --- quit: newcup (Read error: Operation timed out) 05:51:06 --- quit: Inode (Read error: Operation timed out) 05:51:33 --- quit: nighty- (Read error: Connection reset by peer) 05:51:49 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 05:52:38 --- quit: yunfan (Read error: Operation timed out) 05:52:49 --- join: Inode (~inode@time.uk.chromedpork.net) joined #forth 05:55:37 --- join: yunfan (~root@unaffiliated/yunfan) joined #forth 05:57:37 --- quit: proteusguy (Read error: Connection reset by peer) 06:05:49 hello there 06:06:59 Hello. 06:12:36 any chatty folk which wants to explain me internals of gforth? 06:13:00 (or any other decent forth implementation) 06:14:07 I can point you to an article about implementing Forth that covers a variety of techniques. Would that help? 06:14:24 --- join: proteusguy (~proteusgu@ppp-58-8-96-246.revip2.asianet.co.th) joined #forth 06:14:36 maybe 06:15:15 first of all I wonder how are multiple stacks handled by the implementation 06:15:26 http://www.bradrodriguez.com/papers/moving1.htm 06:15:52 I'm not sure what you mean by "how are [they] handled". 06:16:54 ttmrichter: considering the memory in a flat model, you could use one end of the memory address space to allocate stack 06:17:01 and leave the other one for the heap 06:17:33 but that doesn't apply for multiple stacks, I think 06:17:41 The parameter stack is not going to need a lot of space. 06:18:02 64 cells deep is more than enough. If you're using more than that you're not doing it right. 06:18:09 (Hell, 32 should be enough.) 06:19:47 ttmrichter: so you say the solution* is to divide the user space among the stacks, right? 06:20:03 User... space? 06:21:30 If you're talking about some kind of multi-tasking system, you'd deal with the task-specific stacks the same way you deal with them in any multi-tasking environment using any language. 06:21:41 You allocate stack space for each task and go from there. 06:24:41 ttmrichter: sorry, address space 06:24:48 my brain is melting 06:25:18 Well, yeah, then, that is indeed the solution. But I think you're missing on just how shallow the parameter stack should be. 06:25:52 yeah, probably the division is not homogeneous 06:26:30 The Forth 83 specification, for example, mandates a return stack of 48 bytes. 06:26:32 That's the return stack. 06:27:15 We're not exactly talking about a resource-intensive thing here. 06:27:54 You could get a pretty impressive 16-bit Forth program running inside of about 8KB. 06:28:11 That would get larger for a 32-bit machine, but still nowhere near problem levels. 06:31:06 ttmrichter: so the size of the stacks is guaranteed by the standard? 06:31:54 The minimum size is defined by each standard, yes, I think. 06:32:19 (Of course I'm of the philosophical bent that says "Standard Forth" is a contradiction in terms...) 06:39:30 ttmrichter: any info about how words dictionary is implemented? 06:39:55 Usually just a linked list. 06:40:13 With field:bytes: 06:41:22 length:1|name:length|linkfield:pointersize|codefield:???|parameterfield:???|NEXT 06:41:37 The link field is used to point to the next word in the dictionary. 06:42:03 --- join: RodgerTheGreat (~rodger@50-198-177-185-static.hfc.comcastbusiness.net) joined #forth 06:42:20 The code field is used to point to the code that's actually executed for this word (which is a routine in the interpreter for threaded words and the parameter field in a code word for typical implementations). 06:43:26 The parameter field is typically a list of pointers to the code fields of the words used to implement the word in a threaded word, the actual code being executed for a code word or some other parameter for things like variables, constants, etc. 06:43:56 I'm being very hand-wavy because the four major ways of implementing Forth change all of that. 06:44:17 mmh 06:44:18 So if I described it for indirect threading and you looked at a token threaded Forth you'd get confused. 06:44:34 I see 06:44:51 so my last question is going to be tricky to answer 06:45:19 Well, the actual dictionary is just a linked list of word implementations in most cases. 06:45:27 here is is anyway: how do I use assembled* code with forth? 06:45:46 *it 06:46:04 Going with indirect or direct threading, it works like this: 06:46:06 The interpreter reads the code field. 06:46:25 In indirect threading this is a pointer to a routine that will get executed. 06:46:39 In direct threading it's a direct jump or call to said routine. 06:47:07 Either way, in a "compound" (threaded) word, that pointer/jump will be ... back into the interpreter. 06:47:37 But for a "code word" (a word implemented with its own code instead of a list of words) it's a pointer to/jump to the parameter field. 06:47:52 So the code field tells the interpreter where the next executable block is going to be. 06:48:16 If you're implementing a primitive word in assembler, that executable block will be inside the word implementation (the parameter field) itself. 06:48:28 in a subroutine-threaded forth all definitions consist of machine code so it's even easier to understand (imo) 06:49:15 but then you lose the ability to do a few spiffy tricks wherein you patch the inner interpreter to do things like trace execution or profile subroutine calls, etc 06:49:16 Yeah. Subroutine threading is elegant. 06:50:28 I was considering subroutine threading for my Forth Stick thing, but decided to go with direct threading instead. 06:51:11 most of my forths have been subroutine threaded 06:51:29 I just hate the ARM approach to calls. 06:51:37 why? 06:51:49 In saner processors you have a "call ". 06:52:00 The stack stuff is part of the instruction discipline. 06:52:29 So you would call the word, it would call and so on and so on until something actually gets executed, then a string of single RET instructions gets you back. 06:52:46 In ARM you have "branch with link" which puts the return address into a register. 06:52:58 ttmrichter: ah, just like MIPS 06:53:10 You have to manually push and pop that register if you're going to go deeper than one subroutine. 06:53:14 RodgerTheGreat: Yeah, exactly like MIPS. 06:53:24 I'd do ITC in MIPS too. 06:53:26 so you have to secure the address manually 06:53:28 yeah 06:53:40 Because having to do the stack discipline yourself manually is just INVITING error. 06:53:53 (And it costs more space to boot.) 06:54:32 You lose, in short, the elegance that makes STC so appealing. 06:54:48 I believe the rationale in mips is that it allows for a more flexible calling convention (on leaf functions, for example, you don't need to use the stack at all) and since mips has no true stack a "call-save-pc-and-write-through-sp-and-increment-sp" would be a very complex instruction 06:55:01 (complex compared to other mips instructions) 06:55:30 RodgerTheGreat: Oh, it's a fine idea. But it's CLEARLY targeted at being automated by compilers, not being done by hand. 06:55:39 yeah 06:55:45 the downfall of many modern architectures 06:55:53 And, bluntly put, I don't trust myself to not make stupid mistakes. 06:56:11 who does? 06:56:21 A straight branch to target with a branch back through NEXT is far less error prone than something that requires me to manually push and pop a key register EVERY GOD-DAMNED TIME. :) 06:56:30 ErhardtMundt: inexperienced programmers 06:56:34 ie most programmers 06:56:38 Zed Shaw. 06:56:56 Zed Shaw. 06:56:56 I don't think even zed shaw is that arrogant 06:57:29 (I like to hold Zed Shaw up as the Platonic Form of inexperienced programmers. He hasn't had over a decade of experience in writing software. He's had one year of experience over ten times.) 06:57:33 http://zedshaw.com/#/start 06:57:36 what's that? 06:57:38 klingon? 06:58:17 I have no idea. It's the product of a combination hipster-huckster. 06:59:16 I think he's entertaining purely because he rips on ruby programmers so much 06:59:33 they need all the criticism they can get 06:59:40 See, the problem is that he *IS* a Ruby programmer at heart. 07:00:01 It's where he started and it's where he learnt all of his bad habits (and his arrogance). 07:00:14 And when *I*, of *ALL* people, can identify someone as arrogant ... wow! 07:00:37 you seem to know very well this guy 07:01:14 Someone I know is a big fanboi so I keep getting his crud shoved in my face. 07:01:16 I think ruby is almost the opposite of forth. It's a monstrously complex language filled with special-case logic and kludges which is popular in spite of its insane flaws 07:01:34 RodgerTheGreat: Without looking, guess how many lines of code there is in Ruby's Bison grammar? 07:01:58 10,000 07:02:01 at least 07:02:15 Last I checked it was over 16,000. 07:02:19 Something like 16,800. 07:02:29 This was for 1.8.7 I think. Might have been 1.9. 07:02:41 truly a disease of the mind 07:03:02 people need to learn that "short" programs are not at all the same thing as "simple" programs 07:03:36 Indeed. 07:03:51 As I get older, I appreciate code that does EXACTLY what it says in front of me. 07:04:01 Little to no magic. 07:04:19 and there's a difference between apparent simplicity (like lisp, with elegant and orthogonal features which conceal complexity in the form of GC, etc) and actual simplicity (like a concise assembly routine or a well-factored forth program) 07:04:57 There are times when concealing complexity (like GC) is appropriate. 07:05:04 sure 07:05:08 It depends on how much control you need over your environment vs. your problem domain. 07:05:27 The problem is gratuitous "simplification" for the sake of sparing the developer five characters of typing. 07:06:07 C in particular drives me nuts in this regard. 07:08:54 Oh, Ruby's grammar has been simplified. 07:09:02 parse.y is now "only" 11,000 lines long. 07:09:36 https://github.com/ruby/ruby/blob/trunk/parse.y 07:09:39 Read it and go mad. 07:11:29 ghaaa 07:11:43 This doesn't include the lexer, but I can't recall what the lexer they used was. 07:12:19 why did I expect anything different 07:12:32 Because you're one of these saps that expects the best of people? 07:12:50 maybe 07:13:04 it all depends on the meaning of "saps" 07:14:19 They're using some kind of lexer generator called gperf? 07:15:25 No, I have no idea what gperf is doing to this. 07:15:58 gperf is usually for fast keyword recognition 07:16:04 but I don't think it has any lexing capability 07:16:08 it would have to be post-lexer 07:16:19 it constructs perfect hashes 07:16:20 I have no idea how it's lexing then. 07:16:26 Yeah, that's what I just found out. 07:16:34 I used to know this but my brain mercifully purged it. 07:17:05 I like the idea of gperf but I was a little disappointed with its code generation options last time I used it 07:17:12 I had to do some code post-processing 07:17:48 I used it to generate a hash for http://search.cpan.org/~kulp/Mac-PropertyList-XS-0.02/lib/Mac/PropertyList/XS.pm 07:17:51 :) 07:38:14 http://programmingisterrible.com/post/42432568185/how-to-parse-ruby 07:39:41 at least it has a grammar 07:39:45 unlike Perl 5 07:40:47 not that it's necessarily practically any more usable 07:44:35 There was a time when Ruby was usable. 07:44:54 That was back when the community didn't suddenly start its worship of "spooky action at a distance" through monkey-patching and other such tools. 07:44:58 Basically, pre-Rails. 07:58:26 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59579 07:58:30 Oh. My. God. 08:00:43 yeah I never understood that 08:01:06 Please tell me this is ANOTHER programming language called Ruby, not the scripting language? 08:06:13 --- quit: proteusguy (Ping timeout: 260 seconds) 08:08:12 --- join: proteusguy (~proteusgu@ppp-58-8-96-246.revip2.asianet.co.th) joined #forth 08:15:05 --- quit: proteusguy (Ping timeout: 260 seconds) 08:16:12 --- join: proteusguy (~proteusgu@ppp-58-8-96-246.revip2.asianet.co.th) joined #forth 08:20:41 --- quit: proteusguy (Ping timeout: 260 seconds) 08:33:42 --- quit: epicmonkey (Ping timeout: 256 seconds) 08:35:04 nope 08:35:10 it is the ruby of ruby on rails 08:35:18 well, at least, I heard that Ruby is an ISO standard 08:35:25 I don't know specifically that there are not two Ruby ISO standards 08:35:25 ;) 08:44:12 that's creepy 08:48:53 --- quit: dys (Ping timeout: 264 seconds) 08:59:40 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth 09:00:23 kulp: It appears that you misunderstood me. 09:00:30 I wasn't asking you to tell me the truth. 09:00:41 I was asking you to tell me that this was ANOTHER programming language called Ruby. 09:00:48 I was, in short, asking you to tell me a comforting lie. 09:00:56 * ttmrichter now curls up into the foetal position. 09:03:58 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth 09:07:30 --- join: fantazo (~fantazo@213.129.230.10) joined #forth 09:21:44 lol 09:22:06 btw, this might be of interest to you guys 09:22:46 I haven't read it yet; it came up on #suckless/OFTC by bnwr; it's his thesis 09:22:49 http://www.cl.cam.ac.uk/~rp452/1styrrep.pdf 09:29:19 --- join: mtm (~mtm@c-76-102-52-34.hsd1.ca.comcast.net) joined #forth 09:29:21 ttmrichter: so sorry 09:33:18 takes a while to ge going, but this is interesting reading, c00kiemon5ter ... 09:33:59 --- quit: fantazo (Ping timeout: 248 seconds) 09:35:39 not sure i understand it though :) 09:37:18 then it must be a good thesis ! 09:38:27 it's more like a progress report of his first year working on the thesis 09:39:20 talking about using high level languages like ocaml to .. i guess he's saying metaprogram a subset of c 09:40:19 he mentions that linear lisp language from that "the forth shall be first" paper 09:43:07 no i misread that 09:43:26 he wants to make a dialect of ml that doesn't need any runtime code 09:43:36 RTFML :) 09:46:41 So I guess like ML but without the need for garbage collection and so on. 09:59:42 yeah 09:59:58 a minimal runtime ML, no-gc etc 10:00:15 like freestanding C 10:19:14 --- quit: ASau (Remote host closed the connection) 10:20:45 --- join: ASau (~user@p4FF96B51.dip0.t-ipconnect.de) joined #forth 10:32:14 --- join: cp_ (~cp@talula.plus.com) joined #forth 10:41:10 c00kiemon5ter: "ML-without-GC" requires completely different typing system. 10:44:19 Besides, programming in linear style similar to how Baker demonstrated in that paper 10:44:28 is VERY difficult. 10:48:58 ASau: yeah that's probably why it's worth researching :) 10:49:21 Probably. 10:49:53 The problem is that currently there're only two languages that have linear type support, 10:50:19 both languages are very far away on fringes. 10:50:51 And they surely very un-Forth-line. :D 10:51:34 yeah, it takes a long time for things to trickle into anything approaching mainstream use. or even not-quite-mainstream-but-at-least people have heard about it like forth :) 10:53:20 what do you use forth for, ASau ? 10:53:50 I used it for quick prototypes for some time. 10:53:59 Currently, there's nothing. 10:54:24 (If you don't count legacy code I have written over years.) 10:54:39 well what do you prototype? 10:55:02 Most of the code was written when I worked on real-time audio project. 10:55:49 (I even had working OGG codec once that was written just for fun.) 10:55:53 huh. so like signal processing stuff? 10:56:13 No, only communication part. 10:56:36 like voip? 10:56:42 Like that, right. 10:56:48 cool 11:02:55 As for ML-without-GC, it doesn't differ much from barebone Lisp-1 without GC. 11:04:46 The latter brings you to Baker's paper, and once you try implementing something not-completely-trivial, you'll understand how hard it is. 11:09:08 BTW, you do understand that working with linear types means that you cannot just take two numbers and add them, don't you? 11:11:05 --- quit: cp_ (Ping timeout: 264 seconds) 11:16:19 --- join: ARMWorksiMac1 (~ARMWorksi@173-160-216-166-Washington.hfc.comcastbusiness.net) joined #forth 11:35:11 --- join: ASau` (~user@p4FF9794F.dip0.t-ipconnect.de) joined #forth 11:37:35 --- quit: ASau (Ping timeout: 245 seconds) 11:40:04 --- join: cp_ (~cp@talula.plus.com) joined #forth 11:43:34 ruby started as a more modern syntax for smalltalk but all its exceptions and one-offs make it difficult to grok now - you can't "get" just a few small concepts and extrapolate to the entire system 11:44:10 at least i can't. that's what i don't like about it, or python, now. too many special cases and inconsistencies, imo 11:48:52 --- join: ncv (~quassel@79.114.88.45) joined #forth 11:48:52 --- quit: ncv (Changing host) 11:48:52 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth 11:49:33 --- nick: ASau` -> ASau 12:12:15 ASau: no, i guess i don't. why can't you take two numbers and add them? 12:15:39 Because in linear logic, if you have "1", you cannot just take another "1" from nowhere. 12:16:23 You have to find another copy of "1" somewhere. 12:19:16 This means that you have to follow carefully what logic laws, classical or linear ones, apply to which objects. 12:20:20 bluekelp: if you like smalltalk, you know where to get it, don't you? 12:21:31 oh yeah. i love smalltalk. it's one of the 3 or 4 langs i like b/c they're simple and relatively self-consistent: forth, list, smalltalk -- maybe 'c' but mainly b/c it's a "simple" assembly 12:22:17 and cross-platform. but there are no/few "core" concepts you can extrapolate into higher understanding in c - except perhaps 'pointers' 12:23:37 Pure functional subset of SML is very clean too. 12:24:25 sml = standard(?) ml? 12:24:28 Yes. 12:25:18 Erlang is even cleaner. 12:25:53 how's haskell compare? started to look into it but too busy to get far 12:26:44 Haskell is fine too. 12:27:33 (If you manage to bend your mind to understand it...) 12:37:43 ASau: huh. so there are no constants? that doesn't make sense to me... how would you assign values to things in the first place? 12:38:32 There're constants, but you have to have as many of them as you need. 12:38:39 It is sort of like atoms. 12:39:04 If you have one atom of hydrogen and one atom of oxygen, you cannot make water molecule. 12:40:22 You need two atoms of hydrogen, even though they are identical ones. 12:42:44 You have asked correct question. 12:43:18 It demonstrates quite nice why linear types are not in vogue. :) 12:45:21 i guess i'll have to look at the paper again and maybe read the original thing.. but not today, got stuff to do. :) 12:49:35 The correct answer is that you do not assign values to things. 12:49:51 You assign names to things. 12:51:25 ah that makes sense. 12:52:03 but in that case i think you meant that you can't just add two variables together. 2 + 2 ought to work just fine, right? 12:52:11 Hmmm... :noname leave XT on the top of the stack. But if I do :noname 123 ; : xxx [ compile, ] ; there's some other stuff on the stack on top of the XT. :-( 12:53:06 So I have to save the XT in a temporary variable? 12:53:11 tangentstorm: not actually. 12:53:57 John_Metcalf: yes. 12:54:10 tangentstorm: make it more formal. 12:54:15 :noname is lambda? 12:54:28 Sort of. 12:54:39 tangentstorm: you say that "f(x, x)" works just fine. 12:54:40 push here to stack, compile a function with no header? 12:54:59 tangentstorm: yes 12:55:10 : :noname here [[ ; immediate or something? 12:55:16 oh that's not forth 12:55:23 but something like that.. neat. 12:55:28 Not "here", it points to data area, and :noname is to return execution token. 12:55:31 --- quit: jevin (Quit: Textual IRC Client: www.textualapp.com) 12:55:47 tangentstorm: you say that f(x, x), which means that you use the same object twice. 12:56:04 tangentstorm: if x is of linear type, you cannot do that. 12:56:46 yeah i understand that but i'm saying f(5, 5) should be fine. 12:57:02 x is a name but for literals it should be okay 12:57:17 It depends what literals you're talking about. 12:57:24 i mean i know 5 is a name for a concept too but i don't think that's what they mean 12:57:31 i'm talking about 5 12:57:55 ah man dude this is why everyone thinks you're trolling. 12:58:07 The point is that if you want to do that, you have to introduce normal types in addition to linear types. 12:58:29 Even for such simple reasons as being able to count things without major headache. 12:59:46 The consequence is that simplistic linear typing just doesn't work. 13:00:28 And in order to repair it, you have to introduce at least two different types. 13:01:42 While in classic languages, e.g. Lisp, Prolog, Erlang, you need just one. 13:04:24 One of reasons we need GC is that all those objects that are constructed as "f(x, y)" 13:04:49 are logically "still there". 13:05:06 This is what is called "monotonicity" in logic. 13:06:05 If you want to destroy "f(x, y)" explicitly, then you make a big mess, 13:06:07 because non-monotonic logics are much more complicated. 13:09:00 it does sound like a mess 13:09:15 which makes it more interesting to me :D 13:10:05 I was just trying to write a word to display unsigned single precision numbers like U. 13:10:18 : _x. 0 base @ um/mod ?dup if recurse then dup 9 > if 7 + then 48 + emit ; 13:10:18 : x. _x. space ; 13:10:31 This works. 13:11:51 But I was trying to do it like this. It failed due to the XT not being on the top of the stack: 13:11:54 :noname 0 base @ um/mod ?dup if recurse then dup 9 > if 7 + then 48 + emit ; 13:11:54 : x. [ compile, ] space ; 13:13:15 Don't do it that way. 13:13:35 Use <# #s #> 13:15:01 I've also written it with <# #s #>. The above is just for an example of recursion. 13:15:42 What's the point? 13:16:38 what's putting the other word on the top of the stack? 13:16:50 Forth is not Scheme, you don't need to simulate linear loop with recursion. 13:17:09 tangentstorm: ":" does that. 13:17:19 Or "[". 13:17:25 Both are allowed to do it. 13:18:04 allowed to but it's not specified i guess? 13:19:43 "[ compile, ]" is non-standard too. 13:19:53 John_Metcalf: so you don't need a variable, you just need a word that puts it in the right place... like a ROT that copes with compiling. 13:20:42 aSau: the recursive version is simpler than with a loop 13:20:43 imean you can just juggle the stack yourself but then you're tying it to the particular forth implementation 13:21:21 i still really want to make a forthesaurus, John_Metcalf :) 13:21:57 Tangentstorm: how about as a wiki? 13:22:04 John_Metcalf: : #s begin # 2dup d0= until ; 13:23:24 Anyway, using recursion in this particular case is stupid. 13:24:35 And ":noname ... ; : ... [ compile, ] ... ;" dance is hard to track, is unjustified, and is non-portable. 13:25:16 If you're going with recursion, you can waste another stack frame as well. 13:26:02 Thus, you don't actually need "[ compile, ]" thing at all. 13:26:50 ASau: I have a microcontroller with only 2K flash memory. I wanted to avoid including <# # #s #> hld hold sign 13:27:57 Inline them and use loop. 13:28:30 Even if you have to inline them manually that is better than dancing with recursion. 13:29:33 Besides, in that case you have fixed value of "base". 13:29:44 Thus you can optimize it even deeper. 13:31:41 U. using <# #s #> etc = 190 bytes (including code for <# # #s #> etc). Recursive forth U. as above = 60 bytes. Assembly U. = 49 bytes. 13:32:41 "x." suggests that you're going to type hexadecimal, is that correct? 13:34:02 No, my fault. I just used x. to keep the original u. available while testing. 13:34:38 The main problem is that you don't have tail recursion above. 13:34:47 Thus you're going to waste your return stack. 13:35:23 If you have fixed base, then it is easier to write custom # and write code like 13:35:50 : x. #' #' #' #' drop ; 13:36:39 : #' dup 12 rshift 15 and <#> emit 4 lshift ; 13:38:12 John_Metcalf: yeah i had something collaborative in mind but not quite a wiki.. more like a database 13:38:14 Hmmm... that's neat. 13:39:52 Database? 13:50:46 a database of different forth words in different implementations, along with examples of what they do 13:51:14 Like COMUS? 13:51:19 basically a rosetta code for forths but i like forthesaurus better 13:51:33 Well... I don't think that this is actually useful. 13:52:34 Most words are not part of public API. 13:53:09 Yes, we all know that. You think everything anybody suggests is useless and are always happy to tell us so. 13:53:15 Especially in extremist code like colorForth, Retro, and similar ones. 13:54:09 You think that there're no better options than doing useless things. 13:54:36 I think that you don't have a very good imagination. 13:55:42 Well... 13:55:43 Continue thinking so. 13:55:45 It's useful for /me/ but instead of asking me why my reason for wanting it is, you just assert that you think it's useless. 13:56:14 So... Good for you. :) I don't have any particular need to correct your opinions. 13:57:23 Like I said, everyone in here thinks you're a troll. I don't think you're a troll, I just don't think you know or care how unbelievably rude you are. 14:00:00 tangentstorm is not in here ? :O 14:00:07 syllogism ! 14:01:26 what? :) 14:01:45 oh i got it 14:01:52 yeah i suck at logic :) 14:02:51 Sorry, ASau. I was overgeneralizing. But you must realize that there are people in here that have you on ignore. 14:04:18 You clearly know what you're talking about and seem to be wanting to contribute... That's why I don't think you're trolling... But you come off as really really abrasive and hostile sometimes. 14:05:00 --- join: obobo__ (~obobo@dyn-98-124-31-230.nexicom.net) joined #forth 14:06:18 tangentstorm: All About Forth and The Forth Encyclopedia are both pretty good. 14:08:25 --- quit: obobo_ (Ping timeout: 245 seconds) 14:09:59 they look cool, but reading old books and documents and not being able to translate them to the environments i actually use is what makes me want an online reference in the first place. :) 14:18:17 --- join: epicmonkey (~epicmonke@188.134.41.113) joined #forth 14:20:41 --- join: goingretro (~kbmaniac@host81-129-184-151.range81-129.btcentralplus.com) joined #forth 14:32:13 --- join: jevin (~jevin@72.12.217.220) joined #forth 14:43:27 --- quit: epicmonkey (Ping timeout: 256 seconds) 14:58:46 --- quit: ncv (Remote host closed the connection) 15:16:29 --- quit: dys (Ping timeout: 264 seconds) 15:36:01 --- join: beretta (~beretta@cpe-107-8-120-203.columbus.res.rr.com) joined #forth 15:41:40 --- join: epicmonkey (~epicmonke@188.134.41.113) joined #forth 15:53:59 John_Metcalf: : pass >r ' execute r> ; 15:54:53 `pass :` works for getting stuff past the colon-sys, regardless of what size it is... 15:55:13 and can be stacked `pass pass :` etc. for more than one cell... 16:00:23 This assumes that ":" doesn't put anything on return stack. :) 16:01:22 How can it? It has to return. 16:01:29