Re: Ideas for next Eu
On Wed, 10 Nov 1999 22:36:57 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>From: Everett Williams <rett at GVTC.COM>
>Subject: Re: Ideas for next Eu
>
>
>>
>> In effect, you are asking the interpreter to do automatic selective
>> sub-sequencing based on arguments to a function. With proper
>> structure naming, this would be a lot less necessary, but still very
>> nice. Intuitive, too...which in my world makes it even more desirable.
>
>As long as functions _can_ return objects, then it really seems
>rather lame to not take advantage of that feature in every way possible.
>Being able to select a portion of the normally returned object would often
>be preferable to receiving a complete structured variable, and having to
>break out the part(s) you are interested in using from that variable in a
>later step.
>
>There's nothing in this that would preclude a function call sans the extra
>arguments, so functions could still be used just as they are currently.
>
>Irv
Agreed, now how do we get the manager of this hotel to provide us
with the items that we have requested? It seems that many of these
functions..er..items have been known and requested with some fervor
for quite some time by a decent number of the discerning clientele.
Either they can't, they don't want to, or they think that spreading out
to other platforms will gain them more than completing the language.
Right now, they have a language sufficiently elegant to attract a coterie
of devoted followers. However, because of the narrow focus of what
so far has been done on the language, a great deal of the code
generated by programmers working in it has been for the purpose of
hacking their way through the jungle to Assembler and C. Even for
those purposes, the tools are so incomplete as to render much of the
code as peeks and pokes, or to put it in another way, back to ye olde
machine code. That seems a horribly inelegant way to spend one's
time. The libraries being written are great work, but terribly vulnerable
to rather minor changes in the environment or the language. And a
great deal of the code will not survive without great pain in the next
generation of processors. At the very least, programmers should have
sufficient tools to easily communicate with other programs of
whatever origin, and use data of whatever origin or type. Resorting to
machine code should happen only through interfaces, never through
direct code. External code should be self contained and independent
of Euphoria. At the very least, it should be created separately and
then loaded and branched to by interface, even if that
interface is unique to Euphoria. If one wishes to write an assembler
in Euphoria, I think it is well suited to that purpose. But, separate it
from Euphoria. Have tools to build and package routines to that
interface I spoke of earlier. Write all those routines in Euphoria if you
wish. Then, when the change in environment comes, the only
routines that will have to be re-written will be external to "working"
Euphoria code. The tools only have to be rewritten once and the
routines dependent on local architecture were already known as
items that would have to be rewritten.
Oh well, dismount soap box and save wind for other days.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
