1. Initializing variables on declarations
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Apr 04, 2007
- 631 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?
2. Re: Initializing variables on declarations
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 04, 2007
- 588 views
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: http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=7&toMonth=2&toYear=7&postedBy=rds&keywords=declaration+initialize 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 http://www.RapidEuphoria.com
3. Re: Initializing variables on declarations
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 04, 2007
- 572 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
4. Re: Initializing variables on declarations
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com> Apr 04, 2007
- 605 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 > 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> Clear majority? ... of the developers, contributors to the recent contributions page? ... not sure if I have voting rights... but, for what its worth, I vote for initialization of variables on declaration for global, local to a file and & privates. Ken Rhodes Folding at Home: http://folding.stanford.edu/ 100% MicroSoft Free SuSE Linux 10.0 No AdWare, SpyWare, or Viruses! Life is Good,
5. Re: Initializing variables on declarations
- Posted by Juergen Luethje <j.lue at gmx.de> Apr 04, 2007
- 591 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
6. Re: Initializing variables on declarations
- Posted by Jules Davy <jdavy at dsl.pipex.com> Apr 04, 2007
- 575 views
> Clear majority? ... of the developers, contributors to the > recent contributions page? ... good point, are votes weighted in some way? and do we vote here on the forum? my preference is a no for initialisation on declaration. I agree with Rob's point that "In situations where it really doesn't matter how something is written, I think there are advantages to reducing the number of choices." This is especially true when you're trying to read someone elses code.
7. Re: Initializing variables on declarations
- Posted by jxliv7 <jxliv7 at hotmail.com> Apr 04, 2007
- 574 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
8. Re: Initializing variables on declarations
- Posted by Jason Gade <jaygade at yahoo.com> Apr 04, 2007
- 593 views
Most of the examples show a constant assigned in initialization on declaration. Would it complicate matters to make it the rule that only constants or constant expressions are allowed? Legal:
integer x = 5 atom y = 3.1415927 * 8 * 8 sequence foo = {65, 66, "C"}
Illegal:
integer y = x + 320 * v sequence foo = {bar, baz, zoo}
Of course then you get to the point whether the identifier of a constant could be used... Just musing here. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
9. Re: Initializing variables on declarations
- Posted by ChrisBurch2 <crylex at freeuk.co.uk> Apr 04, 2007
- 570 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
10. Re: Initializing variables on declarations
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 07, 2007
- 594 views
> > Current syntax: > > > [global] integer x x = 5 > > > > > > Desired syntax: > > > [global] integer x = 5 > FWIW, I'm for this. I think it could be quite fair to say that only short literal integers are allowed, though the special case of {} would be welcome. I am in agreement with most that object x=f(5,g[7]) etc is overkill. I must admit that I wanted to stand back and watch how this thread panned out, and am left with the desire to call for an old Pascal-style ruling that we can (straying off topic a bit here) say eg:
procedure x() constant a=1,b=2 integer x,y
but NOT
procedure x() integer x constant a=1 integer y constant b=2
I must admit though I am in two minds. I see this as a good thing in many ways and also as a possibly open running sore of disappointment and perhaps confusion as to why certain expressions are not allowed. But a firm hand documentationwise could fix that, surely? Rob Craig wrote: >why not privates (inside a routine) as well? Personally, that is mostly where I want it most. There is a minor syntactic sugar with more complex expressions at top level:
<type> var=<expr>
is exactly the same as:
<type> var var=<expr>
in disguise. It is quite natural to me now to key var<Ctrl W><Ctrl V><space><Ctrl V>; however the former is plain easier to read. As above and general consensus K.I.S.S. for for private routine vars tho. Regards, Pete
11. Re: Initializing variables on declarations
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Apr 07, 2007
- 577 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.
12. Re: Initializing variables on declarations
- Posted by Dan Moyer <danielmoyer at prodigy.net> Apr 10, 2007
- 593 views
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? Michael, For whatever it's worth, I like this idea. Dan Moyer