OpenEuphoria

1. Variable declarations

• Posted by Jim Hendricks <jim at bizcomputinginc.com> Sep 18, 2004
• 458 views
• Last edited Sep 19, 2004

Just started working with Euphoria a couple of days ago, but have
been professionally programming for 20+ years.

I love the simplicity of Euphoria!  Am porting an existing app over
as my way of getting my feet wet.

Haven't dug in deep yet so this issue may have already been discussed,
or may be in the manual and I just missed it.

The manual states that variables must be declared before they are used,
what I didn't see is that at least in a proc/func definition, all the
declarations must come first ( this is just anecdotal and I may be missing
something stupid )

Here's an example:

procedure test()
  atom myatom
  myatom = 1
  sequence myseq
  myseq = "test"
end procedure

This is just sample code, I tried running it real quick and it seems to
demonstrate the error I was receiving.  On line: "sequence myseq" I 
get the exception: Syntax error - expected to see possibly 'end', not 
a type .  If I trade this line with the previous line, all is cool.

This seems to suggest that at least within and procedure or function
definition all the declarations must be made prior to any other code.

Is this correct?  Is it documented behavior?  It's not a problem for me
since enforcing declarations before code results in cleaner and easier
to read code, I just thought that if this was not documented, it would
go a long ways toward helping out the newbies!

Jim Hendricks
President
Biz Computing, Inc.

3. Re: Variable declarations

• Posted by Jim Hendricks <jim at bizcomputinginc.com> Sep 18, 2004
• 431 views
• Last edited Sep 19, 2004

Derek Parnell wrote:
> Yes, variables inside routines must be declared prior to the first 
> executable statement in that routine. It is documented under the 
> heading 'scope'...
> 
> "Variable declarations inside a subroutine must all appear 
> at the beginning, before the executable statements of the subroutine."
> 
> -- 
> Derek Parnell
> Melbourne, Australia

Ah, thanks, my bad.  I saw at the beginning of the scope section the 
statement that all variables must be declared, but stopped reading the 
section when it started in on naming conflicts since right now my
programs are simple enough that naming conflicts are not a problem and
I try to keep to local scope ( if that's the right EU terminology ) 
which greatly reduces naming conflicts.

Thanks also for the quick response!  That will come in handy as I try
and wrap my mind around EU.

Jim Hendricks
President
Biz Computing, Inc.

5. Re: Variable declarations

• Posted by Greg Haberek <ghaberek at gmail.com> Sep 19, 2004
• 416 views

I think thats one of the few things we all did when we started, along
with improperly initializing variables.

we've all done these, i'm sure:

-- wrong:
integer myint = 5

-- right:
integer myint  myint = 5


-- wrong:
integer myint
    myint += 5  --wrong

-- right:
integer myint
    myint = 0
    myint += 5

On Sat, 18 Sep 2004 15:34:41 -0700, CoJaBo <guest at rapideuphoria.com> wrote:
> 
> posted by: CoJaBo <cojabo at suscom.net>
> 
> Jim Hendricks wrote:
> >
> > Derek Parnell wrote:
> > > Yes, variables inside routines must be declared prior to the first
> > > executable statement in that routine. It is documented under the
> > > heading 'scope'...
> > >
> > > "Variable declarations inside a subroutine must all appear
> > > at the beginning, before the executable statements of the subroutine."
> > >
> > > --
> > > Derek Parnell
> > > Melbourne, Australia
> >
> > Ah, thanks, my bad.  I saw at the beginning of the scope section the
> > statement that all variables must be declared, but stopped reading the
> LOL :) I did the exact same thing when I first started!
> 
> 
> > section when it started in on naming conflicts since right now my
> > programs are simple enough that naming conflicts are not a problem and
> > I try to keep to local scope ( if that's the right EU terminology )
> > which greatly reduces naming conflicts.
> >
> > Thanks also for the quick response!  That will come in handy as I try
> > and wrap my mind around EU.
> >
> > Jim Hendricks
> > President
> > Biz Computing, Inc.
> >
> 
> 
> 
>

7. Re: Variable declarations

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 19, 2004
• 417 views
• Last edited Sep 20, 2004

Jim Hendricks wrote:

<snip>

> It does bring
> rise to the question, "What is the value of a declared but not initialized
> integer?"

Just try it:

integer i
? i

> With sequences it's the empty sequence {} or ""

Sure? 

sequence s
? s

<snip>

*Both* cases cause an error.

Regards,
   Juergen

9. Re: Variable declarations

• Posted by Jim Hendricks <jim at bizcomputinginc.com> Sep 19, 2004
• 413 views
• Last edited Sep 20, 2004

Juergen Luethje wrote:
> 
> Jim Hendricks wrote:
> 
> <snip>
> 
> > It does bring
> > rise to the question, "What is the value of a declared but not initialized
> > integer?"
> 
> Just try it:
> }}}
<eucode>
> integer i
> ? i
> </eucode>
{{{

> 
> > With sequences it's the empty sequence {} or ""
> 
> Sure? 
> }}}
<eucode>
> sequence s
> ? s
> </eucode>
{{{

> 
> <snip>
> 
> *Both* cases cause an error.
> 
> Regards,
>    Juergen
Right you are! See my further comments in reply to Derek's comments.

11. Re: Variable declarations

• Posted by CoJaBo <cojabo at suscom.net> Sep 19, 2004
• 430 views
• Last edited Sep 20, 2004

Greg Haberek wrote:
> 
> I think thats one of the few things we all did when we started, along
> with improperly initializing variables.
> 
> we've all done these, i'm sure:
> 
> }}}
<eucode>
> -- wrong:
> integer myint = 5
It would be nice if Euphoria allowed this...
It would save soem typing!

> 
> -- right:
> integer myint  myint = 5
> 
> 
> -- wrong:
> integer myint
>     myint += 5  --wrong
Yup, I seem to forget to set the initial value of a variable
about 99.9% of the time!

> 
> -- right:
> integer myint
>     myint = 0
>     myint += 5
> </eucode>
{{{

> 
> On Sat, 18 Sep 2004 15:34:41 -0700, CoJaBo <guest at rapideuphoria.com> wrote:
> > 
> > posted by: CoJaBo <cojabo at suscom.net>
> > 
> > Jim Hendricks wrote:
> > >
> > > Derek Parnell wrote:
> > > > Yes, variables inside routines must be declared prior to the first
> > > > executable statement in that routine. It is documented under the
> > > > heading 'scope'...
> > > >
> > > > "Variable declarations inside a subroutine must all appear
> > > > at the beginning, before the executable statements of the subroutine."
> > > >
> > > > --
> > > > Derek Parnell
> > > > Melbourne, Australia
> > >
> > > Ah, thanks, my bad.  I saw at the beginning of the scope section the
> > > statement that all variables must be declared, but stopped reading the
> > LOL :) I did the exact same thing when I first started!
> > 
> > 
> > > section when it started in on naming conflicts since right now my
> > > programs are simple enough that naming conflicts are not a problem and
> > > I try to keep to local scope ( if that's the right EU terminology )
> > > which greatly reduces naming conflicts.
> > >
> > > Thanks also for the quick response!  That will come in handy as I try
> > > and wrap my mind around EU.
> > >
> > > Jim Hendricks
> > > President
> > > Biz Computing, Inc.
> > >
> >

13. Re: Variable declarations

• Posted by Jim Hendricks <jim at bizcomputinginc.com> Sep 20, 2004
• 428 views

Derek Parnell wrote:
> 
> <SNIP>
> 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.
I don't know if I can define simple.

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. 

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.

> 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.

> >  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.  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

> 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 
Exactly the point, never an uninitialized state.  I would have loved the
dBase approach more if it required variable declaration.

> 
> > 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.
Yes, nasty stuff, but then again I would not consider OOP a simple 
programming environment although there are simpler OOP implementations
than others.  I think it's funny how many Forth systems have to complicate
themselves with OOP when many of the advantages of OOP are intrinsic to
Forth.

> 
> > > 
> > > 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.
Sorry to hear that, I hope it's not because you are trying to use the 
wrong tool for the wrong problem.

> 
> >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).
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.

> 
> >  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 too new to Euphoria to know what the copyright is etc.  And I guess your
right in that even if the language itself is copyrighted, we have seen
many examples of companies getting around that ( for example Microsoft C#
to get around Java )

And yes, any product can be better, but a system that prides itself on
simplicity usually settles on a strong simple "kernel" if you will which
changes very little, and most of the improvements are in the add-ons in the
form of libs etc.

Although I did just think of something that RDS might want to consider.
It might be that features like Un-initialized allowances could be added as
options which default to the current way, but programmers like yourself
who want the features can switch them on without imposing the overhead on
programmers like myself who don't need them.  ( ie. like VB's Option Explicit )
I know this would be more complicated than just that for example a generic
lib routine, how does it handle itself if it was written assuming NULLS off
and is called from an app that has NULLS on?

> 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.
Haven't yet messed with any of the Win32 stuff yet in Euphoria.  I'm working
strictly with console stuff right now figuring I can tackle the frontend
later. 
> -- 
> Derek Parnell
> Melbourne, Australia
>

15. Re: Variable declarations

• Posted by Jim Hendricks <jim at bizcomputinginc.com> Sep 20, 2004
• 433 views

Derek Parnell wrote:
> 
> [snip]
>  
> 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.
Thanks for that vote of confidence in Euphoria, let's me know to keep 
investigating.
> 
> [snip]
>  
> 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.
It's mostly distributed libs I would be concerned about.  A distributed lib
which assumed initialized args used by a newbie who passed an uninitialized
arg and received the uninitialized message would potentially assume it's
my library which is at fault rather than in their own care to ensure all
their variables are initialized.

> > > >  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. 
Yes I see your point, just still dislike Null.  My real start in programming
came in various forms of ML and ASM where variables were declared via some
type of data directive which would reserve the memory, in some cases 
initialized, in other cases not, but there was never a pre-built means to
determine if it was initialized, it was up to you as a programmer to
habitually declare and initialize. This held true even for allocated heap
where the allocation reserved the memory but it was then up to you as the
programmer to make sure the memory was set to your initialized state.

Null may provide for the ability to detect an uninitialized state, but I
guess with my background I don't want to allow for an uninitialized state
but rather like the language to point out to me when I fail to initialize.

Just thought of another situation where Null allowances would affect me
as a decidedly non-null kind of guy - return values.  I could happily code
without Nulls even with a Null allowance in the interpreter, but if I use
your libraries to do XY and Z I may be forced to deal with Nulls if you
choose to return nulls from some of your functions.

The example you gave a few messages back on this thread where you are
attempting to create a more OOP like functional syntax with optional
arguments, why not stick with the Euphoria way?  By that I mean you are
calling the root routine with a sequence of args, you count the args and
dynamically call the proper routine based on how many args were in the 
sequence.  Why not have the 1 routine in which your initial block of code
determines what args are missing and coding the whole routine in 1 place
filling in the missing with defaults or whatever?

I realize that using the Euphoria way doesn't allow for type checking in
the routine declaration, but this seems a small price to pay in having to
add argument type checking validation.

Jim