Re: Euphoria features
Jason Gade wrote:
>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.
Well at least you shouldn't be encumbered by any preconceptions.
>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.
Nobody here wants it to be in C or Java, but it sure would be nice to
be able to steal what those languages have without the mess they have
it in.
>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 )
Agreed, but this is a matter of programming, not language design. It can
be easily resolved with a little tiny piece of code.
>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 )
Then, you also need to convince yourself that you want to fill in a
sequence before every procedure or function call that you make...I
don't think so! Also, individual variables in a function or procedure
call tend to explicitly document that call if the variable names are
reasonably chosen.
>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.
The alternate view, is that a programmer should not have to know what
is in every include to use it. If the functions are well documented and the
variables and functions are uniquely identified by prefixing, No conflict
can occur.
>An alternate would be an 'export' keyword, which would put the onus on the
>include file programmer to decide what should be exported.
Import and export both require study and intimate knowledge of variable
use in a program and in all it's includes. Let us assume that you are a
maintenance programmer called in to fix this program that you have
never seen before. Now also assume that this program is holding up
something critical like your payroll check. Tell me how much time you
want to spend checking out every include before you add an extra
variable to this program. After my first few years in this business, I
came up with the "two o'clock rule". If it is not going to be easy to
figure out at two o'clock in the morning 6 months to two years after
I have written it or last seen it, then I shouldn't write it. If I follow that
rule, then at least the poor devil who isn't me and never has seen it
before will stand a chance of working on it.
>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.
And how is this type of thing going to describe the umpty hundred bit and
byte flags in the average message header, no matter the protocol. They
have to be literally unpacked one by one and then moved into a different
sequence or atom before they can be intelligently maneuvered. And
since the data stream is dynamic, and treacherous, I really need for
type checking to stay on. Can you spell Methuselah...the guy whose
age you will approach while all this gets done.
>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.
It is hard to disagree with the thoughts here, but until you have specific
ideas, it is hard to comment.
>Sequences are very powerful, and I think that we haven't even scratched the
>surface yet in their utility.
If you look at some of the code in the archive, you will see that this pack
of hens and roosters has done a whole lot of scratching. Granted that
there is a huge amount of power here. The thread on vertical slicing,
otherwise known as columns, is a good beginning for extending the
implicit power of the data description in the sequence to real use in
programs.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
