00:00:00 --- log: started forth/10.09.21 00:06:28 --- join: Deformative (~Joseph@205-36.adsl.umnet.umich.edu) joined #forth 00:10:13 --- quit: Guest58028 (Ping timeout: 276 seconds) 00:13:21 --- join: Joseph (~Joseph@205-36.adsl.umnet.umich.edu) joined #forth 00:13:47 --- nick: Joseph -> Guest83209 00:16:12 --- quit: Deformative (Ping timeout: 252 seconds) 00:31:16 --- join: Deformative (~Joseph@205-36.adsl.umnet.umich.edu) joined #forth 00:35:09 --- quit: Guest83209 (Ping timeout: 272 seconds) 00:36:25 --- quit: Deformative (Ping timeout: 272 seconds) 00:42:32 --- join: Nobody_1707 (~mdmorri1@adsl-240-132-37.msy.bellsouth.net) joined #forth 00:43:05 I just noticed something, but I think it's a mistake on my part or someone would have brought it up by now. 00:44:41 If you change SYNONYM so it's syntax is SYNONYM old-name new-name then it can be implemented in standard Forth, albeit not very efficiently. 00:45:56 http://www.pasteit4me.com/view/1159001/Synonym%20in%20standard%20Forth?.txt 00:46:31 Does someone see any reason why this wouldn't work? Aside from reversing the previously excepted syntax? There must be one. 00:50:32 Anyone? 00:53:01 Someone. 00:54:33 lol 00:55:23 So, do you see any reason why the version of SYNONYM I provided isn't portable, aside from the fact that it's syntax is reversed? 00:55:52 Which isn't a portability problem so much as a standardization problem... 00:59:31 Nobody_1707: what do you think? 01:01:53 --- join: Snoopy_1711 (Snoopy_161@188.107.197.46) joined #forth 01:04:07 Well, I can't see anything, but it seems so obvious that I can't bring myself to believe that no one would have pointed it out already if it worked. 01:04:25 Which is why I wanted a second opinion. 01:04:37 not everything has to be pointed out 01:05:16 --- quit: Snoopy_1611 (Ping timeout: 276 seconds) 01:05:42 True, but SYNONYM has already gotten to a CfV and you would think that this sort of thing would be brought up during the RfD. 01:08:51 Nobody_1707: compile, isn't portable. 01:09:08 Really? I thought it was standard. That would explain it... 01:09:30 Sure. 01:09:52 http://lars.nocrew.org/dpans/dpans6.htm#6.2.0945 01:09:56 And there's big problem with your way to create alia, 01:09:57 No, it's definitely in core ext and I'm making sure it's only called in compilation mode. 01:10:03 6.2.0945 COMPILE, 01:10:04 compile-comma CORE EXT 01:10:04 Nobody_1707: Interpretation: Interpretation semantics for this word are undefined. 01:10:04 Nobody_1707: Execution: ( xt -- ) 01:10:05 you create immediate words for everything. 01:10:51 Yeah, but immediate words execute in interpretation mode too. 01:11:23 synonym + add 01:11:50 Now all words that check immediate status of word may operate incorrectly. 01:12:19 Ah. Good point. 01:13:06 That explains it. 01:13:28 All these tricks reveal design defects in Forth: 01:13:46 The reference implementation has this flaw too. 01:14:05 support for reflection is nothing but a hackery and ad-hockery. 01:16:11 They might have intended the use of checking the immediacy of a postponed word to be implementation defined, but the fact that the reference implementation says that it is incomplete puts that into doubt. 01:16:23 *synonymed word, not postponed 01:17:14 There's big mental defect in standard committee: 01:17:26 there's noone who can think about concepts. 01:18:06 It shows in SYNONYM in that they can't present model of operation behind it. 01:18:29 If there were operation model of dictionary access, 01:18:41 SYNONYM would be trivial to implement. 01:19:12 You need to extract behaviour associated with word, 01:19:24 including immediacy, and assign it to another word. 01:20:24 E.g. you can treat Forth wordlist like Common Lisp package. 01:20:29 Well, they can't have a standard model of dictionary access since the standard is inclusive of all implementation strategies. That's part of the rationale of standardizing immediate, you need carnal knowledge to implement it. 01:21:31 They can't have standard model of dictionary access because 01:21:31 they have conceptually messy implementations and don't want to fix them. 01:21:50 Implementation strategy has nothing to do with it. 01:22:51 No, they have multiple mutually incompatible implementations running around each of which changes the method of interacting with the dictionary and in what ways you can modify it. 01:23:29 Again, providing abstract model of wordlist access has nothing to do with actual implementation. 01:23:58 Um, okay, now I'm confused. What do you mean by an abstract model of wordlist access? 01:24:01 Except that implementation may be just a mess with hardcoded assumptions. 01:24:18 You can provide API to work with wordlists. 01:24:35 Okay, work with wordlist how? What do you want to do with them? 01:24:56 get behaviour by word, get/set immediacy status, create word given its behaviour, 01:24:58 and so on. 01:25:40 This allows more flexible tools. 01:26:06 E.g. you can implement better tools without depending on unstandardized intricacies. 01:26:16 SYNONYM is one of them. 01:26:37 Nobody_1707: read the threads on synonym? 01:26:45 It's trivial get behaviour, create new word from behaviour. 01:26:46 Nobody_1707: there is a similar version of yours in one of the threads 01:26:49 Not in a while. 01:26:55 There kind of long. 01:27:23 ams: Do you have a link? 01:27:38 http://groups.google.com/group/comp.lang.forth/browse_thread/thread/d9530da1cfce9b04 01:27:45 Thanks. 01:28:41 Well then, why don't you make an RfD for words like, immediate? ( "name" -- flag ), behaviour ( name" 01:28:54 -- behaviour-token ) 01:29:34 behaviour: ( "name" behaviour-token -- compile-sys ) ? 01:29:39 Because even writing such RfD is work let alone designing it. 01:30:17 I have enough work besides it. 01:30:22 Um, the RfD gets you help designing it. All you need is what the words look like, what they do, and why you need them. 01:30:39 Hell, I'll write the RfD for you if you want. 01:31:14 Leave your mail address, if you do mean it. 01:31:22 Okay. 01:31:27 Alternatively, I can leave mine. 01:31:50 To late. 01:38:47 Oh, according to the thread he did mean for the immediacy of the synonym to be implementation defined. He just phrased oddly, and as an ambiguous condition for some reason. 01:39:32 So, aside from the ordering of names, it is compliant with the proposal. Cool. 01:40:16 Now I can right a standard, albeit inefficient version. 01:41:05 It looks messy ad-hockery still. 01:41:20 Ad-hockery in what way? 01:41:38 It doesn't create synonyms. 01:42:01 It creates immediate words for regular ones. 01:42:25 This may lead to unexpected consequences. 01:43:41 Yes it does, but it executes the same code, and, if the word wasn't immediate to begin with, it compiles exactly the same. Yeah, you can't rely on the immediacy of your new synonym without an environmental dependency, but environmental dependancies aren't bad, there documentation. 01:44:47 This difference in immediacy is detected in portable way, 01:45:12 you don't need to know internals of your implementation 01:45:23 to find that two words are not synonyms actually. 01:45:50 Yes, but you can't rely on the difference being or not being there on every implementation. The point is to create words that behave the same without having to rewrite them. 01:46:19 Whether the XT or the immediacy bit is the same is usually unimportant. 01:46:24 They don't behave the same way. 01:46:31 That's the problem. 01:47:20 Not internally, but the users of the word don't care as long as it gives the same output for the same input. 01:47:41 And it compiles optimally, so I don't see the problem there. 01:48:13 Sure, that's why I tell you that this word doesn't create synonyms. 01:48:28 If I write "synonym + add" or whatever the correct order is, 01:49:02 It should add the top to numbers on the stack and leave the result when you use it. 01:49:04 then all my words that use search-wordlist and analyze word's immediacy 01:49:04 Which it does. 01:49:08 BEHAVE DIFFERENTLY 01:49:30 "+" and "add" don't invoke same condition branches. 01:49:32 Yes, because if they didn't then they wouldn't be able to handle the synonym correctly 01:49:57 It's a non-issue/ 01:50:20 It is MAJOR issue with this way of implementing "synonym". 01:50:42 No, it's not. I can't think of a single example were it would actually cause a problem. 01:50:51 It can bite you when you don't expect it. 01:51:31 That's the very problem with standard committee: they lack imagination. 01:51:57 Some immediate words can, but this doesn't cause those problems. 01:52:21 Consider one writes "words" with colours to reflect immediacy status. 01:52:47 Which is either non-standard or very nice editor. 01:53:10 User can't know for sure if the word is immediate on purpose or it is just a synonym. 01:53:39 This may have far-going consequences. 01:55:15 Consider someone writes higher order word, where he tests immediacy status 01:55:34 Okay, in all the systems that I know of that colour words like that, the user chooses the colour when he types the word in. If he wants to compile a word that has been set immediate by setting the colour to compile, then he can. If he wants to execute a word while compiling that hasn't been set immediate, then he can. The colours are essentially shorthands for postpone [ and the like. 01:55:39 e.g. to reject words that have compilation semantics. 01:55:44 E.g. in meta-compiler. 01:56:19 Your pseudo-synonyms behave differently there. 01:56:38 Okay, most meta-compilers don't reject some words, they define their own versions that do the appropriate thing while meta-compiling. 01:56:44 *reject those 01:57:12 This isn't about meta-compiler. 01:57:21 It is about higher order word. 01:57:49 These pseudo-synonyms don't play nice with any of higher order word: 01:58:14 How? 01:58:31 they trigger _different_ code paths everywhere where 01:58:31 there may be the need to process immediate words differently. 01:58:45 Let's try a simple higher order word, like times then work our way up, shall we? 01:59:08 Alright. 01:59:15 Consider I'm writing meta-compiler. 01:59:26 All my regular words deal with target space, 01:59:38 all my immediate words deal with host space. 01:59:58 "+" compiles respective operation for target machine. 02:00:26 When I write "synonym + add", I want "add" to work the same way as "+". 02:00:56 That's not how any meta-compiler I've ever heard of treats immediate words. 02:00:57 Consider I write special word to perform, e.g. relocation on given word. 02:01:05 For starters ( is immediate. 02:01:12 And effects neither space. 02:01:55 : rel bl word find 0> abort" doesn't apply to host words" ... ; 02:01:57 Not to mention IF, THEN, DO, WHILE, etc which are going to be immediate anyway and they compile code. 02:02:06 Then "rel add" doesn't work as intended. 02:02:22 Because "add" is immediate instead of regular. 02:02:39 So is IF and you need IF to work and it has to be immediate. 02:03:06 Nobody_1707: if you haven't seen such, that doesn't mean it can't exist. 02:03:24 How are you going to write a non-immediate IF? 02:03:38 I'm not being sarcastic, I really want to know. 02:03:49 Why do I need to write one? 02:04:21 Anyway, there's simple way: 02:04:40 write greedy conditional, I have one called "(if)" 02:04:52 a b 0 (if) ==> a 02:05:04 Oh. 02:05:07 a b true (if) ==> b 02:05:43 Then you can easily write "['] smth1 ['] smth2 condition (if) execute" 02:06:07 It may seem convoluted, but it has its uses. 02:07:02 Okay, but if your only conditionals are higher order functions then your not writing in Forth any more. Your writing in Factor: http://factorcode.org/. 02:07:21 No, I'm not writing in Factor. 02:07:23 Not that there is anything wrong with that, but it isn't Forth. 02:07:27 It is valid Forth. 02:07:58 The style differs from what regular Forth programmers use to see, 02:08:02 still it is Forth. 02:08:59 The fact that it stops them from writing in their usual style is what makes it not Forth, it's a Factor compiler written in Forth 02:09:28 It isn't Factor under any condition, 02:09:38 the syntax is still Forth and semantics is still Forth. 02:10:01 It doesn't utilise closures nor anything else not existing in Forth. 02:13:11 Okay, Forth is more than just a language. It's also a way of writing programs, your supposed meta-compiler is very much not Forth. When I said it was Factor I meant that as a metaphor. 02:13:35 * ASau`` sighs. 02:13:44 You lack imagination. 02:14:01 Substitute "meta-compiler" with "frobnicator" everywhere above. 02:14:09 What does it change? 02:14:36 It nothing, since that's still not a good way to implement it in Forth if you still want it to be a Forth afterwords. 02:14:43 *It changes. 02:14:49 High-order words are still high-order words and "synonym" is still broken. 02:15:09 How do you know it isn't good way? 02:15:19 It's me writing it anyway. 02:15:50 Because it stops you from using a large number of features already included in Forth, including comments. 02:15:58 It doesn't. 02:16:03 Comments are still there. 02:16:07 Comments are immediate words. 02:16:33 Sure, and they continue to use host variables, like those behind "source", 02:16:41 and host tools like "refill". 02:16:45 ASau``: I'm very amazed by you :) You have time to actually produce code *and* take part in these kind of inane discussions :) 02:16:53 * schmrkc gives ASau`` a big thumbs up. 02:17:31 schmrkc: I'm dealing with bureaucracy this week. 02:17:31 schmrkc: and waiting for long build to finish. 02:17:51 Oh I see :) 02:17:57 What? But you explicitly said that code being compiled by your metacompiler couldn't contain immediate words, how does that work? Do you have a custom interpreter loop? 02:18:14 Substitute "meta-compiler" with "frobnicator" everywhere above. 02:18:36 I'm confused as to when forth stops being forth. 02:18:49 but oh well :) carry on :) 02:18:58 Nobody_1707: It is perfectly valid to reject immediate words when it may be tricky to handle them properly. 02:19:19 Yeah, but a compiler is not one of those places. 02:19:25 Your "synonym" breaks it. 02:20:03 And you have yet to give me a reason why you would implement your metacompiler or frobnicator this way. 02:20:44 Because I thought perhaps several months how I do it, 02:20:44 and decided it should be done that way. 02:21:02 Do you think that you can review all reasons in 5 minutes? 02:22:06 You're language implementor and you should provide reasonably behaving tools 02:22:06 rather than dictate me how I should use one or another particular tool. 02:22:16 No, but I can list all the design discussions that baffle me and you can explain them to me. 02:22:46 Basically, as implementation user I want "synonym" to create real synonyms rather than fake ones. 02:23:45 It should be impossible to distinguish between synonyms 02:23:45 with straightforward "bl word find nip 1 =" 02:24:54 Then ask the guy who wrote it for an implementation, or write one yourself using your systems documentation. But there is no reason why the other one shouldn't work for standard programs. 02:25:10 *it should be "your Forth" 02:25:43 If standard supports broken implementation, it is broken by design. 02:26:40 And I don't agree that it's broken, and I strongly suspect that your "frobnicator" is a poorly designed strawman. 02:26:43 Why did you decide that the metacompiler needed it's own interpreter loop instead of it's own version of : [ ] ; 02:26:47 ? 02:27:10 Inside it's own vocabulary of course. 02:28:31 * ASau`` sighs. 02:28:38 FORGET about meta-compilers. 02:28:53 My frobnicator is the best software written in Forth, 02:29:36 and it's you who are stupid implementor who doesn't 02:29:36 understand why his implementation is broken. 02:29:57 The above is real impression of users. 02:30:48 And Forth doesn't impress anyone with real engineering or 02:30:48 scientific background because of this very attitude. 02:30:58 Okay, so your a troll. 02:31:04 Good to know. 02:31:21 I'm find, do as you do. 02:31:53 Assuming that not everything you said was a troll, do you still want that RfD? 02:32:18 Just don't ask why everyone outside Forth community treats 02:32:18 you as another half-educated Forth lover. 02:32:38 Because that's impression from outside communities. 02:33:43 In 3 weeks I may gather material for RfD. 02:34:41 Okay, that's fine since I'm still up for writing it. Although you seem a lot like Hugh Aguilar. 02:35:39 It's amusing. 02:37:53 You don't understand why design and implementation quality matters, 02:37:53 and thus you bring Hugh Aguilar up to cover. 02:38:17 Have you tried to understand why Scheme is designed the way it is? 02:38:45 E.g. why its designers didn't go with improving Lisp? 02:41:12 Yes. But they didn't then turn around and start saying that all Lisp users are uneducated nor did they try and say that extending Lisp in such a way that you can't write code the Lisp way is still Lisp. Not that Scheme is as different from Lisp as what you described is from Forth. 02:42:19 Oh, do they? 02:42:41 You're confusing pre-Scheme Lisp with Common Lisp. 02:43:28 Ask some Schemers and Lispniks what they think about newLISP, Emacs Lisp and dynamic scoping by default. 02:44:21 I might be, I don't think I've ever seen a pre-Scheme Lisp. And I doubt they immediately start insulting the intelligence and education of the users of other languages. 02:44:57 Try writing in Emacs Lisp. 02:45:21 Enjoy power of dynamic scoping. 02:48:11 I will, thank you. 04:25:25 --- quit: Nobody_1707 (Quit: Nobody_1707) 04:38:07 --- join: Nobody_1707 (~mdmorri1@adsl-240-132-37.msy.bellsouth.net) joined #forth 04:38:42 --- part: Nobody_1707 left #forth 09:05:15 --- join: Judofyr (~judofyr@cC694BF51.dhcp.bluecom.no) joined #forth 09:27:19 --- join: impomatic (~chatzilla@87.115.83.45) joined #forth 10:01:33 ASau``: haha 'power of dynamic scoping' 10:01:42 --- nick: alexand31 -> alexand3r 10:06:31 --- quit: crc (Ping timeout: 240 seconds) 10:08:34 --- join: crc (~charlesch@184.77.185.20) joined #forth 10:59:41 --- nick: Snoopy_1711 -> Snoopy_1611 11:27:10 --- join: qFox (~C00K13S@5356B263.cable.casema.nl) joined #forth 11:30:37 --- quit: Monev (Quit: Monev) 11:46:19 --- join: Monev (~nal@adsl-72-50-82-194.prtc.net) joined #forth 12:22:04 --- join: tathi (~josh@dsl-216-227-91-166.fairpoint.net) joined #forth 12:51:25 --- quit: impomatic (Ping timeout: 264 seconds) 13:01:57 --- join: impomatic (~chatzilla@87.115.83.45) joined #forth 13:48:29 --- quit: qFox (Quit: Time for cookies!) 14:21:49 --- quit: impomatic (Quit: ChatZilla 0.9.86 [Firefox 3.5.13/20100914130356]) 14:29:09 --- join: docl (~luke@97-120-241-117.ptld.qwest.net) joined #forth 14:59:49 --- quit: bakaboo (Ping timeout: 264 seconds) 15:00:28 --- join: LionMadeOfLions (~LionMadeO@70.114.156.242) joined #forth 17:25:42 --- quit: tathi (Quit: leaving) 21:36:11 --- quit: crc (Ping timeout: 240 seconds) 21:37:27 --- join: crc (~charlesch@184.77.185.20) joined #forth 21:42:11 --- quit: crc (Ping timeout: 240 seconds) 21:44:03 --- join: crc (~charlesch@184.77.185.20) joined #forth 21:48:53 --- quit: crc (Ping timeout: 252 seconds) 22:15:50 --- join: crc (~charlesch@184.77.185.20) joined #forth 22:21:14 --- quit: crc (Ping timeout: 265 seconds) 22:27:22 --- join: crc (~charlesch@184.77.185.20) joined #forth 22:32:11 --- quit: crc (Ping timeout: 240 seconds) 22:39:15 --- join: crc (~charlesch@184.77.185.20) joined #forth 22:44:26 --- quit: crc (Ping timeout: 265 seconds) 22:45:42 --- join: crc (~charlesch@184.77.185.20) joined #forth 22:50:31 --- quit: crc (Ping timeout: 240 seconds) 23:12:34 --- join: crc (~charlesch@184.77.185.20) joined #forth 23:18:05 --- quit: crc (Ping timeout: 272 seconds) 23:19:13 --- join: crc (~charlesch@184.77.185.20) joined #forth 23:22:01 --- quit: Monev (Quit: Monev) 23:59:59 --- log: ended forth/10.09.21