Re: Euphoria features
-----Original Message-----
From: Everett Williams <rett at GVTC.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, November 12, 1999 10:32 PM
Subject: 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.
I don't have a problem with stealing from these languages. Especially a
"standard library".
>
>>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.
I don't quite understand what you mean here by "fill in a sequence".
>
>>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.
Just like a programmer must declare her variables I do think that a
programmer should know which procs/functions are included in her program. I
don't mean that she needs to know what procs/functions are called by
included functions, just that of course she should declare the ones she is
using.
I kinda agree with linking names to includes by prefixing, but it should be
voluntary.
>>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.
>
If you have more than a few members of an object, then you should break it
down into sub-objects. Byte flags would have to be checked by code, like
almost any other language out there.
No language can prevent poor programming, just make it easier to program
well.
>>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.
Vertical slicing is needed; I just haven't thought about it much myself yet.
>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.
One of the points I think of Euphoria is getting away from rigid data
description.
>
>Everett L.(Rett) Williams
>rett at gvtc.com
>
J.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
|
Not Categorized, Please Help
|
|
