Chris Double wrote: > The KLF need to realize that TUPLE:'s aren't very common per file.
This isn't black and white. Some problem domains call for an object heavy style. We would be penalizing that style. VOCABULARY NUMBER OF TUPLES state-parser 6 xml.data 11 documents 8 ui.gadgets.gestures 22 parser-combinators 15 xmode.rules 10 > So > the saving of 4 keystrokes here and there per slot for something that > appears only a few times seems not that great. But if you use a > different syntax overloading, or a syntax completely different from > anything else, then the fact that TUPLE: usage does not pop up a lot > (compared to word definitions for example) means the overhead of > remembering what that special syntax is seems to be more of a burden. Go and tally up all the instances of TUPLE: in my code. It's a fact that the number of total instances ever emitted by my fingers and keyboard is a larger number. We coders aren't machines who get tuple design right the first time. When I'm working in a new problem domain, I'm always creating scratch files with experimental tuple designs, trying different ones out. Factor lends itself to experimentation. The syntax should be hacking lubricant. Making the syntax more cumbersome will increase the hacktivation energy necessary to start fires. The true cost isn't estimated by only considering the TUPLE: count per file. We have some long tuples. The issue isn't only how many TUPLE: instances there are, but how many slots. The 'rule-set' tuple from 'xmode.rules' has 13 slots. The keystroke overhead is 52. That seems crazy to me. Try typing 26 " in a row. No cheating; press shift each time. It's not always good to use the argument that since something occurs less frequently, it's impact is less considerable. The problem is that our language is a syntactic ecosystem of *many* things which may not occur with great frequency, but all together have a sum impact. Therefore, we should shave fat off of each element so that the whole is not a beast. If we let tuple syntax get fat here, let method syntax get fat there, etc, you'd start to feel the effects. (By the way, the new method design is wonderful and moves in a good direction) I'd like to keep tuple syntax, and all syntax, lean and mean. Ed ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
