OpenEuphoria

2. Re: My comments

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Feb 28, 1998
• 927 views

|> * There is a new documentation file, PERFORM.DOC with lots of
|>   tips for performance-obsessed programmers.
|
|        This will help me dramatically.

8-) What about a history ?
So I can have multiple versions of a program to run with different versions
of Euphoria.

|> * A new -clear_routines option of bind and shroud will leave the
|>   names of all routines unshrouded. This is necessary if your
|>   program calls routine_id(). You'll be warned if you use
|>   routine_id() and do not choose this option. (Registered users
|>   can use -scramble together with -clear_routines to restore a
|>   high level of shrouding.)
|
|        Good. although I don't use routine_id() yet. It will be
|helpful to many.

Yes, I use it a lot, altrough I have no need to bind any program.

|Setting values at declaration:
|        integer x = 5
|
|I feel it will complicate the code and make the interpreters job harder.

Your right.
It adds nothing, yet makes it harder to learn Euphoria.
Yet, this is something that you don't have to learn.
Still you are able to understand this right away. (the integer x is set to
5) (oh.. x is thus an integer and it is initialised at 5)

I won't have anything against this, but it sure shouldn't be on top of the
priority list.
When will built-in port functions be available. They should be. (yes
built-in, it can then make use of Euphoria's fast stack-based system)

|The following is an excellent Idea BUT I feel that it makes the code harder
|to read.
|   variable = function( self, value )

    Yes, it makes it harder to read.
    No it is not an excellent idea.
    It's a dumb idea.
    Consider this OOP version (that's what you want:)

    my_var.my_proc (value)

    Now in the case of for example append.

    sequence my_text1, my_text2

    my_text2 = my_text1
    my_text2.append( "Yabbadabadoe")

    Instead of:

    my_text2 = append(my_text1, "Yabbadabadoe")

    Or having this:

    my_text1 = append(self, "Yabbadabadoe")

    Instead of:

    my_text1 = append(my_text1, "Yabbadabadoe")

    So you want to save 4 characters typing to add a whole new line in other
cases. (non trival cases maybe)
    No, you can still do "my_text1 = append(my_text2, "Yabbadabadoe")

    So there will be two methods that will do the same thing. (self - or
repeat var-name)

    That doesn't save any time at all! Making a language more complex will
make debugging time increase like hell.
    With Euphoria you can write a full program in no-time, why ?
    Because you ussually only have two catch one or two syntactic errors,
and one or two logical errors.
    The procces of your program is very straitforward and simple.
    Adding this complexicity to Euphoria, will make Euphoria harder to
learn, slower to write programs in and adds no real value. (what can you do
what you couldn't before ? I rest my case: Not very important)

    Why is everybody so lazy at typing ?
    Euphoria has a lot of typing overhead, yet programs faster than ANY
other language.
    Because you won't have to scan your programs for hours finding that '}'
or searching for that place that you messed up. (which you can't find,
because you forgot which method you used for this problem, and thus can't
use the search function. Only one method/way should be available, so you
always know what to look for)

|The following saves keystrokes. But I don't like its readability.
|I don't think it is worth it.
|   a =+ 1

Nope, maybe it saves typing time, it again increases debugging time and
thinking time.

|> Currently, the environment variable EUDIR contains a single
|> directory specification, which is used by Euphoria to determine
|> the location of include files.
|>
|> I think it would be nice to allow this variable to contain
|> multiple directories, _ l_ PATH.
|
|I think this Idea should be considered. Either that or having the
|Euphoria search the PATH after searching EUDIR.
|None of my extra includes are kept in the euphoria directory.
|Doing so would make it very difficult to install the next release
|of Euphoria.

Yes, this doesn't hurt any1, isn't hard to implent, yet helps a number of
people out.

|I saw the following format used in PERL.
|   { x, y } = get_position()
|It took me a moment to get use to it but I find that it would
|be very useful. Another example:
|   {BMPpalette, BMPimage} = read_bitmap("bitmap.bmp")

    This increases readablity, and how weird it may seems, it makes Euphoria
easier to learn.
    I know I've tried to do this in a program, when I used got Euphoria.
    (from CompuServe BTW, I think you got a lot of users because you posted
Euphoria there..)

|My personal Opinion on the following:
|        variable = variable[6..end]-- end meaning length(variable)
|I hate it. I don't exactly like having to type length(variable)
|every time but it is much more readable. It makes deciphering
|somebody else's code, or better yet Code that I built ages ago,
|much easier to understand.

    Aggreed!
    Again... two ways to do the same thing.
    Lets start by adding the things we can't do.
    Then its complexicity <-> typing-speed case should be considered.
    I suggest some of the typing speed obsessed people out there take a
typing class instead of asking for type-saving complexicties.

|My opinion on base-0.
|I would like to have the option of 0-base but it would crash all
|existing code. The only way to prevent it from crashing existing
|code would be the following: with base-0
|I suggest not doing it.

    Well, you can't mix base-0 include files with base-1 and the visa versa.
    If this is implented, with and without should have the optional keyword
global.
    (With global it will apply to all includes from that point, without the
global in front of it it can only effect the current file)

|I would actually like to see the use of an operator for power.
|But as you said; power isn't use that much.

    Yes, it would be more consistent. Mathimatical operations that need to
values, use operators, those that will only need one, use a built-in
function.
    Example:

    not (1) instead of not 1
    2 ^ 6 instead of power(2,6)

|procedure foo() end procedure
|                        VS
|procedure foo() {}
|
|I actually prefer the extra typing. It serves as a reminder when
|I get to the end of the procedure/function that I should or
|shouldn't return a value. I know that sounds like a weak argument
|but consider that you are Rewriting OLD code. And that near
|the end of the code you start wondering again. Is this a procedure
|or a function. You can simply move to the END of the code or to the
|beginning.   ALSO it is much easier to spot "end function" than it
|is to spot }. one thin little character can be easily overlooked.
|It could lead to an accident such as:

    I can't even image some1 wanting this ?
    Why not introduce pointers ??
    You think the extra debugging time this will bring is less that the time
saved by the less typing ?
    Than your either a VERY VERY slow typer, or a VERY VERY VERY fast
debugger.

|procedure vs. function:
|I am use to the BASIC's I like have function and procedure separated.
|It allows the reader to quickly see that it will/won't return a value.
|It should/shouldn't be assigned to something.

    Ignoring a return value is like returning 0 at a divide by zero.
    It shouldn't be allowed, because it can never be the intention.

|compare()
|Ah.   I think everyone should just get over it.
|compare() is the most logical method.
|The only other idea I have is to implement eq, ne, gt, lt instead.
|I really don't want that to occur. It looks to much like ASM.

    If an '=' has different means in an if-statement that it would mean that
the actions inside if should be recursive:

    text = "Euphoria !!! Cliche example text !!\n"
    if text = '!' then
        count = count + 1
    else
        puts (1, text)
    end if
    ? count

    Will display:
    --
    Euphoria  Cliche example text
    5
    --

    Or at least some recursive construct to avoid to restriction of routines
for recursion:
    Example:
    text = { "Yes", { { "no", "No' , } , '!' } , '!' }
    recursion text do
        puts (1, text)
    end recrusion

    Will display "YesnoNo!!"
    It should have the extra option:

    recursion text by sequence do
        puts (1, "Text')
    end recursion

    Will error because the last element of text is an atom instead of a
sequence.
    And the second element of the second element is an atom rather than a
sequence.
    What about this:

    recursion text by sequence do
        text = "bang"
    end recursion

    Or maybe a recursion construct isn't the way.
    What about a recursion type ?

    recursion my_rec (sequence x)
        if sequence (x[1]) then
            recurse x
        else
            return x
        end if
    end recursion

    Or as an option like:

    recursive sequence text

    puts (1, text)

    Which will call the procedure puts for every sequence found in text.
    (was it defined with recursive atom text, it would have been called for
every atom found !)

    So text can have any level of nesting (recursive says that) but a
sequence is the lowest level.

|global exception handler
|This is definitely needed.

    Well, an exit-routine is needed.
    To close the soundcard device when you Euphoria crashes with an
error-message for example!


Ralf