1. RE: Small feature request for future EU versions
CoJaBo wrote:
>
>
> posted by: CoJaBo <cojabo at suscom.net>
>
> Vincent wrote:
> >
> > It would be nice to have the '==' (equal comparison) relational
> > operator implemented in future versions of EU. Many programming
> Unfortunatly this, while it certainly be helpful, will probably never
> be added...
>
It sounds like we will be able to add it ourselves once 2.5 arrives.
> > languages have this operator for equal comparision, while EU
> > uses equal(). I doubt anyone will comfuse '==' with the '='
> > assignment operator. And if this is a compatibility issue,
> > keep the equal() ruitine until people agree that it is no longer
> If this is ever added, equal() should remain. '==' would simply
> be short for equal(). Less typing good!
>
bool = equal(s1,s2)
is just a shortcut for
bool = (compare(s1,s2) = 0)
I think I would prefer an operator like ==.
I think that is something that can be done in a preprocessor though.
Alot of the changes that people want can be done in a preprocessor, and
once 2.5 arrives, we will have the ability to edit the front end, I
beleive, which is even better than a preprocesor.
Chris Bensler
Code is Alchemy
2. RE: Small feature request for future EU versions
Chris Bensler wrote:
[snip]
>
> I think I would prefer an operator like ==.
And I would like '=' to only be an equality test, ':=' to only be an
assignment action and 'element_eq()' to be the sequence operation.
If we have '==' we should logically also have '<<', '>>', '!==', '<<='
and '>>='.
> I think that is something that can be done in a preprocessor though.
> Alot of the changes that people want can be done in a preprocessor, and
> once 2.5 arrives, we will have the ability to edit the front end, I
> beleive, which is even better than a preprocesor.
Yes, this is going to be survival-of-the-fitest game, with lots
of variants vying for attention.
--
Derek Parnell
Melbourne, Australia
3. RE: Small feature request for future EU versions
Derek Parnell wrote:
>
>
> posted by: Derek Parnell <ddparnell at bigpond.com>
>
> Chris Bensler wrote:
>
> [snip]
>
> >
> > I think I would prefer an operator like ==.
>
> And I would like '=' to only be an equality test, ':=' to only be an
> assignment action and 'element_eq()' to be the sequence operation.
>
> If we have '==' we should logically also have '<<', '>>', '!==', '<<='
> and '>>='.
>
That would work for me, change the behaviour of seq = seq, and use ==,
<< , etc.. for dimmed operators.
Chris Bensler
Code is Alchemy
4. RE: Small feature request for future EU versions
Pete Lomax wrote:
>
>
> On Sun, 17 Oct 2004 00:24:23 -0700, rudy toews
> <guest at RapidEuphoria.com> wrote:
>
> >> Derek Parnell wrote:
> >> > Yes, this is going to be survival-of-the-fitest game, with lots
> >> > of variants vying for attention.
> >please don't go off in different directions like pieces of a bomb.
> >communicate with each other
> FWIW, new operators are not actually needed, it is quite easy to
> greatly improve the language using the current ones.
>
> Taking the if <expr> then example, the interpreter should realise that
> <expr> must deliver a boolean result (or crash), in other words map
>
> e1<e2 to compare(e1,e2)=-1
> e1<=e2 to compare(e1,e2)!=1
> e1=e2 to equal(e1,e2),
> e1!=e2 to not equal(e1,e2),
> e1>=e2 to compare(e1,e2)!=-1
> e1>e2 to compare(e1,e2)=1
>
> Of course, it does not need to do this if e1 and e2 are both atoms.
>
> Taking this a step further "if <e1> and <e2> then" must also deliver a
> boolean result, which means the "need" for a boolean result must be
> propagated into e1 and e2. The same is true for all the other
> operators (not, unary minus, +, -, *, /, or, xor), and the same logic
> applies to while, for, subscript, and slice expressions, but not to
> assignments, constants, or parameters. If this all sounds horribly
> complicated, don't worry, in practice it's not. I already have this
> working in Posetf 
)
>
> Regards,
> Pete
>
The reason Euphoria crashes when you pass a sequence as a condition, is
because it assumes you made a mistake, rather than assuming what you
wanted to do, it plays dumb. I prefer it to behave exactly as I tell it
to. If it crashes, then I just have to fix it.
If it assumes what I meant, there is a good possibility, that is really
is a mistake, and eu will keep going, with perfectly valid execution,
eventhough it may be wrong, making it that much harder to find and fix.
Chris Bensler
Code is Alchemy
5. RE: Small feature request for future EU versions
Patrick Barnes wrote:
<SNIP>
> --cond2 will be {1,0,0,1}, because Euphoria compares each element.
>
> 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.
This concept can be implemented very cleanly actually, by 2 new rules.
The way I see it, 0 is absolute, either there are none or there are
some.
1. treat {} as FALSE.
2. a sequence is FALSE, only if the sum of all of it's elements is 0
Eg.
{} is FALSE
{0} is {FALSE} which is FALSE
{0,{0,{}}} converts to
{FALSE,{FALSE,FALSE}},
now flatten it to {FALSE,FALSE,FALSE}
the sum of {FALSE,FALSE,FALSE} is 0
{1,{0,{}}} converts to
{TRUE,{FALSE,FALSE}},
now flatten it to {TRUE,FALSE,FALSE}
the sum is 1
the sum of {1,1,0,{0,1,{1}}} would be 4, which is != 0
and is how conditions work now, by asumming only 0 means FALSE.
This behaviour would inform you that at least one element is true, and
you could proceed to check the sequence, in detail, while avoiding the
FALSE sequences.
For comparing sequences that are not the same length, euphoria should
still fail.
If you wanted to know if every element is true, you could use
compare() or equal().
<SNIP>
Chris Bensler
Code is Alchemy
6. RE: Small feature request for future EU versions
Chris Bensler wrote:
>
[snip]
>
> For comparing sequences that are not the same length, euphoria should
> still fail.
>
> If you wanted to know if every element is true, you could use
> compare() or equal().
I guess this is where you and I differ.
It seems that you would like equality (and relationship comparisions)
implemented as built-in functions (eg. equal(), compare() ) and
sequence operations performed by operators ('=', '<', etc...)
Whereas I'd prefer the reverse situation. I'd like relationship
comparisions to use operators and sequence operations to use built-in
functions.
I'd prefer that ...
cond1 = (seq1 = seq2)
to be interpreted as ...
if the contents of seq1 and the contents of seq2 are identical then
assign 'true' to cond1 otherwise assign 'false' to cond1.
If I really wanted a sequence operation to be performed as its result
to be assigned I'd rather write something like ...
cond1 = seqop_eq(seq1, seq2)
--
Derek Parnell
Melbourne, Australia
7. RE: Small feature request for future EU versions
Chris Bensler wrote:
> For comparing sequences that are not the same length, euphoria should
> still fail.
You're joking, right?
if "Sam" = "Sammy" then -- crash? give an error message?
No. They are just plain NOT EQUAL.
Any second grade child can tell you that.
What's the matter with Euphoria?
Irv
8. RE: Small feature request for future EU versions
irv mullins wrote:
>
> Chris Bensler wrote:
>
> > For comparing sequences that are not the same length, euphoria should
> > still fail.
>
> You're joking, right?
>
> if "Sam" = "Sammy" then -- crash? give an error message?
>
> No. They are just plain NOT EQUAL.
> Any second grade child can tell you that.
> What's the matter with Euphoria?
It has been a thorn in my side too that Euphoria interprets that as ...
Create a new sequence by comparing each corresponding element
in "Sam" and "Sammy". It then crashes because the number of elements
are different. But even if it could continue, it then says ...
And now test that new sequence to see if it's a boolean value. Of course
it isn't so it crashes.
The syntax for the 'if' is
if :: 'if' atom-expression 'then' [ statement ... ] etc...
but the problem is that the symbol '=' inside an expression in which
either operand is a sequence causes the result to be a sequence-expression.
The '=' is being interpreted as a sequence operation and not a test
for equality.
And yes, that is counter-intuitive.
I agree that sequence operations are valid but they are rarely used
and thus shouldn't reserve the commonly used symbols for their use.
Built-in functions are a much more appropriate implementation.
If RDS were to change Euphoria to behave as most people expect it to,
there would be some existing programs that would fail. But I suspect
that there would be very, very few of those. The pain is worth the gain.
--
Derek Parnell
Melbourne, Australia
9. 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
>
>
>
>
10. RE: Small feature request for future EU versions
Ricardo M. Forno wrote:
>
> 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.
Another alternative is to use function calls for sequence operations and
leave operators just for comparisions. To have the same syntax element do
multiple jobs, depending on context, can be a source of problems.
I agree with the C and Pascal comments you make, but the difference there
is that they are only dealing with assignment and comparisions, not
sequence operations as well. In Euphoria, '=' is used for three distinct
actions, depending on its context. I would propose that it, and the other
comparison operators, should be deprecated for sequence operations and
those (rarely used) activities be replaced with built-in functions.
--
Derek Parnell
Melbourne, Australia
11. RE: Small feature request for future EU versions
Hi, Juergen.
Your thinking is logical, and I agree that using different operators for
different purposes *should* be clearer. But, in my experience (and it seems
some other people had the same kind of experience), == or := versus = leads
to pitfalls.
I think this is due to the fact that all these operators contain the = sign.
This problem rarely arose in APL, where the assignation symbol was a left
arrow (such as <-, but a single character).
Regards.
----- Original Message -----
From: Juergen Luethje <j.lue at gmx.de>
To: <EUforum at topica.com>
Sent: Monday, October 18, 2004 5:20 AM
Subject: Re: Small feature request for future EU versions
>
>
> Ricardo Forno wrote:
>
> <snip>
>
> > 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 :=.
>
> <snip>
>
> That really surprises me. I was thinking that different symbols for
> different operations (comparison vs. assignment) would lead to clearer
> code and less pitfalls -- compared to Euphoria's '=', the meaning of
> which dependes on the context.
>
> Regards,
> Juergen
>
>
>
>
12. RE: Small feature request for future EU versions
----- Original Message -----
From: Igor Kachan <kinz at peterlink.ru>
To: <EUforum at topica.com>
Sent: Monday, October 25, 2004 8:57 AM
Subject: Re: Small feature request for future EU versions
>
>
> Hi, Dear EU users!
>
> Me wrote:
>
> [snip]
> > Me did not provide the universal function for any alphabet,
> > but a *way* to make the concrete function for concrete alphabet.
> [snip]
> > The task is not very difficult if you do know your native alphabet,
> > be sure, dear End Users.
>
> Let us try to use that way to make the concrete (i.e. specific, only
> this one, not any other) function for concrete well known alphabet
> -- pure Latin -- alphabet_la, just for example.
>
> }}}
<eucode>
>
> sequence alphabet_la
> alphabet_la="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
>
> global function case_LA(integer c, object x)
> -- case_LA -- to not confuse with the existing case_la() function
> -- convert Latin atom or sequence to upper or to lower case
> integer n
> sequence A, a
> if c then
> A=alphabet_la[1 ..26]
> a=alphabet_la[27..52]
> else
> a=alphabet_la[1 ..26]
> A=alphabet_la[27..52]
> end if
> n = 0
> if atom(x) then n=find(x,a)
> if n then return A[n]
> else return n end if
> else
> for i=1 to length(x) do
> n=find(x[i],a)
> if n then
> x[i] = A[n]
> end if
> end for
> end if
> return x
> end function -- case_LA()
>
> puts(1, alphabet_la & '\n')
> puts(1, case_LA(1, alphabet_la) & '\n')
> puts(1, case_LA(0, alphabet_la) & '\n')
>
> </eucode>
{{{
>
> Just replace the alphabet_la sequence with your native alphabet
> and you will have concrete function for your native language
> and for your current code page.
> If you see your alphabet correctly in your editor, all right.
> Do not forget, on DOS and Windows may be different results.
>
> Say,
> sequence alphabet_mj
> alphabet_mj = "......place here The Great Mumbo Jumbo Alphabet....."
>
> global function case_mj(integer c, object x)
> And so on.
>
> Do not forget:
> A=alphabet_mj[1 .. not 26, but needed number]
> a=alphabet_mj[not 27, but needed number .. not 52, but needed number]
> -- Just first and second half.
>
> ... is easy peasy, NO? -- by Pete Lomax
>
> But I just now found one old bug in my case_ru() function.
> Thanks for your questions!
>
> Regards,
> Igor Kachan
> kinz at peterlink.ru
Hi, Igor.
Your function is slow compared to other approaches.
Since in Euphoria (and also i C and other languages) a character is just a
number, may I suggest a change?
I think it would be much faster having two 256-character sequences, one
representing the "translation" of the other (characters in the same
position), and using the input characters as indexes.
This way, you will get not only a way to translate between upper and lower
case, but also (changing the sequences) to translate ASCII to EBCDIC or
vice-versa, or any translation character by character you want.
Regards.
13. RE: Small feature request for future EU versions
----- Original Message -----
From: Patrick Barnes <mrtrick at gmail.com>
To: <EUforum at topica.com>
Sent: Tuesday, October 26, 2004 9:05 PM
Subject: Re: Small feature request for future EU versions
>
> What I think he means is this:
>
> constant LA_up= "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
> constant LA_lo = "abcdefghijklmnopqrstuvwxyz"
> constant LA_diff = LA_up - LA_lo
>
> global function case_LA(integer c, object x)
> integer n
> if atom(x) then
> if c then
> n = find( x, LA_lo )
> if n then
> x += LA_diff[n]
> end if
> else
> n = find( x, LA_up )
> if n then
> x -= LA_diff[n]
> end if
> end if
> else
> for i = 1 to length(x) do
> x[i] = case_LA(c, x[i])
> end for
> end if
>
> return x
> end function
>
Well... not exactly this.
find() is a bit slow.
What I suggest is having a 256-character sequence from which you take the
character corresponding to the the one you want to translate, used as an
index.
For example, you know that 'A' is equal to 65 (its ASCII value). Assume then
that sequence X contains an 'a' in position 66, a 'b' in position 67, and so
on. So, to translate sequence Z from upper to lower case, you will code:
for i = 1 to length(Z) do
Z[i] = X[Z[i]+1]
end for
For an atom: C = X[C+1]
Adding 1 is necessary because Euphoria uses 1-origin indexing. C, instead,
uses 0-origin indexing, and consequently you do not have to add 1.
Something similar but oriented to translating whole files is one of my
contributions to The Archive, I dont remember under what name, at the
moment.
> > I like your suggestion, but I just do not see the solution how to make
> > this way the stable templet for *any* alphabet now.
>
> Works for any alphabet and code page, and is faster, because it
> doesn't have to keep slicing the alphabet sequences.
>
> > Some alphabets have no case at all, some alphabets have different
> > numbers of upper and lower letters.
> > For example, computer Russian has 3 extra letters in upper case, which
> > are absent in Russian canonical grammar.
>
> The limitation of the above function is that LA_up and LA_lo must be
> the same length... what do you mean by 3 extra letters? What if you
> try to convert them to lower case? If it should just leave them as
> upper case, that's fine - just leave them out of the function.
>
>
> ***The above function is completely untested. It should not be used in
> nuclear reactors, medical life support systems, or anywhere where
> failure may cause injury*** 
> --
> MrTrick
>
