Re: Euphoria Interpreter design
- Posted by "Boehme, Gabriel" <gboehme at MUSICLAND.COM> Feb 23, 1999
- 463 views
jiri babor <jbabor at PARADISE.NET.NZ> wrote: >>Euphoria declare-before-use is one of it strong points. It enhances >>redability & conceptual organization. > >Just like the Pavlov's dogs: totally predictable. Sorry, Daniel, but >you and your fellow travellers cannot trot out the same unjustifiable >cliches every time someone asks for a bit of programming freedom, and >get away with it. 'Declare-before-use' principle enhances your >programming roughly the same way a straight-jacket enhances your >mental health. And how running backwards or standing on my head >improves readability of anything is also a bit of a mystery, to me >anyway. And when you finally trap that strange and elusive beast you >call conceptual organization, enhanced or not, please let me know, I >sure want to see it. jiri First of all, you don't get "freedom" by declaring routines anywhere you want, in much the same way you don't get "freedom" from allowing uninitialized variables, invalid subscripts, and invalid parameters. Instead of allowing us the "freedom" to do all of these things, Euphoria "forces" us to do things in such a way that we have freedom *from* many of the mistakes that would result from allowing these things. So there's more to "freedom" than simply doing whatever the heck you want. The only straight-jackets I see are the bad habits we programmers have learned from other programming languages. Pavlov's dogs, indeed. So, leaving aside the emotional appeals and verbal attacks, let's try and clarify the issues here -- examining why declare-before-use is so attractive to begin with, and looking at how Euphoria works now. When I first discovered Euphoria, I found that its declare-before-use method of routine declaration was an invaluable aid to learning how this new language worked. Whenever I was looking at the source code for a Euphoria program, I *always* knew I could find a routine's declaration *before* it was used. I could always find the main routine (whatever it was) at the very bottom of the source code. I always knew that, if a routine was being called from somewhere, that I should look backwards from that location to find the routine's declaration, either within the file or within one of the include files. And I always knew that each succeeding routine was building on the routines declared before it, which certainly seemed intuitive to me -- far more so than the willy-nilly way programmers can do things in QB, C or Cobol. Of course, nowadays in Euphoria you won't *always* find a routine's declaration before it's called -- routine_id() has seen to that. While routine_id() is certainly a necessity for Windows event-based programming, it has also introduced a great amount of confusion into the language where before there was only simplicity. Extensive use of routine_id() can result in some very weird problems that can be extremely difficult to track down, even with trace(). (And I'm speaking from experience here...) Before routine_id() came along, Euphoria's declare-before-use routine declaration made perfect sense with the way everything else in the language worked. Now, with routine_id() blurring the lines, it's more difficult to see the benefits or necessity of declare-before-use. This is most likely why declare-before-use has come under so much attack recently. So perhaps, now that we have routine_id(), we should allow routines to be declared anywhere in the source code, completely doing away with declare-before-use. However, if we allow this, then we must change some other things that Euphoria currently does. An example: ------------------------ procedure some_proc(sequence s) puts(2, s) end procedure procedure Puts(integer fn, sequence s) puts(fn, s & '\n') end procedure procedure puts(integer fn, sequence s) Puts(fn, s) end procedure procedure some_other_proc(sequence s) puts(2, s) end procedure ------------------------ Now, ignoring the impractical nature of this example, we can see that Euphoria's current way of doing things makes sense here -- some_proc() calls the built-in puts() while some_other_proc() calls the redefined puts(). This *only* works because of Euphoria's declare-before-use nature; routine redefinition would be *impossible* otherwise -- some_proc() and some_other_proc() would have no idea which puts() they should be calling, and calling the redefined puts() would result in an infinite, mutual recursion between puts() and Puts(). So, if we're going to do away with declare-before-use, we've got to do away with built-in redefinitions. I don't know how much this will impact other Euphoria programmers, but it would force me to completely change what I'm doing with some of my custom include files I've been tinkering with (far more practical uses than the above example). Maybe I'm the only Euphoria programmer making extensive use of this built-in redefinition ability, but I don't think so. This, by the way, is also part of the basis for the "weird" behavior of routine_id() -- since the built-in routines can be redefined, routine_id() must be called *after* the routine in question has been defined, to avoid the potential ambiguity shown above. So, elimination of declare-before-use would eliminate built-in redefinitions, but allow routine_id() to function a bit more intuitively, perhaps a bit less strangely. So the argument isn't so much a question of which side is right and which side is wrong. It's more a question of weighing the pros and the cons of each side, looking at how Euphoria has changed with routine_id(), and trying to find which approach makes the most sense -- based on the way things are now, and on the way other things in Euphoria would have to change. Not quite as much fun as emotional appeals and verbal attacks, but far more useful if we actually want to arrive at a solution. Gabriel Boehme