Re: ? 1={}, is there really any other interpretation?
Derek Parnell wrote:
>
> ChrisBurch2 wrote:
>
> > > If for some rare reason I actually wanted to do a sequence operation, then
> > > I'd
> > > appreciate using a different method - either a new operator or a
> > > function-like
> > > construct.
> > >
> > > x = name [>] "pete"
> >
> > huh?
>
> I agree. This was just a quick example of something that might be an operator.
> I was not advocating this exact syntax or any specific syntax at this point.
> I still talking concepts.
>
> > > x = seq_gt(name, "pete")
> > >
> > > These are rarely used operations and I firmly believe that breaking code
> > > is
> > > justified if improves the language for (the many?) future users.
> > >
> >
> > This is the dangerous bit. While progress is good, breaking previous code is
> > most definitely not - the more advanced programmers will have little
> > difficulty
> > migrating, but the mid class (eg me) would struggle for a while - I would
> > get
> > there eventually of course. However, would this in fact not be more
> > confusing
> > for
> > newbies? Ie an ettempt to make the code even more human readable, may in
> > fact
> > have the reverse effect.
>
>
> And exactly how much of your code would break if we made comparision operators
> behave intuitively in 'if' and 'while' statements? None! Because if you were
> doing that now your code is already broken. And outside of these constrtucts
> I suspect that almost no-one will be badly affected, notwithstanding Andy's
> 60% analysis. A quick check on Andy's public code shows that he uses sequence
> operations using '=', '>', '<' etc.. exactly zero times. He even uses
> compare() on operands that are known to be atoms.
>
> The case for breaking existing code must be based on actual empirical usage
> and not guessitmates on what and who will be affected.
>
> If it turns out that the cost of fixing existing code is too steep then we
> won't
> change, but if it is not more costly than perpetually having non-intuitive
> constructs
> then change should be considered.
>
>
> > Whats wrong with compare?
>
> Nothing per se, but to be consistant Euphoria coders should always use it
> rather
> than sometime use compare and sometimes use comparision operators.
>
> > Yes, there is an initial learning curve, but this would be true for any
> > programming language.
> >
> > > if intA = intB -- This works
> > > if seqA = seqB -- This fails
> >
> > Of course that should fail, one is an integer, and one is a sequence. This
> > seems
> > obvious to me, after I have had the errors thrown up, and searched for, and
> >
> > asked in this forum many times - this is part of the learning progress.
>
> And it feels good when one stops hitting one's head too. So I guess I better
> stop arguing for this 'cos I'm not going to convince anyone.
>
On the contrary Derek, don't stop arguing for it. My fear is that existing
code would break in the name of progress, not that new constructs could be used,
which at the same time would NOT break existing code. I'm not against progress,
just against change for change's sake.
Regards
Chris
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
