1. A question about certain language features
I've been reading the Euphoria documentation, and I have a
few questions about certain features of the language.
I assume that the author made certain choices because he
felt that this encouraged a better way of programming. I
don't want to start (or continue) an argument about this per
se, but I would like to try and understand the reasoning.
For instance, without debating their merit, I can understand
the author leaving out the goto statement, as abuse of goto
can lead to hard-to-read and hard-to-prove-correct code. Of
course, the converse is possibly true too.
The features I have questions about as to why there were
implemented that way are:
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.
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.
3) No support for local constants.
Again, I'm not trying to start a debate, I'm just trying to
understand why these features/omissions are desirable.
Thanks for any information!
2. Re: A question about certain language features
- Posted by tone.skoda at siol.net
Feb 11, 2002
Euphoria is almost perfect programming language as it is now.
It only needs a simple OOP addition.
Of course, debuger and editor with IDE also are missing, but that is not
part of language itself.
Why call by reference, becuase VB has it?
It is complicated feature, I don't need it.
I don't need goto either.
Variables can not be initialized when declared, that is ok.
Local constants are really not needed.
Things I most like with Euphoria: simplicity, sequences, type checking, no
waiting for compilation, speed...
----- Original Message -----
From: "Ed Davis" <ed_davis2 at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 11, 2002 5:39 PM
Subject: A question about certain language features
>
> I've been reading the Euphoria documentation, and I have a
> few questions about certain features of the language.
>
> I assume that the author made certain choices because he
> felt that this encouraged a better way of programming. I
> don't want to start (or continue) an argument about this per
> se, but I would like to try and understand the reasoning.
> For instance, without debating their merit, I can understand
> the author leaving out the goto statement, as abuse of goto
> can lead to hard-to-read and hard-to-prove-correct code. Of
> course, the converse is possibly true too.
>
> The features I have questions about as to why there were
> implemented that way are:
>
> 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.
>
> 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.
>
> 3) No support for local constants.
>
> Again, I'm not trying to start a debate, I'm just trying to
> understand why these features/omissions are desirable.
>
> Thanks for any information!
>
>
>
>
3. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
You wrote on 2/11/02 1:40:26 PM:
>
>It only needs a simple OOP addition.
>
What would that be?
Karl B
-------Phoenix-Boundary-07081998---
4. Re: A question about certain language features
- Posted by tone.skoda at siol.net
Feb 11, 2002
I was not really responding to you but generally writing what I feel about
Euphoria.
Your question should really be answered by Robert Craig, richtig?
I do not know why he did it the way he did.
But I think most of the the things are the way they are for simplicity (no
goto, no local constants, no initialization of variables when declared...)
and for clear programming style.
If Euphoria had some ugly characters like $, &, *, {,} it would become ...
not what it is now.
----- Original Message -----
From: "Ed Davis" <ed_davis2 at yahoo.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 11, 2002 11:39 PM
Subject: RE: A question about certain language features
>
> tone.skoda at siol.net wrote:
> > Euphoria is almost perfect programming language as it is now.
> > It only needs a simple OOP addition.
> > Of course, debuger and editor with IDE also are missing, but that is not
> > part of language itself.
>
> I appreciate your feelings, but I'm not sure what this has
> to do with my original message/questions?
>
> > Why call by reference, becuase VB has it?
>
> I've never used VB. I have used C, C++, Pascal, Modula 2
> and Oberon, all of which feature call by reference (well, in
> C you have to use pointers, but it amounts to the same thing
> in actual use).
>
> > It is complicated feature, I don't need it.
>
> I am happy for you. However, that was not the point. I was
> simply wondering why it was not included. I've read that
> functional languages don't allow call by reference because
> of the side effect factor. But they also (I'm not a
> functional language expert - this is based on my readings of
> the subject) don't allow assignment to global variables from
> a subroutine, because it is a also a side effect. So, I'm
> simply wandering why Euphoria's author choose not to allow
> call by reference. Is it a style issue, a good programming
> issue, is he trying to emulate some tenet of functional
> programming, etc.
>
> > I don't need goto either.
>
> Good for you. But I did not ask about goto.
>
> > Variables can not be initialized when declared, that is ok.
>
> That may be. But I did not ask if it was 'ok', I simply
> asked why it is not allowed. Is initializing a variable
> when it is declared a 'bad thing'? It is supported in other
> languages I have used, and so I was wondering why not in
> Euphoria.
>
> > Local constants are really not needed.
>
> True. But again, I simply asked why the feature was not
> supported.
>
> > Things I most like with Euphoria: simplicity, sequences, type checking,
> > no
> > waiting for compilation, speed...
>
> Again, I am glad you like it, I like Euphoria also. But
> that is not what I was asking about.
>
> And to make sure I'm clear - I'm not asking for these
> features to be added to Euphoria.
>
> For instance, I can see why the author would not choose to
> add a goto to Euphoria. Many programmers realize that
> goto's, used unwisely, can cause hard to
> follow/maintain/prove correct code.
>
> I'm simply trying to understand if in general the author
> feels that call by reference, variable initialization on
> declaration, and locally declared Euphoria constants are bad
> things, or would lead to poor programming style, or what
> have you.
>
> If I know why these things are not allowed, who knows,
> perhaps I will adopt this style for my own use in the other
> languages I program in.
>
>
> > ----- Original Message -----
> > From: "Ed Davis" <ed_davis2 at yahoo.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Monday, February 11, 2002 5:39 PM
> > Subject: A question about certain language features
> >
> >
> > > I've been reading the Euphoria documentation, and I have a
> > > few questions about certain features of the language.
> > >
> > > I assume that the author made certain choices because he
> > > felt that this encouraged a better way of programming. I
> > > don't want to start (or continue) an argument about this per
> > > se, but I would like to try and understand the reasoning.
> > > For instance, without debating their merit, I can understand
> > > the author leaving out the goto statement, as abuse of goto
> > > can lead to hard-to-read and hard-to-prove-correct code. Of
> > > course, the converse is possibly true too.
> > >
> > > The features I have questions about as to why there were
> > > implemented that way are:
> > >
> > > 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
<snip>
>
>
>
5. Re: A question about certain language features
- Posted by tone.skoda at siol.net
Feb 11, 2002
Classes!
include circle.e as circle
circle circle1
circle cirlce2
cirlce1.radius = 5
circle1. x = 0
circle1.y = 0
cirlce2.radius = 10
circle2. x = 5
circle2.y = 5
circle1.draw ()
circle2.draw ()
code above would draw two differecnt circles.
All global variables and routines in include file would be public members,
those not global private.
And I see no reason why such file could't also be used in old way:
circle:x = 20
circle:y = 20
circle:radius = 100
circle:draw ()
----- Original Message -----
From: <kbochert at ix.netcom.com>
To: "EUforum" <EUforum at topica.com>
Sent: Tuesday, February 12, 2002 1:07 AM
Subject: Re: A question about certain language features
You wrote on 2/11/02 1:40:26 PM:
>
>It only needs a simple OOP addition.
>
What would that be?
Karl B
6. Re: A question about certain language features
On Monday 11 February 2002 05:39 pm, Ed Davis wrote:
>
> tone.skoda at siol.net wrote:
> > Euphoria is almost perfect programming language as it is now.
> > It only needs a simple OOP addition.
> > Of course, debuger and editor with IDE also are missing, but that is not
> > part of language itself.
>
> I appreciate your feelings, but I'm not sure what this has
> to do with my original message/questions?
>
> > Why call by reference, becuase VB has it?
>
> I've never used VB. I have used C, C++, Pascal, Modula 2
> and Oberon, all of which feature call by reference (well, in
> C you have to use pointers, but it amounts to the same thing
> in actual use).
Call-by-reference isn't used much, but when it is, it makes code
both simpler and clearer: Compare:
swap(A,B)
with our available alternative:
object tmp
tmp = A
A = B
B = tmp
> > It is complicated feature, I don't need it.
Not at all complicated. And it doesn't cause errors, because (in Pascal, for
example) it must be specifically and consciously enabled in the function
header.
> > Variables can not be initialized when declared, that is ok.
>
> That may be. But I did not ask if it was 'ok', I simply
> asked why it is not allowed. Is initializing a variable
> when it is declared a 'bad thing'? It is supported in other
> languages I have used, and so I was wondering why not in
> Euphoria.
If it is a bad thing, then does that not make constant declarations equally
bad?
> > Local constants are really not needed.
Nothing, other than a handful of assembler instructions, are really needed.
Everything else is either for convenience or for clarity.
Local constants make for clearer, less buggy code.
The alternative, which we have now, is to declare them as variables,
assign to them, then hope we don't accidently change the value somewhere
in the routine. And the only way to know whether that variable is used as
a variable or as a constant is to read the entire routine. How does that
contribute to clarity or convenience?
<snip>
> And to make sure I'm clear - I'm not asking for these
> features to be added to Euphoria.
>
> For instance, I can see why the author would not choose to
> add a goto to Euphoria. Many programmers realize that
> goto's, used unwisely, can cause hard to
> follow/maintain/prove correct code.
>
> I'm simply trying to understand if in general the author
> feels that call by reference, variable initialization on
> declaration, and locally declared Euphoria constants are bad
> things, or would lead to poor programming style, or what
> have you.
>
> If I know why these things are not allowed, who knows,
> perhaps I will adopt this style for my own use in the other
> languages I program in.
Other than the goto, I've never seen any textbook that condemns
these things. All that any of them can do is contribute to code clarity.
As to why they're not in Euphoria, along with a number of other things
which would add convenience while improving and simplifying code,
only Rob can answer.
Regards,
Irv
7. Re: A question about certain language features
On 11 Feb 2002, at 22:45, Irv Mullins wrote:
<snip>
> Other than the goto, I've never seen any textbook that condemns
> these things. All that any of them can do is contribute to code clarity.
> As to why they're not in Euphoria, along with a number of other things
> which would add convenience while improving and simplifying code,
> only Rob can answer.
<NOT an attack on Irv>
As for the goto being maligned in some textbooks, let me refer you to the
slam i made regarding Alabama interstate highways. There truely is nothing
wrong with the roadway or the right-of-way in Death Valley. The recurrent
problem is slow drivers, usually over 50yrs old, who apparently get scared of
the narrow back roads, and decide to drive on the interstate, but at the
speeds of the back roads. They merge at 40mph, and slow to 45mph when
they see the exit sign in the distance. If they are older, they slam on the
brakes right at the exit warning, a mile before they get to it. To be succinct:
poor driving skills. But we do not rip out the interstate highway system, we
try to improve driving habits. Well, i take that back, *here* they plan on
putting up roadside barriers so the wrecks stay in the traffic lanes.
Kat
8. Re: A question about certain language features
On 12 Feb 2002, at 4:18, tone.skoda at siol.net wrote:
>
> Classes!
>
> include circle.e as circle
>
> circle circle1
> circle cirlce2
>
> cirlce1.radius = 5
> circle1. x = 0
> circle1.y = 0
>
> cirlce2.radius = 10
> circle2. x = 5
> circle2.y = 5
>
> circle1.draw ()
> circle2.draw ()
>
> code above would draw two differecnt circles.
I wonder if you could write a Eu program that includes the interpreter as a
class, and all the Eu language keywords as Eu.keyword(). Would this give
us a clean exec(sequence) and pseudothreads?
Kat
9. Re: A question about certain language features
- Posted by euman at bellsouth.net
Feb 11, 2002
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
> I wonder if you could write a Eu program that includes the interpreter as a
> class, and all the Eu language keywords as Eu.keyword(). Would this give
> us a clean exec(sequence) and pseudothreads?
> Kat
yeah I can see that.....not..
infinite recursion of explicit function constructors...
"geesh that doesnt even sound good"
hehe
Euman
euman at bellsouth.net
10. Re: A question about certain language features
On 12 Feb 2002, at 1:02, euman at bellsouth.net wrote:
>
> ----- Original Message -----
> From: "Kat" <gertie at PELL.NET>
>
> > I wonder if you could write a Eu program that includes the interpreter as a
> > class, and all the Eu language keywords as Eu.keyword(). Would this give us
> > a
> > clean exec(sequence) and pseudothreads?
>
> > Kat
>
> yeah I can see that.....not..
>
> infinite recursion of explicit function constructors...
> "geesh that doesnt even sound good"
Nono,, do it *once*, as if an attempt to redefine any class would be an error.
Kat
11. Re: A question about certain language features
Hello Ed,
----------
> ïÔ: Ed Davis <ed_davis2 at yahoo.com>
> ëÏÍÕ: EUforum <EUforum at topica.com>
> ôÅÍÁ: A question about certain language features
> äÁÔÁ: Monday, February 11, 2002 19:39
<snipped>
> The features I have questions about as to why there were
> implemented that way are:
>
> 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.
> 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.
> 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.
No any & all confusions.
I think, many confusions are from those old good
*static*-*shared*-*extern*-*void*,
*by reference*-*by value*, *create*-*object*-*class*,
I call such the things just mumbo/jumbo.
Euphoria is normal human language for translation
to puter's mumbo\jumbo without weird side-effects.
Not from mumbo/jumbo to mumbo\jumbo.
And there is the human Mumbo-Jumbo language.
Almost all Russians know about this language
and understand it well. 
No any confusion, OK ? ;-[
Regards,
Igor Kachan
kinz at peterlink.ru
12. Re: A question about certain language features
> On 12 Feb 2002, at 4:18, tone.skoda at siol.net wrote:
> > Classes!
> >
> > include circle.e as circle
> >
> > circle circle1
> > circle cirlce2
> >
> > cirlce1.radius = 5
> > circle1. x = 0
> > circle1.y = 0
> >
> > cirlce2.radius = 10
> > circle2. x = 5
> > circle2.y = 5
> >
> > circle1.draw ()
> > circle2.draw ()
> >
> > code above would draw two differecnt circles.
Some time ago, when Dave Cuny was testing his Py interpreter, he sent me a
version that allowed:
include sprite.e as bart
include sprite.e as lisa
bart.image = "C:\bart.bmp"
lisa.image = "C:\lisa.bmp"
bart.loc = {0,0}
lisa.loc = {100,200}
IOW, allowing multiple instances of a single "object" declared in a single
include file. This seemed to work great, and could have been very useful.
Unfortunately, when I reported as much to Dave, he immediately removed
that capability. Perhaps he saw a way that it would have caused trouble.
Dave, when that happens at Microsoft, they just call it a "feature", and
turn it over to marketing who convince the rest of us that we are going to
like it :)
Regards,
Irv
13. Re: A question about certain language features
On Tuesday 12 February 2002 08:34 am, Ed Davis wrote:
!
>
> Note that the 'standard' definitions of Pascal, Modula-2,
> and Oberon, do not allow variables to be initialized when
> they are declared, just like Euphoria. So Professor Wirth
> perhaps thinks it is a bad thing? I have read several of
> his books dealing with the mentioned languages, but I have
> not been able to find a justification for not allowing
> variables to be initialized when declared.
>
> But there must be a reason. I can't believe it is just an
> arbitrary restriction.
Many design decisions were made for the purpose of keeping the
parser simple. I expect that is one of them.
Regards,
Irv
14. Re: A question about certain language features
Ed Davis wrote:
<snip>
> 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.
>
> 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.
>
> 3) No support for local constants.
</snip>
Only Rob can truly answer this, but I feel like speculating:
1. I share Ed's puzzlement about initialzion on declaration from a
programmming style stanpoint. Dissallowing it simplifys the parsing of
declarations.
2. Call by reference is dangerous, as is assigning to a global variable.
But when your are assigning to a global variable, you know that you are
doing it--when you pass a parameter to a function written by someone else
(perhaps in a shrouded library) do you know that you a doing it? In VB, you
don't know but assume so as ByRef is the default--even then without the
source or the good documentation that never exists in the real world you
don't know what the side effect will be. So even if the fuction call syntax
required you to declare that a parameter you were passing was by reference,
there would be more uncertainty that in the global variable case.
OOP languages pass (objects) by reference, but what can be done to the
reference (object) is restricted to the operation of the object's methods.
Unexpected side-effects are less likely (though certainly possible).
3. I'm not sure about why this is dissallowed.
A factor that Rob must have considered--the more features implemented in the
interpreter, the bigger and slower the interpreter gets. While any of these
features may be cheap in this regard, all the various proposed features
collectively are expensive.
>From his own writing, I gather that Rob's philosopy is "if it isn't
essential, leave it out." Early versions of Eu didn't even have "for" --
all looping was done with "while", which is sufficient -- but for loops make
such clear code when used appropriately and were desired by a huge portion
of Eu users that Rob felt adding this feature was in order.
In general I agree with Rob's philosophy as I understand it. Euphoria is so
flexible that you can do almost anything in libraries rather than the core
language.
Thank you, Ed, for an exellent though-provoking question.
-- Mike Nelson
15. Re: A question about certain language features
----------
> > > 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
16. 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.
function aaa(integer z)
object d, e, f
constant a = 99 * foo()
integer b = 99 + bar() * 7, h, i, g = 777
atom c
g += 1
h = g
etc.
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.
I once spent hours debugging something in another language,
simply because the author of the code had hidden a variable
declaration with initialization in amongst 20 or so other declarations.
I just couldn't "see" that the subroutine did not really "start" where
I thought it did. It actually started in the middle of the declarations
somewhere.
I like it better the way it is. You could argue that I don't have to use
variable inits if I don't want to. You could argue that I don't have
to use goto if I don't want to. A language does not exist just
to serve the isolated programmer. It exists to serve a community
of programmers. In situations where it really doesn't matter
how something is written, I think there are advantages to
reducing the number of choices.
> 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.
1. Call by value is appropriate 90% of the time, and no one
has any complaints.
2. Call by value is fundamentally easier to understand and
less likely to cause surprises.
3. In Euphoria, a variable can only be modified by explicitly
assigning a new value to it. No aliases. No pointers. No hocus pocus.
Certainly I would never want to have to look up the source code for
each routine to find out if it was going to secretly modify the
argument I was passing.
4. If a sequence parameter is not modified in the subroutine, then only a
pointer is passed internally, so it's very cheap.
5. If the sequence *is* modified, then copy-on-write comes into effect,
and a copy will be made of the argument sequence.
In some cases this copying could be considered expensive, but
only when a small portion of the sequence is modified. If you are
going to rewrite the whole sequence, as in a sort routine, then the
overhead from copying ( a few machine cycles per element)
will be far less than the cost of sorting (or adding/subtracting/multiplying
etc.)
each element.
There's an optimization which is near the top of my list, that would
eliminate the need for copy-on-write in many cases. Consider:
function sort(sequence s)
s[i] = ...
end function
sequence x
...
x = {5,6,7,8}
...
x = sort(x)
It would be possible to detect that the value of x, as passed to
sort(), will never be needed again. The implementation could then
arrange that the value passed to sort() will have only *one*
reference count (from s), rather than 2 (from x and s). This would
eliminate the need for a copy.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: A question about certain language features
On Tuesday 12 February 2002 11:51 am, Igor Kachan wrote:
>
> Inside a subroutine, in EUPHORIA, only PRIVATE variables
> may be declared. These points are in the reference manual.
>
True, but what is wrong with having private constants?
It's a convenience, and produces clearer code. No one has
provided a reason why it is either a good or a bad idea.
No doubt it was just an accident that it turned out that way.
Some people want Euphoria to be a minimalist language.
To achieve that goal, there are a lot of things that need to be taken out.
Other people want Euphoria to be the most usable language
possible. For that to happen, there are a few things which need
to be added.
Frankly, I don't recommend holding your breath while waiting for either of
these things to happen.
Regards,
irv
18. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
Hi Robert Craig, you wrote on 2/12/02 10:51:44 AM:
>Suppose we allow:
> ...
I don't always agree, but I think one of the big things
Euphoria has going for it is the clear vision of a single
designer. God save us from languages that are designed
by committee.
Karl
-------Phoenix-Boundary-07081998---
19. Re: A question about certain language features
Ok, another one, concerning scope of local vars declared in a function, and
passed to other functions: Pascal allowed nesting functions and procedures
inside each other. Every function and procedure was essentially a separate
program. The top procedure could declare vars "global" to the functions
inside it, but not outside it. This was handy also, in Pascal, but i have not
needed it in Eu, yet. But my point is this: there was no code to test and
abort with error("you cannot do that in a function!").
Kat
20. Re: A question about certain language features
Irv Mullins wrote:
----------
> ïÔ: Irv Mullins <irvm at ellijay.com>
> ëÏÍÕ: EUforum <EUforum at topica.com>
> ôÅÍÁ: Re: A question about certain language features
> äÁÔÁ: Tuesday, February 12, 2002 21:50
>
> On Tuesday 12 February 2002 11:51 am, Igor Kachan wrote:
> >
> > Inside a subroutine, in EUPHORIA, only PRIVATE variables
> > may be declared. These points are in the reference manual.
> >
>
> True, but what is wrong with having private constants?
> It's a convenience, and produces clearer code. No one has
> provided a reason why it is either a good or a bad idea.
> No doubt it was just an accident that it turned out that way.
This question is answered by Robert just now, about
"good and bad".
But we can make the concrete analisys of the frequencies
of useing some programming language fetures to decide
is some thing very useful or it is just a very rare thing.
If thing is rare, then there is no any reason to
replicate it in the new language.
Why not such analisys?
If we have the open sources of some program texts in C,
C++, Modula, Ada, Forth ...
But Windows has no open C sources. This secret is not
a good thing.
Task of analisys is not simple and cheap but without
concrete statistical stuff we may argue & argue & argue
without really useful results ...
Then Rob just will come to his own desision and program
new official version ...
The very good possibility to say any thing you think
without any side-effect ...
> Some people want Euphoria to be a minimalist language.
> To achieve that goal, there are a lot of things that need
> to be taken out.
Now, any one, who *really* wants something, can use the
source, learn C language and make system programming
to get interpreter on his taste.
Why not ?
But EU is the end user's language, language which
doesn't require knowledge of C to get working
compiled C program. EU is a good example of the
robust useing of existing C languages.
> Other people want Euphoria to be the most usable language
> possible. For that to happen, there are a few things
> which need to be added.
OK, why not ? But who must care this new Euphoria
to be solide and will not broken under own
weight? (somewhat bad frase, my Runglish, I'm sorry).
> Frankly, I don't recommend holding your breath
> while waiting for either of these things to happen.
Thanks. But I can not understand well
enough some hints, I'm sorry.
Regards,
Igor Kachan
kinz at peterlink.ru
21. Re: A question about certain language features
- Posted by tone.skoda at siol.net
Feb 12, 2002
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
> > > It is complicated feature, I don't need it.
>
> Not at all complicated. And it doesn't cause errors, because (in Pascal,
for
> example) it must be specifically and consciously enabled in the function
> header.
Yes, the feature itself is not complicated but it makes your code
complicated.
22. Re: A question about certain language features
>Call-by-reference isn't used much, but when it is, it makes code
>both simpler and clearer:
I spent 12 years coding with everything being call by reference.
I never understood the problem eg:
proc square(k)
k=k*k
end proc
z=2
square(z)
print(z)
===> just bizarre to me to see that print 2. I'll live though.
(And yes, in this case I do know to use function & z=square(z) ok)
>> > Local constants are really not needed.
And the same 12 years with no such concept as constants, just
variables you didn't alter.
>
>The alternative, which we have now, is to declare them as variables,
>assign to them, then hope we don't accidently change the value somewhere >in
>the routine.
Hope? yuk. who taught you to code?
> And the only way to know whether that variable is used as
>a variable or as a constant is to read the entire routine.
I find that commenting my code with trivia like what a variable is
used for and things like whether it should be modified or not quite
helpful. Mind you I am that rare beast that spends a lot more time
writing comments than code and feel very strongly that is the right
way to go about it. I try to write stuff that you can read the
comments and know what it is (trying) to do, then, and only then, if
you need to, you can look at the code.
For what it's worth, the only time I ever felt i *needed* a goto was
to do something really horrid like jump _into_ the middle of a loop
or another routine. To extricate myself from a tricky (aka nested)
situation is (usually) trivial: just move the code to new procedure(s)
and plonk return(s) in it. Trying to get in half way through on the
other hand without using goto can create a godawful mess. Needless to
say such use of goto tends to do that anyway, only quicker.
Pete
23. Re: A question about certain language features
Dear EU users,
I can continue some thoughts about
really useful language features.
----------
> Igor Kachan <kinz at peterlink.ru>
> > Irv Mullins <irvm at ellijay.com>
> > > Inside a subroutine, in EUPHORIA, only PRIVATE variables
> > > may be declared. These points are in the reference manual.
> > True, but what is wrong with having private constants?
> > It's a convenience, and produces clearer code. No one has
> > provided a reason why it is either a good or a bad idea.
> > No doubt it was just an accident that it turned out that way.
>
> This question is answered by Robert just now, about
> "good and bad".
>
> But we can make the concrete analisys of the frequencies
> of useing some programming language fetures to decide
> is some thing very useful or it is just a very rare thing.
> If thing is rare, then there is no any reason to
> replicate it in the new language.
>
> Why not such analisys?
>
> If we have the open sources of some program texts in C,
> C++, Modula, Ada, Forth ...
OK, it seems to be, no ?
But we have now Rob's source code, which allows
Rob to build interpretets and translators and
get Euphoria programming language.
Euphoria can do all you want, if you really want.
Let us ask Rob to find the time for such the analisys
of his complete source code and telling us the results.
Then we can make some conclusions about C language
as a system programming language.
I do not think Rob uses full set of ANSI C, so
we'll know the info about his working subset.
This one may be one of the best subsets
of C language, I think.
After updating Russian docs and my contributions
for official Eu 2.3, I'll be ready to make such
the analisys on the publicly-available part of
the Eu source code (in 5..7 days).
(If Rob has no any protests).
Regards,
Igor Kachan
kinz at peterlink.ru
24. Re: A question about certain language features
Robert wrote:
> In situations where it really doesn't matter how
> something is written, I think there are advantages to
> reducing the number of choices.
But in this case, it's not a matter of cosmetics. It actually *does* matter
how (and where) something is written. By splitting the declaration from the
assignment:
integer foo
...
foo = 123 -- default value
you increase the chances that the code will encounter an uninitialized
variable. And when that happens, the Euphoria interpreter stops, and anything
the user was doing is permanantly lost.
That's been my experience with Euphoria.
Isn't the end goal to provide users with robust applications?
-- David Cuny
25. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
Hi David Cuny, you wrote on 2/15/02 12:32:11 AM:
>
>But in this case, it's not a matter of cosmetics. It actually *does*
>matter
>how (and where) something is written. By splitting the declaration from
>the
>assignment:
>
> integer foo
> ...
> foo = 123 -- default value
>
>you increase the chances that the code will encounter an uninitialized
>variable. And when that happens, the Euphoria interpreter stops, and
>anything
>the user was doing is permanantly lost.
>
An argument could be made that uninitialized variables
ought to be prohibited.
integer foo
^
'Attempt to create variable without value'
Might make the interpreter faster because it
wouldn't have to do a runtime check for
uninitialized variables.
Karl
-------Phoenix-Boundary-07081998---
26. Re: A question about certain language features
On 15 Feb 2002, at 0:32, David Cuny wrote:
>
> Robert wrote:
>
> > In situations where it really doesn't matter how
> > something is written, I think there are advantages to
> > reducing the number of choices.
>
> But in this case, it's not a matter of cosmetics. It actually *does* matter
> how
> (and where) something is written. By splitting the declaration from the
> assignment:
>
> integer foo
> ...
> foo = 123 -- default value
>
> you increase the chances that the code will encounter an uninitialized
> variable. And when that happens, the Euphoria interpreter stops, and anything
> the user was doing is permanantly lost.
Program runs for an hour, then:
error - end while - undefined
I thought these were caught at compile time?
Kat
27. Re: A question about certain language features
Karl wrote:
>An argument could be made that uninitialized variables ought to be
>prohibited.
I thought about that when I was writing this. One problem with this is that
some variables are placeholders, and don't have a default value. For
example:
integer key
while (1)
key = wait_key()
if key = <some value> then
exit while
end if
end while
Another is that just because you set a variable to a value doesn't mean that
it's a *sensible* value, or that it will make the code behave properly.
After all, you could initialize a flag to TRUE, when the default should have
been FALSE.
In retrospect, I have to admit that allowing initialization at declaration,
while increasing the chances that a variable will be initialized, doesn't
*guarantee* that it will. So it's not entirely a good solution for the
problem that I'm trying to solve.
I think Java got it right in some ways, complaining in cases where a
variable is used where it might not be initialized. For example:
integer i
if rand(1) then
i = 1
end if
return i
would fail in Java, because it would recognize that "i" *might* not be
initialized. But it's just fine in Euphoria. Mind you, that was sometimes a
pain - I'd have to add 'else' clauses that I was sure wouldn't execute just
to make the compiler happy. But it would certainly solve the problem.
Euphoria does check to make sure that "i" is actually set to some value
somewhere in the routine. If you wrote:
integer i, j
if rand(1) then
i = 1
end if
you'll get a warning that "j" is not used.
So, while I'd prefer to be able to assign variables at runtime, a better
solution fot the problem would be to make the interpreter smarter, instead
of extending the language.
28. Re: A question about certain language features
David Cuny writes:
> Euphoria does check to make sure that "i" is actually set to some value
> somewhere in the routine. If you wrote:
>
> integer i, j
> if rand(1) then
> i = 1
> end if
>
> you'll get a warning that "j" is not used.
And if a variable is used, but not assigned a value anywhere...
procedure foo()
integer x
? x
end procedure
Warning: private variable x in foo() is never assigned a value
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
29. Re: A question about certain language features
Robert wrote:
> And if a variable is used, but not assigned a value anywhere...
> ...
> Warning: private variable x in foo() is never assigned a value
Yes. But I was more interested in a case like this:
integer i
if rand(10) > 5 then
i = 100
else
-- this will cause an error
end if
? i
and getting:
Warning: private variable i might never be assigned.
-- David Cuny
30. Re: A question about certain language features
David Cuny writes:
> Yes. But I was more interested in a case like this:
>
> integer i
>
> if rand(10) > 5 then
> i = 100
> else
> -- this will cause an error
> end if
> ? i
>
> and getting:
>
> Warning: private variable i might never be assigned.
At compile time, at each place where a variable is referenced,
Euphoria tries to determine if the variable will definitely be
initialized at that point. If it's not sure that the variable will be
initialized, it outputs an INIT_CHECK opcode to do a run-time check.
See InitCheck() in parser.c
It would be trivial to output a warning whenever an INIT_CHECK
is issued. In most cases, no INIT_CHECK is needed, so there
wouldn't be a huge number of spurious warnings, but I imagine
there would be enough warnings that people would get tired of it.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
31. Re: A question about certain language features
----- Original Message -----
From: "David Cuny" <euphoria_coder at HOTMAIL.COM>
To: "EUforum" <EUforum at topica.com>
Subject: Re: A question about certain language features
>
> Karl wrote:
>
> >An argument could be made that uninitialized variables ought to be
> >prohibited.
>
> I thought about that when I was writing this. One problem with this is
that
> some variables are placeholders, and don't have a default value. For
> example:
>
> integer key
>
> while (1)
> key = wait_key()
> if key = <some value> then
> exit while
> end if
> end while
>
> Another is that just because you set a variable to a value doesn't mean
that
> it's a *sensible* value, or that it will make the code behave properly.
> After all, you could initialize a flag to TRUE, when the default should
have
> been FALSE.
>
> In retrospect, I have to admit that allowing initialization at
declaration,
> while increasing the chances that a variable will be initialized, doesn't
> *guarantee* that it will. So it's not entirely a good solution for the
> problem that I'm trying to solve.
>
> I think Java got it right in some ways, complaining in cases where a
> variable is used where it might not be initialized. For example:
>
> integer i
> if rand(1) then
> i = 1
> end if
> return i
>
> would fail in Java, because it would recognize that "i" *might* not be
> initialized. But it's just fine in Euphoria. Mind you, that was sometimes
a
> pain - I'd have to add 'else' clauses that I was sure wouldn't execute
just
> to make the compiler happy. But it would certainly solve the problem.
>
> Euphoria does check to make sure that "i" is actually set to some value
> somewhere in the routine. If you wrote:
>
> integer i, j
> if rand(1) then
> i = 1
> end if
>
> you'll get a warning that "j" is not used.
>
> So, while I'd prefer to be able to assign variables at runtime, a better
> solution fot the problem would be to make the interpreter smarter, instead
> of extending the language.
>
Yes David, I think that approach sounds good too. In a related issue, I once
suggested that it would be useful to know at run-time whether or not a
variable has been initialised.
Something along the lines of:
if not initialized(x) then
x = 0
end if
------
Derek
32. Re: A question about certain language features
- Posted by rforno at tutopia.com
Feb 16, 2002
Well, I think it is worse to encounter a variable containing an arbitrary
default value instead of one you forgot to assign.
In the second case, you´ll get an execution error just at the point. In the
first one, you probably will get a difficult to trace error many sentences
after.
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
To: "EUforum" <EUforum at topica.com>
Subject: Re: A question about certain language features
Robert wrote:
> In situations where it really doesn't matter how
> something is written, I think there are advantages to
> reducing the number of choices.
But in this case, it's not a matter of cosmetics. It actually *does* matter
how (and where) something is written. By splitting the declaration from the
assignment:
integer foo
...
foo = 123 -- default value
you increase the chances that the code will encounter an uninitialized
variable. And when that happens, the Euphoria interpreter stops, and
anything
the user was doing is permanantly lost.
That's been my experience with Euphoria.
Isn't the end goal to provide users with robust applications?
-- David Cuny
33. Re: A question about certain language features
On 16 Feb 2002, at 16:52, rforno at tutopia.com wrote:
>
> Well, I think it is worse to encounter a variable containing an arbitrary
> default value instead of one you forgot to assign.
> In the second case, you´ll get an execution error just at the point. In the
> first one, you probably will get a difficult to trace error many sentences
> after.
This would be fine, if the interpreter caught it at compile time, and not after
a
heavily edited file was open and about to be nuked because of the error. If
the unassigned var was default s={} and i=0,, hmm, a=? 0? ' '? ''?
Ok, i got it !, make the last include file scan the var list, and assign
whatever
you want to them! Oh wait, no var list,, well, drat. Hey Rob, giving a varlist
function would bypass this pre-assignment request..
s = varlist() -- nested sequence
?s[1] -- first var declared
{"junk",'a',12}
procedure AssignDefaultVals()
for each 'a' in s[2] do
if equal(s[each][1],SpecialCaseValue)
then s[each][3] = 1
else s[each][3] = MyAtomDefaultValue
end if
end for
end procedure
Or somesuch. Passing the ref would help here, so a new copy isn't made of
a 200meg database of sequences. Better yet, make it a class? I dunno, it
was a thought.
Kat
----- Original Message ----- From: "David Cuny" <dcuny at LANSET.COM> To:
> "EUforum" <EUforum at topica.com> Sent: Friday, February 15, 2002 5:32 AM
> Subject:
> Re: A question about certain language features
>
>
> Robert wrote:
>
> > In situations where it really doesn't matter how
> > something is written, I think there are advantages to
> > reducing the number of choices.
>
> But in this case, it's not a matter of cosmetics. It actually *does* matter
> how
> (and where) something is written. By splitting the declaration from the
> assignment:
>
> integer foo
> ...
> foo = 123 -- default value
>
> you increase the chances that the code will encounter an uninitialized
> variable. And when that happens, the Euphoria interpreter stops, and
> anything
> the user was doing is permanantly lost.
>
> That's been my experience with Euphoria.
>
> Isn't the end goal to provide users with robust applications?
>
> -- David Cuny
>
>
>
>
34. Re: A question about certain language features
On Sat, 16 Feb 2002 16:52:48 -0300, you wrote:
>By splitting the declaration from the
>assignment:
>
> integer foo
> ...
> foo = 123 -- default value
>
>you increase the chances that the code will encounter an uninitialized
>variable.
Finally I just understood:
integer foo foo=123
integer bar bar=7
procedure f(integer k, sequence s)
is fine, but
procedure f(integer k, sequence s)
integer foo foo=123
integer bar bar=7
gives an error. It's all about scoping rules. Eg a for loop introduces
a new scope, so in
for i=1 to 10 do
...
integer k
end for
what the hell would be k's scope? (not that anyone is asking for
integer declarations in the middle of a for loop, but it's all part &
parcel of the same thing.) Above, the scope of bar clearly would not
include the code foo=123 but the only scope bar can legally have is
all of procedure k. And the semantic problems. Rob, if you're
listening, please please NEVER put that in!
>And when that happens, the Euphoria interpreter stops, and
>anything the user was doing is permanantly lost.
OH GOD! Now I hadn't really thought of that but it is a MAJOR omission
- which hopefully should be relatively easy to rectify. Any serious
programming environment should have an application-defined recovery
point [defined/set with routine-id()?]. When a fatal error occurs, the
interpreter should take a copy of the recovery routine (if defined),
clear it, then invoke it via the copy. Rob, forget scoping or multiple
or nested recovery routines, just one at top level. It is up to the
programmer to ensure any data they need is available (global) & if
they are stupid enough to reset the recovery pointer making the thing
loop it's the programmers problem not the interpreters. It would be
very nice, but not necessary, to supply the recovery point with (the
stuff you have just written to) the ex.err file. On the other hand it
may be easier/better to throw it away to ensure it is safe to invoke
the top-level routine.
Pete
35. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
You wrote on 2/16/02 6:55:21 PM:
>
>Finally I just understood:
>
>integer foo foo=123
>integer bar bar=7
>procedure f(integer k, sequence s)
>
>is fine, but
>
>procedure f(integer k, sequence s)
>integer foo foo=123
>integer bar bar=7
>
>gives an error. It's all about scoping rules. Eg a for loop introduces
>a new scope, so in
>
>for i=1 to 10 do
>....
>integer k
>
>end for
>
>what the hell would be k's scope? (not that anyone is asking for
>integer declarations in the middle of a for loop, but it's all part &
>parcel of the same thing.) Above, the scope of bar clearly would not
>include the code foo=123 but the only scope bar can legally have is
>all of procedure k. And the semantic problems. Rob, if you're
>listening, please please NEVER put that in!
>
The simple rule that could be used is that the scope of a
variable extends from it's point of declaration to the
end of the current block.
k's scope would be from its declaration to the end of the
for statement, just like i's scope is from 'i=1' to
the end of the for loop.
bar's scope would be from it's declaration to the end of
the procedure (not including the 'foo=123' line).
The only issue is whether the interpreter will always
see the declaration before it sees any references,
which is why declarations are normally restricted to
the start of blocks. If it did see a reference first,
the result would be no worse than an uninitialized
variable.
>And when that happens, the Euphoria interpreter stops, and
>anything the user was doing is permanantly lost.
>...
> Rob, forget scoping or multiple
>or nested recovery routines, just one at top level.
Good idea! I would think it quite easy to make the
interpreter find and execute a specifically-named
procedure when a fatal error is encountered. The
programmer would make sure the recovery routine
was coded at the start (right after the globals
it needed) so it would be available.
Wouldn't solve everything but a LOT better than nothing.
Karl Bochert
-------Phoenix-Boundary-07081998---
36. Re: A question about certain language features
----------
> > > 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
37. Re: A question about certain language features
I've got a few minutes before the next crisis so I'll add my tuppence worth...
13/02/2002 3:51:43 AM, Igor Kachan <kinz at peterlink.ru> wrote:
>
>
>----------
>> > > 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.
>
Firstly, as you know full well, constants and variables are not the same. Sure
one can do:
constant x = 5
but then you can't go and do:
x += 1
I think that the primary reason for wanting to initialise variables when they
are being declared is
simply because it is convenient and reduces the chance of forgetting to do it.
The current syntax
for doing this only works outside of routines:
integer x x = 5
integer y y = 6
the argument is that this is not a particularly pretty solution. For example:
integer CustomerResidentialAddressIndex CustomerResidentialAddressindex = 1
integer CustomerMailingAddressIndex CustomerMailingAddressIndex = 1
(Yes, I know they have the same value. This is because it might have to change
at run-time for some
valid reason.)
It might be said that :
integer CustomerResidentialAddressIndex = 1
integer CustomerMailingAddressIndex = 1
was cleaner. However, did you notice the subtle bug in the proper Eu syntax
example? I made an error
because I had to type the variable name twice and got it wrong the second time.
using standard Eu, some people might write:
integer CustomerResidentialAddressIndex,
CustomerMailingAddressIndex
CustomerResidentialAddressIndex = 1
CustomerMailingAddressIndex = 1
This looks a little cleaner (to me) but it is still too much typing and we are
getting away from
initialising at declaration time. However, this is how we might do it now inside
a routine. What is
being suggested is:
integer CustomerResidentialAddressIndex = 1,
CustomerMailingAddressIndex = 1
regardless of whether it is inside or outside of a routine.
Apparently, RDS believes that mixing declarations and executables outside a
routine is okay, but not
inside routines?
integer x
x = 1
integer y
y = 2
is okay but :
procedure a()
integer x
x = 1
integer y
y = 2
end procedure
is not!
Why not? It is inconsistent behaviour. I suggest it has been done this way just
so that writing the
interpreter was easier for RDS. I can not think of any other reason yet.
I remember in COBOL you could declare a variable and give it an INITIAL-VALUE
clause. This would
make the compiler generate code that not only gave the memory area reserved for
the variable the
initial value, in made another COBOL statement useful. One could say in your
program:
INITIALIZE var1, var2, var3.
And each of these variables would be set to their initial values again. A very
useful thing to speed
up coding.
>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.
The "side-effects" being discussed here are not of the type you mention, but
more along the lines
that - if I call a routine, how can I be sure, aside from looking at the
routine, that it doesn't
update any global variables? This problem is lessened (but not eliminated) by
using pass-by-
reference. In that case, you have narrowed down the potential scope of side
effects to the variables
being passed.
My feeling is that global variables should almost never be declared at all. And
if so, you probably
have not got an optimal design. I locks you in to potential maintenance problems
in the future.
For example, I seriously wish the win32lib.ew did not have all those onXXX
sequences globally
available. I has made serious issues with expanding its functionality. With the
current regime, I
cannot assume inside the library that somebody using the library hasn't altered
the values at any
time. And I want to be able to define new handler exits at run-time, which the
onXXX method doesn't
allow - because the names must be known by the interpreter at run-time.
---------
Cheers,
Derek Parnell
ICQ# 7647806
38. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 3/20/02 7:41:44 PM:
>I think that the primary reason for wanting to initialise variables when
>they are being
>declared is
>simply because it is convenient and reduces the chance of forgetting to do
>it. The current
>syntax
>for doing this only works outside of routines:
>
> integer x x = 5
> integer y y = 6
>
>the argument is that this is not a particularly pretty solution. For
>example:
>
> integer CustomerResidentialAddressIndex CustomerResidentialAddressIndex
>= 1
> integer CustomerMailingAddressIndex CustomerMailingAddressIndex = 1
>
My ?favorite? example of this kind of redundancy is something like:
CustomerResidentialAddressIndices = CustomerResidentialAddressIndices[2..
length (CustomerResidentialAddressIndices)]
An earlier fix I tried allowed the oddball syntax:
@foo[2..]
to be equivalent of:
foo = foo[2..length(foo)]
>Why not? It is inconsistent behaviour. I suggest it has been done this
>way just so that writing the interpreter was easier for RDS.
> I can not think of any other reason yet.
I think that the only reason for this can be because Rob wants it
that way.
It took me 2 months to add a dozen 'enhancements' to Eu, and most
of them were very easy once I understood the code sufficiently.
You have got to believe that Rob could add these features in a
week (maybe a month, with extensive testing).
>
>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.
>
I know its been here before, but could someone point me to this
article again?
>> > > 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.
As near as I can see, Pass By Reference involves a 'deep' change
to the language. Every modification to every passed variable
must check if the variable is a reference. This single extra
check would noticeably slow down all programs, violating a
prime design goal of Eu.
I partially implemented PBR and was surprised to find that
it slowed any program that did not use it extensively by
10-15%.
Karl Bochert
-------Phoenix-Boundary-07081998---
39. Re: A question about certain language features
Karl,
I'm thinking that a distinct token be placed in the slice notation that
indicates end-of-sequence rather than omitting the end slice value. Maybe a
"$" symbol.
foo = "abcdefghij"
a = foo[2..$] -- everything except the first element.
a==> "bcdefgihj"
b = foo[1..$-6] -- everything except the last 6 elements.
b==>"abcd"
c = foo[$-4..$-1] -- only the elements 6 thru 9.
c==>"fghi"
The problem with omission is that it you are never certain that the omission
was deliberate or not. A specific symbol inserted is more rarely a mistake.
Of course we don't need a special symbol to represent the beginning of a
sequence because the value 1 suffices.
The other nice slice extention is to allow a list of subslices in the
notation:
d = foo[1..3, $-2..$]
d==> "abchij"
but that might be stretching the friendship 
------------
Derek.
----- Original Message -----
From: <kbochert at ix.netcom.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, March 22, 2002 6:36 AM
Subject: RE: A question about certain language features
You wrote on 3/21/02 10:54:37 AM:
>Karl,
>
> Consider this syntax for shorthand slicing. Your current syntax sort
>of defeats the sequence bounds checking.
>
>seq[1..0] -- seq[1..length(seq)]
>seq[1..0-1] -- seq[1..length(seq)-1]
>
>seq[1..1-1] -- {} (reverse slice)
>seq[1..-1] -- index [-1] out of bounds
>
>integer index index=0
>seq[1..index] -- {} (reverse slice)
>
>'O' is explicit, it cannot be implied. If it is, the original EU rules
>apply.
>
>I haven't thouroughly looked. Does your shorthand work if it's implied
>with a variable?
>
>
>Chris
I handle 'foo[2..]' by expanding it textually. I think of it
as a macro.
when I see the '..' followed by a ']' or '-', I insert the text
'length(foo)' directly into the input stream. (Having previously
saved the 'foo').
'foo[2..]' causes the interpreter to actually see 'foo[2..length(foo)]'
and 'foo[2..-(a*b)]' is seen as 'foo[2..length(foo)-(a*b)]'
As a result, all the normal Euphoria processing is left intact.
Thanks for the link
Karl Bochert
40. Re: A question about certain language features
Chris,
I see we are thinking alike here. I suggested the '$' symbol because that is
often used in regular expression syntax to mean the end-of something. The
symbol '0' could also be a coding mistake, but I would think a rare one (eg.
I miskeyed the '9'). Also, it doesn't seem to be associated with "end-of",
except maybe a count-down by NASA.
a = foo[2..0] -- is what I keyed,
a = foo[2..9] -- but this is what I meant.
-------
Derek
----- Original Message -----
From: <bensler at mail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, March 22, 2002 8:00 AM
Subject: RE: A question about certain language features
>
> Your syntax, and the form that I am suggesting are virtually identical.
> The difference is in readability, and ease of implementation.
> Compare:
> foo[1..] == foo[1..length(foo)]
> foo[1..-1] == foo[1..length(foo)-1]
>
> foo[1..0] == foo[1..length(foo)]
> foo[1..0-1]== foo[1..length(foo)-1]
>
> Your implementation requires 2 checks for substitution.
> My suggestion is to simply subtitute the literal '0' with length(foo)
>
> foo[1..] could just be a typo.
> foo[1..0] is defined explicity.
>
> Yes, my example could be a typo also, but not as likely to happen.
>
> foo[1..-1] the negative could be fairly easily missed.
> foo[1..0-1] knowing that the literal '0' is always substituted with
> length(foo), it's easy to see the intention.
>
>
> To summarize, your implementation adds two new rules, whereas my
> suggestion only adds one.
> The concepts are identical, but the representation is different.
>
>
> Chris
>
> kbochert at ix.netcom.com wrote:
> > -------Phoenix-Boundary-07081998-
> > Content-type: text/plain; charset=ISO-8859-1
> > Content-transfer-encoding: 8bit
> >
> > You wrote on 3/21/02 10:54:37 AM:
> >
> > >Karl,
> > >
> > > Consider this syntax for shorthand slicing. Your current syntax sort
> > >of defeats the sequence bounds checking.
> > >
> > >seq[1..0] -- seq[1..length(seq)]
> > >seq[1..0-1] -- seq[1..length(seq)-1]
> > >
> > >seq[1..1-1] -- {} (reverse slice)
> > >seq[1..-1] -- index [-1] out of bounds
> > >
> > >integer index index=0
> > >seq[1..index] -- {} (reverse slice)
> > >
> > >'O' is explicit, it cannot be implied. If it is, the original EU rules
> > >apply.
> > >
> > >I haven't thouroughly looked. Does your shorthand work if it's implied
> > >with a variable?
> > >
> > >
> > >Chris
> >
> > I handle 'foo[2..]' by expanding it textually. I think of it
> > as a macro.
> >
> > when I see the '..' followed by a ']' or '-', I insert the text
> > 'length(foo)' directly into the input stream. (Having previously
> > saved the 'foo').
> > 'foo[2..]' causes the interpreter to actually see 'foo[2..length(foo)]'
> > and 'foo[2..-(a*b)]' is seen as 'foo[2..length(foo)-(a*b)]'
> >
> >
> > As a result, all the normal Euphoria processing is left intact.
> >
> > Thanks for the link
> > Karl Bochert
> >
> >
> > -------Phoenix-Boundary-07081998---
> >
>
>
>
>
41. Re: A question about certain language features
-------Phoenix-Boundary-07081998-
Hi Derek Parnell, you wrote on 3/21/02 12:27:45 PM:
>
>Karl,
>I'm thinking that a distinct token be placed in the slice notation that
>indicates end-of-sequence rather than omitting the end slice value. Maybe a
>"$" symbol.
>
> foo = "abcdefghij"
> a = foo[2..$] -- everything except the first element.
> a==> "bcdefgihj"
> b = foo[1..$-6] -- everything except the last 6 elements.
> b==>"abcd"
> c = foo[$-4..$-1] -- only the elements 6 thru 9.
> c==>"fghi"
>
>The problem with omission is that it you are never certain that the
>omission
>was deliberate or not. A specific symbol inserted is more rarely a mistake.
>Of course we don't need a special symbol to represent the beginning of a
>sequence because the value 1 suffices.
I much prefer '$' to '0' for this purpose. It seems that this introduces
a 'Perl-ish' pseudo-variable into the language. '$' is defined as:
'length(<most-recent parsed sequence>)'. We could then have:
sequence s
s = foo();
?$ -- print length of s
The possibilities are endless!
>The other nice slice extention is to allow a list of subslices in the
>notation:
>
> d = foo[1..3, $-2..$]
> d==> "abchij"
>
>but that might be stretching the friendship
Maybe later
Karl Bochert
-------Phoenix-Boundary-07081998---
42. Re: A question about certain language features
foo[1..0] is already a legal (null) slice, using it to mean length(foo) will
break existing code. Perhaps a better scheme would be using -1 for the end
of the sequence. This is also fairly intuitive:
foo[1..3] means the first thru third elements conting from the beginning,
and
foo[-3..-1] would mean the third thru first elements counting from the end.
also something like foo[2..-2] would be legal (this would return the
sequence minus the first and last element)
Internally a negative slice would be converted like this:
foo[-3..-1] becomes foo[length(foo)+1-3,length(foo)=1-1] which can be
simplifed in this case to foo[length(foo)-2..length(foo)]
Of course, the same negative indexing should apply to subscripts, where it
is even more intuitive:
foo[4] is the fouth element form the beginning, foo[-4] is the fourth
element from the end.
-- Mike Nelson
