RE: Small feature request for future EU versions
I think Euphoria, in this respect, is exactly as it should be.
To maintain laguage coherence / orthogonality, if {5,1,4}+{4,0,2} is {9,1,6}
as it is now, and similarly regarding subtraction, multiplication and
division, then {3,2,1}={4,2,1} should be {0,1,1}, and {5,7}>{8,6} should be
{0,1} and so on.
Comparing sequences is entirely another matter, and so I think the equal()
and compare() functions are all right.
If an improvement is needed, then equal() and compare() could be replaced by
other special characters or sets of same. remainder(a, b) is also a good
canditate to be replaced by a % b.
Moreover, please remember (or consider) that one of the most common pitfalls
in the C language is to use = instead of ==, and in Pascal and other ones,
to use = instead of :=.
This is my (perhaps not so) humble opinion.
Regards.
----- Original Message -----
From: irv mullins <guest at RapidEuphoria.com>
To: <EUforum at topica.com>
Sent: Sunday, October 17, 2004 10:38 PM
Subject: Re: Small feature request for future EU versions
>
>
> posted by: irv mullins <irvm at ellijay.com>
>
> Patrick Barnes wrote:
> >
> > On Sun, 17 Oct 2004 04:46:14 -0700, irv mullins <guest at
rapideuphoria.com> wrote:
> > > string and numeric comparisons? Several other languages do that
> > > without any problem.
> > >
> > > Irv
> >
> > The problem is this:
> >
> > constant
> > atom1=5,
> > atom2=10,
> > seq1={1,5,2,4},
> > seq2={1,2,5,4}
> >
> > constant cond1 = ( atom1 = atom2 )
> > constant cond2 = ( seq1 = seq2 )
> >
> > --cond1 will be 0, as 5 does not equal 10.
> > --cond2 will be {1,0,0,1}, because Euphoria compares each element.
>
> By any normal meaning of the word 'equal' as used by scientists,
mathematicians,
> programmers, and the corner grocer, the answer can not possibly
> be {1,0,0,1}. It is either TRUE or FALSE. If the lengths of the two
> sequences are different, then they are not equal, and the result should
> be FALSE - not an error.
>
> If, for some strange reason, someone wanted an item-by-item comparison
> between two sequences, then a new and more meaningful name should be
chosen
> for a function which returns {1,0,0,1}.
>
> > The problem is that the IF statement doesn't know what to do with a
> > sequence, and there's not an obvious solution.
> > As a quick hack, lets say that if the IF statement receives a
> > sequence, it treats it as true if every element is non-zero.
> >
> > That would allow us to easily compare strings using the simple form:
> > if string1 = string2.
> > However, what if the sequence passed to the IF statement is empty?
> > What if the sequence contains multiple levels?
> > What if the sequence contains a mix of non-zero integers, and an empty
sequence?
>
> You're thinking within the box built by RDS.
> No matter whether the sequences are empty, or contain multiple levels,
> if the two are identical, then they are equal, otherwise they aren't.
> That is the obvious definition of equal which anyone can understand.
>
> > I think that these things aren't easily solved...
>
> The whole thing could have been avoided if Rob had used the = operator
> to return equality and another operator or function to return a
comparison.
>
> ....
>
> > At least with the above suggestion, there's no broken compatibility, a
> > common issue (Why can't I just use '=' to compare these strings?) is
> > fixed, and it's a logical solution.
>
> I'll bet there aren't a dozen uses of = in the existing code base. I've
> used it exactly once, and I really don't mind changing that instance to
> some new function.
>
> Irv
>
>
>
>
|
Not Categorized, Please Help
|
|
