1. Feature suggestion: without keyword=
One of the reasons new keywords are not easily accepted into the language is
that they will break code that used the previously available identifier as a
var/routine name.
While additions to 4.0 will have this undsirable effect - can't help -, we could
avoid further breakage by introducing a new directive:
without keywords= <comma separated list on one line>
This would instruct the interpreter to accept identifiers in the list as normal
identifiers, and prevent it from considering any of them as a keyword.
Symetrically, "with keywords" would disable such filtering.
Both directives would behave like "with trace" or similar, ie you can change
them at any point, and they are restored when parsing resumes after including a
file.
This way, Eu 4.1 would be able to run pre-4.1 code that might break with only
minor editing. I guess there could be a command line switch to set the initial
state of the filter. At startup, and without such instruction, the interpreter
would start "with keywords".
Any thoughts?
CChris
2. Re: Feature suggestion: without keyword=
CChris wrote:
>
> }}}
<eucode>
> without keywords= <comma separated list on one line>
> </eucode>
{{{
>
I kind of think that we should just accept the fact that some things are going
to break with 4.0. Hopefully not too much. The location of a few functions that
were previously in misc.e and are now in a more appropriate place is about all.
There are a few new keywords that could cause a conflict in source code, for
instance if you use a variable named "continue"
But other than that, I do not really think we have a problem with 4.0 breaking
things? win32lib works out of the box as does anything else I have ever tested.
All my code works fine. ed.ex used the variable "continue" in the function
search(). A search/replace for continue to continue_search remedied that problem
in about 5 seconds.
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: Feature suggestion: without keyword=
- Posted by Arthur Crump <arthur.crump at ?t?world.com>
May 19, 2008
-
Last edited May 20, 2008
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> > }}}
<eucode>
> > without keywords= <comma separated list on one line>
> > </eucode>
{{{
> >
>
> I kind of think that we should just accept the fact that some things are going
> to break with 4.0. Hopefully not too much. The location of a few functions
> that
> were previously in misc.e and are now in a more appropriate place is about
> all.
> There are a few new keywords that could cause a conflict in source code, for
> instance if you use a variable named "continue"
>
etc.
> > without keyword = <comma separated list on one line>
seems like a good idea. Perhaps restricted to new keywords.
If Jeremy Cowgar doesn't want to use it, there is no need to.
Arthur Crump.
4. Re: Feature suggestion: without keyword=
- Posted by Jeremy Cowgar <jeremy at cowg?r.?om>
May 19, 2008
-
Last edited May 20, 2008
Arthur Crump wrote:
>
> > > without keyword = <comma separated list on one line>
> seems like a good idea. Perhaps restricted to new keywords.
> If Jeremy Cowgar doesn't want to use it, there is no need to.
>
It's not a matter of if John or Jane will use it, it's a matter of what's best
for the entire community. I think we need some more discussion on this. Any other
thoughts from others?
Once concern I have is the complexity it may add (I say may because I have not
thought out how it would work) and potential slow down to the parser having to
check if a keyword is allowed in this file or not.
Chris, can you speak to those two concerns?
The last concern I have is then a division in how Euphoria programmers program.
I've said many times that consistency in the language is paramount. Starting to
enable/disable parts of the language sounds very dangerous to me.
To me if you have an application that will only run on Eu 3.1 simply because of
one keyword (continue) then you should either update your application or continue
to run it under 3.1. I do not think we should introduce new parsing routines and
possible/probable? slow downs into 4.0 just so someone does not have to update a
variable name that could easily be done w/a simple search/replace.
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: Feature suggestion: without keyword=
- Posted by gshingles <gshingles at ?mai?.com>
May 19, 2008
-
Last edited May 20, 2008
Jeremy Cowgar wrote:
>
> Arthur Crump wrote:
> >
> > > > without keyword = <comma separated list on one line>
> > seems like a good idea. Perhaps restricted to new keywords.
> > If Jeremy Cowgar doesn't want to use it, there is no need to.
> >
>
> It's not a matter of if John or Jane will use it, it's a matter of what's best
> for the entire community. I think we need some more discussion on this. Any
> other thoughts from others?
I think it's a good idea that might not be economic to implement. The idea
seems to be allowing code written for 4.0 using an identifier (eg 'xxxxxx') which
later becomes a keyword in 4.1x to be run in 4.1x by ignoring the fact that
'xxxxxx' is a keyword now.
I think the case is very common, for example using "continue" as a loop control
variable ('while continue do'), but I think a search and replace could cure that
in 3 seconds vs. X hours to implement/test/document 'please ignore this' in the
interpreter.
I also think its use would be limited to new programs include'ing old includes
because if you were trying to run an 'old' program you would have to edit it
anyway to add the 'without keywords....' for either the program or its includes.
So you may as well search/replace the identifier in question at the time of doing
that.
However it would be a very handy feature if you were using a lot of Euphoria
includes on a network drive or server host environment that you absolutely could
not get updated.
So my position is, if someone wants to do it and it doesn't have any adverse
effects, then I'm neither for nor against it.
Gary
6. Re: Feature suggestion: without keyword=
I vote NO, I agree with Jeremy on that.
Jacques
CChris wrote:
>
> One of the reasons new keywords are not easily accepted into the language is
> that they will break code that used the previously available identifier as a
> var/routine name.
>
> While additions to 4.0 will have this undsirable effect - can't help -, we
> could
> avoid further breakage by introducing a new directive:
> }}}
<eucode>
> without keywords= <comma separated list on one line>
> </eucode>
{{{
>
> This would instruct the interpreter to accept identifiers in the list as
> normal
> identifiers, and prevent it from considering any of them as a keyword.
>
> Symetrically, "with keywords" would disable such filtering.
>
> Both directives would behave like "with trace" or similar, ie you can change
> them at any point, and they are restored when parsing resumes after including
> a file.
>
> This way, Eu 4.1 would be able to run pre-4.1 code that might break with only
> minor editing. I guess there could be a command line switch to set the initial
> state of the filter. At startup, and without such instruction, the interpreter
> would start "with keywords".
>
> Any thoughts?
>
> CChris
7. Re: Feature suggestion: without keyword=
CChris wrote:
>
> This would instruct the interpreter to accept identifiers in the list as
> normal
> identifiers, and prevent it from considering any of them as a keyword.
> Symetrically, "with keywords" would disable such filtering.
> Any thoughts?
Sounds like Perl 6. For what that's worth.
Matt
8. Re: Feature suggestion: without keyword=
Matt Lewis wrote:
>
> CChris wrote:
> >
> > This would instruct the interpreter to accept identifiers in the list as
> > normal
> > identifiers, and prevent it from considering any of them as a keyword.
>
> > Symetrically, "with keywords" would disable such filtering.
>
> > Any thoughts?
>
> Sounds like Perl 6. For what that's worth.
Also, I think we could get away with this through conditional compilation.
The important bits, at least.
Matt
9. Re: Feature suggestion: without keyword=
Matt Lewis wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> > >
> > > This would instruct the interpreter to accept identifiers in the list as
> > > normal
> > > identifiers, and prevent it from considering any of them as a keyword.
> >
> > > Symetrically, "with keywords" would disable such filtering.
> >
> > > Any thoughts?
> >
> > Sounds like Perl 6. For what that's worth.
>
> Also, I think we could get away with this through conditional compilation.
> The important bits, at least.
>
> Matt
Agreed.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: Feature suggestion: without keyword=
Jeremy Cowgar wrote:
>
> Arthur Crump wrote:
> >
> > > > without keyword = <comma separated list on one line>
> > seems like a good idea. Perhaps restricted to new keywords.
> > If Jeremy Cowgar doesn't want to use it, there is no need to.
> >
>
> It's not a matter of if John or Jane will use it, it's a matter of what's best
> for the entire community. I think we need some more discussion on this. Any
> other thoughts from others?
>
> Once concern I have is the complexity it may add (I say may because I have not
> thought out how it would work) and potential slow down to the parser having
> to check if a keyword is allowed in this file or not.
>
> Chris, can you speak to those two concerns?
>
This directive is not meant to be used in new code. It is meant to enable code
that might otherwise suddenly start breaking to keep going.
How it would work is to select which parser switchboard is being used, one that
doesn't test (current) and one which does. So
* using code without keywords (the default) has no noticeabe effect performance
- IncludePush() and IncludePop() push and pop one more item.
* using code with keywords= incurs a parsing time penalty (one test for each
potential keyword). Execution is not affected.
And now that I think about it, it's even simpler to implement this inside the
symbol identification routine proper, ie in scanning. No dual parser, just an
ifdef and a check when "with keywords" is on and a keyword is identified.
While I agree that, for a developer, editing the offending code is not more than
5 seconds of text manipulation, this may not be true for the average user. It's
easy to forget using the Whole word only option, and Notepad doesn't have a
Search/replace across project option.
Upgrading the application is obviously better, but if the maintainer is no
longer there or just too busy?
Not upgrading the interpreter may be a pain because you'll wind up having
several versions and juggle with various paths.
Adding a one line directive at the top of a couple files may appear as a lesser
nuisance.
One last thing: John Doe wrote an app that uses a 3rd party lib which starts
breaking. True, he can fix the lib. But this means that he will now distribute a
modified version of a lib. Licensing may not be a problem, but what will happen
when the author of the 3rd party lib upgrades it any time later, and users will
get the new and old versions installed?
CChris
> The last concern I have is then a division in how Euphoria programmers
> program.
> I've said many times that consistency in the language is paramount. Starting
> to enable/disable parts of the language sounds very dangerous to me.
>
> To me if you have an application that will only run on Eu 3.1 simply because
> of one keyword (continue) then you should either update your application or
> continue to run it under 3.1. I do not think we should introduce new parsing
> routines and possible/probable? slow downs into 4.0 just so someone does not
> have to update a variable name that could easily be done w/a simple
> search/replace.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
11. Re: Feature suggestion: without keyword=
Chris,
I think even if this is easy and does not cost in performance, it's a dangerous
idea. I'm not a dictator and everything has to go up for vote, but I will be
voting a very firm no to this proposal. I think we are making a complex solution
to a problem we do not have and I see no good coming out of being able to alter
the core language.
--
Jeremy Cowgar
http://jeremy.cowgar.com
12. Re: Feature suggestion: without keyword=
Jeremy Cowgar wrote:
>
>
> Once concern I have is the complexity it may add (I say may because I have not
> thought out how it would work) and potential slow down to the parser having
> to check if a keyword is allowed in this file or not.
>
I don't believe the complexity or parsing time would be significant, as long
as this statement were limited to the first line(s) of code. Essentially,
all you're doing is manipulating the symbol table. If the entry doesn't
exist among the built-in symbols, then it can't get an opcode and will cause
no conflict.
I think this is an incredibly valuable feature that can let me evaluate older
contributions easily without having to scan through several thousand lines of
code to rename variables that conflict with new language features.
> The last concern I have is then a division in how Euphoria programmers
> program.
> I've said many times that consistency in the language is paramount. Starting
> to enable/disable parts of the language sounds very dangerous to me.
Nobody's disabling anything. Think of it more as a backwards-compatibility
switch, reverting the interpreter to an earlier state temporarily.
> To me if you have an application that will only run on Eu 3.1 simply because
> of one keyword (continue) then you should either update your application or
> continue to run it under 3.1. I do not think we should introduce new parsing
> routines and possible/probable? slow downs into 4.0 just so someone does not
> have to update a variable name that could easily be done w/a simple
> search/replace.
Simple search and replace is rarely so simple, especially in code. By telling
people to maintain multiple versions of the interpreter in their environments,
it's as bad as Microsoft telling us we have to use .NET v1.1 for feature a,
but .NET v3.0 for feature b; and the two aren't compatible. If you want to
fork off Eu 4.0, by all means go ahead. But mark my words, nothing will kill
this language or community faster than forking versions.
13. Re: Feature suggestion: without keyword=
Michael J. Sabal wrote:
>
>
> I don't believe the complexity or parsing time would be significant, as long
> as this statement were limited to the first line(s) of code. Essentially,
> all you're doing is manipulating the symbol table. If the entry doesn't
> exist among the built-in symbols, then it can't get an opcode and will cause
> no conflict.
>
The symbol table is global. You cannot modify the symbol table for just one file
(I don't think?).
>
> Simple search and replace is rarely so simple, especially in code.
Hm, I just did a sed in euphoria/include and replaced the variable named fn with
replace_fn_var_for_testing. It worked fine, all unit tests still pass.
> By telling
> people to maintain multiple versions of the interpreter in their environments,
> it's as bad as Microsoft telling us we have to use .NET v1.1 for feature a,
>
> but .NET v3.0 for feature b; and the two aren't compatible.
No matter about incompatibilities in syntax, there are going to be other
incompatibilities. Removing a keyword is going to fix very little code. For
instance, 3.1 code requires a few functions in misc.e that are no longer there.
3.1 code will break regardless if the continue keyword is present.
Adding this option is *not* going to enable 3.1 code to run. The only way 3.1
code will run is to have 3.1. If you do not want to maintain multiple installs of
Euphoria (which is actually, super simple) then you can bind or translate the 3.1
program and call it independent of any Euphoria install.
> If you want to
> fork off Eu 4.0, by all means go ahead. But mark my words, nothing will kill
> this language or community faster than forking versions.
How did we get to forking? That's a terrible idea. My statement was simple: "I
do not like this idea, but everything has to come up for a vote. I am simply
saying that I will vote a firm no to this proposal." Does that sound like someone
who wants to fork Euphoria?
But please, the main grunt of this message here is that disabling a keyword *is
not* going to enable you to run 3.1 code.
--
Jeremy Cowgar
http://jeremy.cowgar.com
