OpenEuphoria

Re: Feature suggestion: without keyword=

• Posted by Michael J. Sabal <m_sabal at y?hoo?com> May 20, 2008
• 605 views

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.