Euphoria features
- Posted by Jason Gade <jgade at NETZERO.NET> Nov 12, 1999
- 581 views
First, let me say that I love the simplicity of Euphoria (I even like the abbreviation of 'U4' that someone came up with.) Second, let me say that I have never written any large projects. I have been planning on writing a Euphoria 'Rogue' clone for nearly a year now, and never did follow through with my 'CoreWar' ideas which Rod and others inspired in me. Now, on to *my* ideas. First off, I think that Euphoria is very cool the way that it is. Although namespace needs to be addressed, programmers need to find the language's true paradigm before trying to make it into C or Java. The infamous construct of xy = get_position() position( xy[1], xy[2] ) should never have been begat. The most Euphorian solution should have been for position() to take a sequence as a parameter list instead of integers. xy = get_position() position( xy ) I am even thinking (though not convinced) that functions and procedures should *always* take one parameter, and that '&' should replace ',' as a parameter separator. position( x & y ) Although I don't know object orientation very well, I do believe that Euphoria should lean in that direction. Mainly polymorphism ( I think that that term is correct ) where functions and procedures take values that make sense to them. So, for my ideas to additions: { line, column } = get_position does make *some* sense to me. Not wholly in favor, but not against it either. I need more convincing. My other idea, for namespace, is as follows: --foo.e include bar.e import var1, var2, var3 --you could even use a 'type' identifier (such as integer, atom, sequence, user-defined) if you *must* import constant CONST_I, CONST_II, CONST_III import func_one, func_two, proc_three The import keyword would make these identifiers global to the file. If the file was included, then it would be *just* within that file. If the file was the main program, then it would be the entire program (after the import statements). The main idea is that the programmer should *know* what is being included in his/her program. An alternate would be an 'export' keyword, which would put the onus on the include file programmer to decide what should be exported. I think that the 'type' declaration can adequately handle structures, but it would be longer to program than in other languages. type employee( sequence empl ) if length( empl ) = 4 then if sequence( empl[1] ) then -- last name, could use string type if sequence( empl[2] ) then -- first name, could use string type if atom( empl[3] ) then -- salary, could use float type if integer( empl[4] ) then -- years in service, could use type return TRUE end if end if end if end if end if return FALSE This would trap bad structs, but it is cumbersome. There may be a better way. Also, if speed is a consideration then it would only apply to dev, alpha, or beta programs. Then you should have 'without type_check' if your source is stable. I think that routine_id() is okay, but that it should be global. This can facilitate OO, and it could even do away with my proposed 'import' or 'export' keywords. It should be combined with variable_id() though, even though I would loathe to see pointers in Euphoria. It could be useful in overriding scope when necessary. I can forsee a Euphoria in which most 'objects' are defined in separate include files that contain functions for working with that object. Object-oriented, but not in the non-flexible way that most OO languages are defined. Sequences are very powerful, and I think that we haven't even scratched the surface yet in their utility. __________________________________________ NetZero - Defenders of the Free World Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html