Re: Variable declarations
Jim Hendricks wrote:
>
> Derek Parnell wrote:
> > <SNIP>
> > > OK, I can see this even though it didn't trip me up yet. It does bring
> > > rise to the question, "What is the value of a declared but not initialized
> > > integer?" With sequences it's the empty sequence {} or "" but what is it
> > > with atoms and integers?
> >
> > Actually its the same for integers, atoms, sequences and objects. When you
> > declare any of these but don't explictly initialize them, they all have
> > a special state of 'uninitialized'. Unfortunately, even though the
> > Euphoria interpreter and debugger recognizes this state, there is no method
> > of that your application can test for it. By that I mean you cannot do
> > something like ...
> >
> > if not initialized(myVar) then
> > myVar = 1
> > end if
> >
> > which is a pity because it makes a great "first-time-through" test and
> > would be a neat way to test for 'optional' function arguments.
> >
> > To put it simply, the RDS philosophy is that all variables must be
> > explictly initialized before they can be used in anyway.
> I don't think that's so bad since it forces the programmer to think
> through setting up the environment. I agree it could be useful to be
> able to test for unitialized but declared variables but it would go
> against the simple design of Euphoria.
I know I'm going to be misunderstood by commenting here, but believe me
I'm not being agressive or confrontational. I'm not big-noting myself, or
putting anybody down. But....
"the simple design of Euphoria" slips so easily off the tongue. But what
does one actually mean by it? How is "simple" measured? Can it be measured?
Are you saying the Euphoria is at the cusp and adding just one more thing
suddenly pushes it over the edge and makes it no longer simple?
Does simple mean "simple to use", "simple to write interpreters for",
"simple to explain", ... or some mixture of these.
Why does adding a test for the variable's "initialized" property make
Euphoria's design not simple? All variables already have that property. We
know this because the interpreter can detect it (thus the specific
error message) and the debugger can detect it (thus the specific warning
message). Variables already have other properties that we can inquiry
about (length() for sequences, datatype for all variables) so how is
this a big change for the language design. The concept already exists
in the language.
Currently we have to workaround the issue. By this I mean that we might
initialize a variable to an impossible value in order to detect if
it has been 'initialized' by some other process. However, this leads
to inefficiencies or non-intuitive situations. For example I find myself
declaring some variables as 'object' so I can initialize them to zero, and
then later test if they been changed to a sequence or not. If not, then I
might have to perform some lengthy process to give them a default value.
And by the way, some default values might not be not available until other
values have been assigned. I have even created variables to track
the 'initialized' state of other variables - how bug-inducing is that!
> Personally I despise dealing with
> Null in other languages, it's too ambiguous.
I don't see this. Its either initialized or not. What is ambiguous?
Currently, this is true for all variables. Its just that we can't test
for it programatically.
Visual Basic got it wrong by making it more confusing that it needed to be,
by having Null, Nothing and Empty.
The D language has implemented this for arrays and classes, but not for
intrinsic datatypes or structs. Again, not clever.
Euphoria already has implemented it for all datatypes, but it just doesn't
allow programmers access to the property.
>Years ago I used to program
> in dBase/Foxbase/FoxPro and loved the lack of Null and the automatic
> defaulting, nums to 0, strings to "", logicals to false. Although the
> lack of explicit declaration could lead to sloppy code and unexpected errors.
Yes, well this is a whole other issue. Though implictly initialized
variables can never be uninitialized 
> And as optional arguments go, I have a love/hate relationship with them.
> While I love the ability to drop some arguments that may not be necessary,
> I hate how optional arguments can lead to sloppy code. I try to allow for
> a "NA" state for arguments which may be optional and then test for that
> state in the function/procedure. This forces me to be specific in calling
> the function/procedure that if I don't want the argument I must explicitly
> set it to the "NA" state.
I've gone even further! In trying to implement signature matching for OO
systems in Euphoria I've done this (I'm still undecided if its a good thing)
...
procedure FuncA_2(object Parm1, object Parm2)
. . .
end procedure
procedure FuncA_1(object Parm1)
return FuncA_2(Parm1, defparm2)
end procedure
procedure FuncA_0()
return FuncA_2( defparm1, defparm2)
end procedure
procedure FuncA(sequence parms)
return call_func(routine_id("FuncA_" & sprintf("%d",length(parms))), parms)
end if
Nasty stuff.
> >
> > Ooops! Sorry - there I go bad mouthing Euphoria and RDS again. I apologize
> > to all forum readers who are upset when people do that heinous crime.
> Since I'm new to Euphoria and this list I wouldn't know your history of
> "bad mouthing" so my opinion here may show a lack of sensitivity to the
> situation,
Its nothing. I'm just a little jaded and battle-scarred at the moment.
I'll get over it and grow-up soon.
>but I don't see this as bad mouthing. You might change your
> choice of "RDS way" to "Euphoria way" to make it a statement of "this is
> how it is" rather than the more political statement of "this is how it is
> because this is how RDS wants it".
You're probably right. I don't tend to keep quiet; I'm not a status quo
man (ironically though, they are one of my favourite bands).
> Even though the more political
> statement is true, it goes without saying since Euphoria belongs to RDS.
Does it? This is where I might differ a bit from some. For example, when I
publish an implementation of Euphoria, I'll have a GOTO facility in it. Not
because I think it is a good thing, but because some of my customers do,
and it is not forced on all to use. Sure, a product can't be all things to
all people. But a product can always be better than it currently is.
I'm currently the primary person coordinating the Win32lib library. If
I could work on it full time, it would be a much improved beastie. There
are a number of areas that it falls down, with respect to customer
satisifaction, and I only wish I had the time to address those issues
properly. Speaking of which, I'm trying to package up the next release
today.
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
