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
|
Not Categorized, Please Help
|
|
