OpenEuphoria

Re: A question about certain language features

• Posted by Igor Kachan <kinz at peterlink.ru> Feb 12, 2002
• 646 views

----------
> > > 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'?  What is the 'bad thing'?  I also note
> > > that standard Pascal does not allow variables to be
> > > initialized when they are declared.
> >
> > There is good article by Travis Beaty about this point.
> > Visit please:
> > http://www.RapidEuphoria.com/hotnew.htm
> > There is the link to that article in this html.
> 
> Hmmm.  I read the article, but I still don't understand why:
> 
> function foo()
>   integer a
>   a = someNastyComputation()
>   -- lots of code that massages a snipped
>   return a
> end function
> 
> is ok, whereas:
> 
> function foo()
>   integer a = someNastyComputation()
>   -- lots of code that massages a snipped
>   return a
> end function
> 
> is 'dangerous'? (if it were allowed, which it is not)

Your question is just about this
catastrofic, terrible, weird difference
as:

integer x=5 -- not supported

against:

integer x x=5 -- supported

Yes ?

But you can write in Euphoria

constant a=1,
         b="good luck",
         c={1,{1,{1,{1,2,3,45678999999.01},"foooo"}}} 


I do not understand your problem at all, I'm sorry.
I think, thing with integer x above is like to a storm
in a cup of tea. Sorry again.

But real problem is the *initialisation* of variables
and run-time control of that initialisation,
Travis, in his article, explains the real problem,
solved in Euphoria, not a problem of some individual taste.

> > > 2) No support of call by reference.  I understand that call
> > > by reference can lead to unexpected side-effects, but since
> > > changing global variables in a subroutine seems to
> > > essentially cause the same problem, I don't understand this
> > > omission.
> >
> > No any side-effects here with the *globals*. If you'll
> > reference to gobal name from inside subroutine, then you
> > change just that variable. Private variable name override
> > global and local names inside subroutine and exists
> > only inside subroutine.
> 
> integer a, b
> 
> function foo()
>     a = 5
>     return 6
> end function
> 
> a = 1
> b = foo() + a
> 
> See what I mean?  Even though call by reference is not
> allowed, you can still have unexpected side effects, because
> global (e.g., not local to a subroutine) variables can be
> modified inside a subroutine.

Yes, I see. But that example above has no some real sence, I think.
That example above is just like to my one below:

integer a
a=1
a=2
a=3
integer b
b=3
b=2
b=1

? a*b

Why not, if you do want such a thing ?

> > > 3) No support for local constants.
> >
> > There *is* full support for local constants in Euphoria.
> > Terms are: global - for a different files scope,
> > local -- just for single file scope, private -- just for
> > current subroutine scope.
> > *Private* constants are not supported, becouse of *all*
> > private variables exist just inside soubroutine.
> > Local constants are very useful for cross-routine use
> > inside the library file. Say, you have global functions in
> > the include file. You can set *local* constants just for
> > those global functions just inside single lib.
> >
> > See and try Local <--> Private <--> Global,
> > thing looks just like to the real life.
> 
> I think we are not talking about the same thing.  I am
> referring to the reference manual, which says, in section
> 2.4.1, under heading "constants":
> 
> "Constants may not be declared inside a subroutine."

Dear Ed, if you want be talking about EUPHORIA, please
be talking about EUPHORIA, welcome !

But if you want say *WE* are not talking about
the same thing now, you are wrong, I think,
I'm sorry, but life is life.

Inside a subroutine, in EUPHORIA, only PRIVATE variables
may be declared. These points are in the reference manual.

> 
> Thanks for your reply!
> 

Thanks for your interest !

Good luck !

Regards,
Igor Kachan
kinz at peterlink.ru