1. Y1900 Problem, GoTo or GoAway,

Y1900 Problem
============

    No offense, but exactly how dumb is a person actually using two digits
to store a year. Due to our chipset, we can work with values between 0 and
255 or 0 and 65535. By suplying all 4 digits (as you call it) you would
force these morans to use 4 digits, and us normal people, to use 2 bytes.
This means that storing a date would look something like this:

    puts (fhandle, { year, year/256 } )

Instead of:

    puts (fhandle, { year })

Or even:

    puts (fhandle, year)

And off course, those who dont care about space (not nessecarily morans,
many reasons can be found for this:)  would use:

    print (fhandle, year)

Which would work exactly the same with your full date as it would with the
elegant date now..

However the addition of 1900 for those cases where we want to display the
actual value seems complicated for you, not considering the easy of
calculating with the 100 value instead of 2000. Maybe 0,001% of all programs
storing dates, will ever have a data below 1900...

GoTo or GoAway
=============

Again, no offense, but the arguments against Goto's at this point are in a
scale from pathetic to silly. I will deal with them here:

>Have I mentioned that C++ code that doesn't
>use GOTOs is easier for me to understand than QBasic code that does?
>Well, it's true. (When I write the C++ code, using Euphoria style
>thinking, at least. :)

Because C++ code doesnt use goto's it doesnt mean they are not needed.
1) In C++ you can at least jump backwards by using continue.
2) In C++ you have much more control over a loop then you have in Euphoria.
The for statement has a validation expression that is continiously
calculated. It allows any kind of statement block as the last part of the
expression. Etc.
3) In C++ you can define a new scope for a variable at any place, so you
dont get messy with your flag variables (to jump out of multiple blocks) ..
still they *need* to be used.
4) In C++ Goto's *can* be used. And are at some points used.

But this is a sum of the argument made:
I can understand C code that doesnt use goto's better than basic code that
does use goto's ..

Its like saying that blue car over there, goes faster than the red car at
the other side. And then logically assume it must be due to the color.

But the logic continues...

>Well.... You saw that it's torturing us for us to not use GOTOs... In my
>last message on this subject, I asked for an example (codewise was
>implied, at least, it was meant to be) of where using GOTOs would be
>easier than avoiding them. My logic is: Us non-GOTOers can't think up any
>example like that because we beleive none exist. The pro-GOTOers beleive
>it does exist, so therefore should be able to provide us with it. Of
>course, us arrogant non-GOTOers beleive we can easily employ our while
>loops and if blocks to great effect and prove that a GOTO is not nearly
>as elegant or easy to read. (Without an example, we win by default... blink

I'll sum this up:

"We need to avoid goto's because we can not find an example of where they
could be more useful."

First of all, since when do we need to avoid something that we cant find ?
If we cant find any logical use now, how could we ever have a need to avoid
it.
Avoiding something makes assumption that we are heading in that direction.
And then you say we cant' even find that direction!

However, I have already given many pseudo examples in which goto's *are*
very usefull.
When jumping out of multiple blocks of code. You cant use exit () you need
to use flags, or perform the same check. (which at times isnt possible
because the counter in a for loop isnt available after the 'end for') But
thats an ugly hack. Structured goto's are nice. And if we wouldnt have
called them goto's so no1 will confuse them with goto's in basic, there
would be no problem, would there be ?

Consider an Euphoria program, notice that all code is read from top till
bottom. What do we notice, a pretty one-dimensonal program flow, is it not ?
We need to 'fake' a dimension by using flags. (if its a flag, its on the
right track, otherwise on the left ... for example). I really really prefer
goto's in that case.

So, now the complete definition of how goto IMHO should be implemented:

begin:
while some_expression do
    for index = 1 to 10 do

        if this then exit (begin) end if
        if that then continue (begin) end if

    end for
end while

Logically, exit means fall out of the statement block pointed followed by
the label, and continue means jump back to the beginning of the loop. (or
otherwise, continue/redo the statement block.)
Only statement blocks can be labelled.
However, lets introduce a new clean statement called 'block'

block zero do

end block
Blocks's have the advantage that you can exit () and continue () them.

However, this can only happen, from withint the block!
And this might sound a lot c-like, but I wouldnt mind being able to define
new variables inside a block, with a scope reaching from the beginning to
the end of the block.
It would actually be pretty neat.

Ralf -- 'nuff messages for one evening..

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu