OpenEuphoria

1. Initializing variables on declarations

• Posted by Michael J. Sabal <m_sabal at yahoo.com> Apr 04, 2007
• 604 views

Okay, I'm about to do it again.  I was looking at the Euphoria source and 
the list of open feature requests, and I think this change can be done with
minimal code.

Current syntax:
[global] integer x  x = 5

Desired syntax:
[global] integer x = 5

As I see it, the initializing assignment can remain optional.  The procedure 
parser() in parser.e would need an additional temp variable to hold the 
variable name.  After global_symbol is called, check if the next token is 
EQUALS.  If not, put it back.  If so, call assignment.  This would need to be
added to both the TYPE and GLOBAL TYPE sections.

AFAICT, this wouldn't break anything.  Can anyone see a reason for not doing
this?

3. Re: Initializing variables on declarations

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 04, 2007
• 549 views

Robert Craig wrote:
> 
> Michael J. Sabal wrote:
> > Okay, I'm about to do it again.  I was looking at the Euphoria source and 
> > the list of open feature requests, and I think this change can be done with
> > minimal code.
> > 
> > Current syntax:
> > [global] integer x  x = 5
> > 
> > Desired syntax:
> > [global] integer x = 5
> > 
> > As I see it, the initializing assignment can remain optional.  The procedure
> > 
> > parser() in parser.e would need an additional temp variable to hold the 
> > variable name.  After global_symbol is called, check if the next token is 
> > EQUALS.  If not, put it back.  If so, call assignment.  This would need to
> > be
> > added to both the TYPE and GLOBAL TYPE sections.
> > 
> > AFAICT, this wouldn't break anything.  Can anyone see a reason for not doing
> > this?
> 
> Here's what I said about this (and some other stuff) back in 2002:
> 
>   <a
>   href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize</a>
> 
> If a clear majority wants this, and someone is prepared to do it,
> I would go along with it (though I still don't think it's
> a particularly good idea.) However if you do it for global 
> (and local to a file) declarations, why not privates (inside a routine) 
> as well?
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

I'm definietly for it.

sequence longClearAndMeaningfulName
longClearAndMeaningfulName={}

is made more clear by coding it as

sequence longClearAndMeaningfulName = {}

The redundancy runs counter to the stated ideals of elegance and simplicity
 of the language. Not mentioning the reduction of visual clutter and typos.

CChris

5. Re: Initializing variables on declarations

• Posted by Juergen Luethje <j.lue at gmx.de> Apr 04, 2007
• 568 views

Robert Craig wrote:

> Michael J. Sabal wrote:
> > Okay, I'm about to do it again.  I was looking at the Euphoria source and 
> > the list of open feature requests, and I think this change can be done with
> > minimal code.
> > 
> > Current syntax:
> > [global] integer x  x = 5
> > 
> > Desired syntax:
> > [global] integer x = 5
> > 
> > As I see it, the initializing assignment can remain optional.  The procedure
> > 
> > parser() in parser.e would need an additional temp variable to hold the 
> > variable name.  After global_symbol is called, check if the next token is 
> > EQUALS.  If not, put it back.  If so, call assignment.  This would need to
> > be
> > added to both the TYPE and GLOBAL TYPE sections.
> > 
> > AFAICT, this wouldn't break anything.  Can anyone see a reason for not doing
> > this?
> 
> Here's what I said about this (and some other stuff) back in 2002:
> 
>   <a
>   href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize</a>

I agree with every word in the posting at this link.
Intermixing declaration of variables with assignments can reduce
readability, and therefore shouldn't be allowed.

> If a clear majority wants this, and someone is prepared to do it,
> I would go along with it (though I still don't think it's
> a particularly good idea.) However if you do it for global 
> (and local to a file) declarations, why not privates (inside a routine) 
> as well?

Regards,
   Juergen

7. Re: Initializing variables on declarations

• Posted by jxliv7 <jxliv7 at hotmail.com> Apr 04, 2007
• 551 views

I agree with Rob and Jeurgen -- it's going to reduce clarity and add a level of
confusion when deciphering code.

sometime * convenience != confusion AND clarity-1
 

--
jon

9. Re: Initializing variables on declarations

• Posted by ChrisBurch2 <crylex at freeuk.co.uk> Apr 04, 2007
• 549 views

Hi

I'm in the 'no need to initialise on declaration camp'. However, if the change
is trivial (as you suggest), and consistent (function and procedure declarations
too), and there is no time penalty (in compilation), then I wouldn't _object_
per se.

Chris

11. Re: Initializing variables on declarations

• Posted by Michael J. Sabal <m_sabal at yahoo.com> Apr 07, 2007
• 555 views

Robert Craig wrote:
> 
> 
> Here's what I said about this (and some other stuff) back in 2002:
> 
>   <a
>   href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize</a>
> 
> If a clear majority wants this, 

This is certainly not the case, it seems.  As I read it, it's about 50%, 
myself included.

> and someone is prepared to do it,

That's why I brought it up.

> I would go along with it (though I still don't think it's
> a particularly good idea.) However if you do it for global 
> (and local to a file) declarations, why not privates (inside a routine) 
> as well?

I would have, if this mod had enough support to actually do.
I just overlooked that part in my first glance.

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

Just about every editor used for Euphoria programming has keyword coloring
where constant and integers are different colors.  The doubled symbol
name on a typed line is just as easy to overlook as the single symbol
name being proposed.  This is one reason a lot of programmers capitalize
constants (or use a variation of Hungarian notation) and leave variables
in mixed case.

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

In this "other language" (C perhaps?), you use braces for statements,
routines, structures, and I'm sure there are a few other places I'm 
forgetting at the moment.  Euphoria separates its parts with words, not
punctuation, so you have to try really hard to obfuscate the start of a
routine.  Don't forget that the constant assignment IS executing code
anytime there isn't a literal.  If I later try to assign a value to a 
constant, Euphoria will throw a very clear error (unlike those obscure
C errors that sometimes don't even point you to the right file, much less
the right line).

That's the last I'll say on this topic.  Unless there's a pretty big change
of support, this mod won't be getting done anytime soon.