Re: Variable declarations
Jim Hendricks wrote:
>
[snip]
> I was drawn to Euphoria because it seems to offer the simplicity yet power
> that I first discovered in Forth. The basis of Forth is simple, but sadly
> most implementations for Windows are overly complex.
Ahhh...Forth. One of my favourite programming languages. I implemented
a small Forth-like scripting language in my Macro Processor (soon to
be released at RDS site). It is a great write-only language, like APL
and Lisp.
I am drawn to Euphoria too because of its clean lines. And like C, the
language is very complete, in that there is very little that can't be coded
without stepping outside the language.
> Now I'm too new to Euphoria to know weather it's the direction I will go
> for personal Windows app dev, but I'm optomistic because Euphoria is
> providing me something I first liked in Forth, simplicity. A handful of
> primitives, clean syntax, straight forward code formatting, and apparent
> access to the OS and the machine. This may be because I haven't been
> exposed to Euphoria long enough, but time alone will tell.
I'm sure you will enjoy using it. The improvements to the language now are
mainly in the syntax-sugar arena. With the upcoming 2.5's crash handling,
I feel confident that it can be used in commercial, responsible
applications.
> > 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.
> Personally I don't know that adding an "isInitialized( object )" to the
> language necessarily makes the design more complex so much as it makes
> programs written in EU more complex. See some of my following comments
> to see why I say that.
>
> > 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!
> Yes your descriptions of work arounds sound complex and maybe what you are
> programming requires that kind of complexity. 9 times out of 10 though
> in my own experience I find that my most complex code is due to my own
> failure to "see" the simple solution. I tend to over complex a problem.
> I don't say that this is your case, only that it's my own experience. I
> also don't think that EU should be or can be the "be all-end all" to all
> programming problems, that would be true Euphoria, something that can only
> be found in Utopia.
>
> Your work arounds may be complex, but on the flip side adding initialization
> state functions would also require the elimination of some of the
> non-initialized checking in the interpreter. For example you would need
> to allow for passing a non-initialized variable to a function/procedure
> to do some of what you want to do. That complicates my code because I
> can no longer assume that all the arguments passed to my routine are
> initialized, I then am required to complicate my code, especially my
> reusable code to ensure I have initialized arguments.
You are right about the argument passing change. However the effect on your
code would be zero because currently a program fails if you pass an
uninitialized variable, but if that was relaxed, your program would still
fail when that parameter was used by your routine. So the only difference
is *when* it fails, not *why* it fails. And because using IsInitialized()
would not be mandatory, you can choose to add it as appropriate to
give your code more flexibility.
> > > 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.
>
> Ambiguous in that a boolean is true/false/null it is not really a boolean
> but a tristate. Ambiguous in that a string is either a value, a null
> string ( ie. empty string ), or null.
I suspect if people realize that we are not talking about the *value* of
a variable, but about a *property* that it possesses, then they can see
that even current programs must deal with this situation. A boolean is
not true/false/null it is initialized or uninitialized. If initialized
it can then either be false or true. This is not new because all Euphoria
programs work like this today. There is no new concept or change to the
way Euphoria is working today. Its just that developers today cannot query
a variables 'is-initialized' property. All existing code that runs today
would still run if we had access to this property.
> Then to top it all off, Java
> allows for nulls with Object based variables but the primitives can't
> be null. And then I agree with your following statement about VB, all
> different types of Null. Then there's the differences between different
> languages about how to handle nulls. Empty in some languages return true
> for null values, others return false, so is Null empty? Depends on each
> languages interpretation. Then dealing with Nulls in SQL drives me
> batty. Some tools I have to use ignore rows that contain a null so I have
> to make sure I default null values in my SQL statement, a real PITA.
>
> >
> > 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.
> Reminiscent of Java
Yeah - D borrowed a lot ideas from C#, Java and C++.
[snip]
> >
> > 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).
> I personally don't think you should stay quiet! What is a good
> programming community if there aren't outspoken individuals that keep
> everyone thinking. But one of the disadvantages of being that outspoken
> person is that sometimes in the ferver challenges either turn into
> insults or are interpreted as insults. Don't be cowed into silence though,
> just always be ready with an apology when your misinterpreted and be
> ready for personal attacks by people not desireous of being challenged to
> think.
Thanks.
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
