1. Information Overload

I'll be gone for the next 2 weeks, after the two weeks i'll receive
all those zillion messages send... that would take me a couple of
days to read, but it will be fun
        Well, just to let people know..

        And about the SPAM, everybody responding on it is even worse,
althrough i must admit i can understand you all being upsed. I can't
be like that, i'm going on a 2-weeks vacation to Grech!! =)

        Something you can all discuss when i'm gone:
        Their are suggestions to the Euphoria Language:
        (It is long, skip it if you're not interested in suggestions for a
new version of euphoria)

        * Get rid of integers, atoms & floats:  Lets make sequences &
info. Sequence is how it is organized (just like now) and info is the
data that is actually stored. It can take up up *ANY* number of
bits. You can use 'tablize' them, that is assigning the way it can
be cut/sliced. You can make it an multidimensional table with items
of as many bits you want. The number of total bits can change
dynamically, but is not effected by the 'tablizing'. That just sets
how to slice the data already in memory. You can perform operations
on the whole 'info' or on a part of it. You can change its intire
organization by 'tablizing' that just compiles the next to executed
code differently. This is great for look-up-tables, or anything were
we are messing with a WEIRD datatype. You need to convert bits to a
sequence to edit them, which takes up at least 4 bytes for each item.
And it slows it down a lot as we are actually only changing a few
inbuilt parameters.
        * Compiling statements like #IF DEFIND and macro's would be really
nice, constants needed to be saved in memory while executing, but
they should be replaced while compiling. (I think they are, but i am
not so sure).
        * When a .E file is included for the first time, it's code is
compiled and immidiate statements are executed. If it is included
again, it is just ignored, i think it should call a procedure (if
available) like 'init' or something. So the code should only be
compiled and the immidiate statements should only be executed the
first time, however if a procedure 'init' is available is should be
called whenever the file is included (Also the fist time thus)
        * we should be able to slice or random acces anything that
represents a sequence, as well as function calls, or comparisements
(like ({3,4,5} > j)[2] = 'r') Another example is (gets(1)[2..end] =+
1)
        Look at the second example, it containes end (which is a shortcut
for the length of the sequence returned by gets(1)). Normally you
would have to save this in a sequence variable. The '=+'
automatically ADDS 1 to all values in the sequence. It creates very
compact and efficent code. (PS next to '=+' we would also have all
the others like '==' and '=!=' and '=*' and '=-' and '=/' etc.
        * we should be able to include routines in a NEW INLINE close-to-asm
but-far-away-from-the-computer-specific-stuff language for use with
our ASM code. Code optimized for a 386 runs a lot slower than code
opitimized for a Pentium (on a Pentium) however that code will not
run on that 386!! If the code would be compiled (like the rest of the
EU code) it will generate the BEST machine code for THAT PARTICULLARY
processor, os, monitor, keyboard, grandmother whatever. * extend
slicing.. that is algoritm slicing, having special slice routines
that include and exclude members of a sequence (till any depth) This
way the old slicing method would just normally work (you just specify
a name or symbol the that slicing routine) but also all the other
custom ones. Some people wanted EU to use a sequence to slice it,
well they can just write their own routine, the maximum flexibility i
think.
        * With an assignment where we slice the sequence that is going to
store the value we need to be able to specify 2 sources. That is
something like this: " s[2..3] = 3  | 5"
        Now s[2..3] = 3 and the rest of s will be 5. We seperate it with the
'|'


        Enough.. i am browsing with more... but i have bored you all enough.
        You can discuss about these ones until i get back.
        They are practical, aren't they and they CAN be easily implended.
(well it doesn't look impossible to me)
        Please some1 respond...
        What do you think of these suggestion, Robert Craig?
        I'll like to hear other ideas too, any1 got any new ideas ?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
~~~~>> Ralf Nieuwenhuijsen <<~~~~
 ~~~>> nieuwen at xs4all.nl <<~~~~

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu