Re: Euphoria features
> >Jason Gade wrote:
> >
> >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".
In other words, assign values to the elements of a sequence. The
concatenation is a cute trick. but actually harder to read than comma
delimiters. I am not against it, I just can't see the purpose. On the
other hand, orthogonality between arguments of related functions
is a meaningful goal. We just don't have it and changing it at this
point would break a lot of code. If you want it, you can just build an
include with wrapper functions for the current functions that are not
orthogonal.
> >>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 agree with the voluntary part. The prefixes would be optional and would
only apply to "exposed" items anyway, so the load on the interpreter
would be little different than it already is. Something of the form
xyz include foo.e or include foo.e name xyz
without the prefix would be
include foo.e in either case
As to knowing and declaring functions, a library may contain
literally hundreds of functions and the programmer may need all or
only a few. Having to go back and declare each function before it
can be used is an unnecessary hassle. The interpreter can see
which functions are used and proceed on that basis. If you can
describe some advantage in declaring those functions, I will
reconsider the point.
>
>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.
In many, if not most programming situations these days, the data that
we get to use is determined externally to our program or series of
programs almost by definition. I know how to check bit and byte codes,
but I don't have to have the extra overhead of pulling individual, non-word-
aligned bytes out of a data structure or bits out of a byte if adequate
built in types are available. With no data type smaller than 32 bits in this
language, a lot of code is generated in breaking out and reassembling
bit and byte values. Much of that code makes no logical sense. It is
just transforming from one set of coordinates to another...the type of
thing that a compiler or interpreter optimizes very well.
When I do a get, depending on the input, I may obtain a sequence of
bits, bytes, and words of arbitrary complexity. However many pieces
that I break that down into, I had better be able to tie all those pieces
together into a single structure for the IO function to populate. If I must
parse every stitch of data coming in, the overhead will fast get out of
hand. Much data is defined by standards and interface documentation
that is outside of any language. If I cannot with some efficiency
handle whatever data format is thrown at me, I will again spend
inordinate amounts of time and very "gothic" code handling these
situations.
>One of the points I think of Euphoria is getting away from rigid data
>description.
As long as we are within Euphoria and we, the programmers get to
define all the data for both inputs and outputs, you are right. I wish that
I could say that I have worked on a lot of projects that are that
self-contained. Unfortunately, tain't so.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
