OpenEuphoria

Re: Hello

• Posted by Derek Parnell <ddparnell at bigpond.com> Dec 09, 2002
• 593 views

----- Original Message -----
From: "Gabriel Boehme" <gabrielboehme at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Hello


>
> I hope Rob doesn't mind if I copy his excellent
> explanation as to why "integer var = val" isn't permitted in Euphoria.
>
> Also, don't hesitate to use the "mailing list search" on the Euphoria
> website, as answers to this and many other questions can be found that
> way (that's how I found this).
>
> Cheerios,
>    Gabriel
>
>
> Date: 12 Feb 2002
> From: Robert Craig <rds at RapidEuphoria.com>
> Subject: Re: A question about certain language features
>
> Ed Davis writes:
> > 1) Variables can not be initialized when declared, but
> > rather, must be initialized via an assignment statement.
> > Based on other languages, this seems like one of those
> > convenience type issues.  Is there some programming
> > philosophy that says that an initialization in a declaration
> > is a 'bad thing'?
>
> It's not a "bad thing". In fact it seems like an obvious bit of
> convenience that couldn't possibly cause any harm.
> Since a lot of people have asked lately, here is my
> (very subjective) opinion on the matter. I've also
> included your question about private constant declarations.
>
> Suppose we allow:
>
> #1.  variable inits:  integer x = 99
>
> and if you allow #1, it would be even stranger (than it is now)
> not to allow:
>
> #2.  constants declared inside a routine for use within that routine
> only
>
> So now you've got routines that start off with an arbitrary mixture
> of variable and constant declarations, some of the variables
> are assigned an initial value, some aren't. The only visual difference
> between a constant declaration and a variable declaration, is
> that people have to remind themselves that "constant" is not a type,
> it's something totally different. e.g.
[snip]
>Now whenever you examine a routine, instead of quickly skipping
>over the declarations, you will have to carefully
>wade through all the declarations, some containing
>function calls and complicated expressions, to figure out
>which code is going to be executed.
>
>Simply stated, you've got executable code hidden amongst the
>declarations, and constant declarations now look no different from
>variable declarations. Things used to be neatly separated and
>you could visually skip the declarations when mentally tracing
>execution. Now things are jumbled together.

Ahhh, so that's why we can't use executable code to assign some constants
and not others, and why we can't mix executable code and variable
declarations outside of routines. Its all so clear now.

----------------
cheers,
Derek Parnell