1. question on func equal_from
Would
r=equal_from(x,s,i)
be the same as
r=(match(x,s)=i)
but faster and
the same as
if i>=1 and length(s)>i+length(x)-1 then
r=equal[x,s[i..i+length(x)-1]]
else
r=0
end if
but simplier?
Why hasn't this also been implemented if we have match_from and find_from?
Cheers,
Salix
2. Re: question on func equal_from
equal_from() seem pointless to me as one can do, as you mention in your own
message:
r = match(x,s)=i -- no exertal perenthesis needed
regards,
jacques deschênes
Salix wrote:
>
> Would
> }}}
<eucode>
> r=equal_from(x,s,i)
> </eucode>
{{{
> be the same as
> }}}
<eucode>
> r=(match(x,s)=i)
> </eucode>
{{{
> but faster and
> the same as
> }}}
<eucode>
> if i>=1 and length(s)>i+length(x)-1 then
> r=equal[x,s[i..i+length(x)-1]]
> else
> r=0
> end if
> </eucode>
{{{
> but simplier?
>
> Why hasn't this also been implemented if we have match_from and find_from?
>
> Cheers,
>
> Salix
3. Re: question on func equal_from
jacques deschênes wrote:
>
>
> equal_from() seem pointless to me as one can do, as you mention in your own
> message:
> }}}
<eucode>
> r = match(x,s)=i -- no exertal perenthesis needed
> </eucode>
{{{
>
> regards,
> jacques deschênes
>
I do not think so.
Let's assume i=1000000. It means that x starts at position 1000000 in
sequence s. The match routine needs to go through the first 999999
elements of s to be able to return a result. (The result is 1000000.)
It is obviously a lot more time than jumping to position 1000000 and
to see if x is there. (But to jump there you would need to make sure
a few things including that 1000000<=length(s) and 1000000>=1.)
I haven't included a test code here but give a try.
So, my question remains. Why don't we have equal_from if speed
was such an important issue in case of find_from and match_from?
Cheers,
Salix
P.S.: Even match_from doesn't replace equal_from because length(s)
can be easily 999999999 or something like that.
4. Re: question on func equal_from
- Posted by Matt Lewis <matthewwalkerlewis at g?ail?com>
Jul 26, 2007
-
Last edited Jul 27, 2007
Salix wrote:
>
> So, my question remains. Why don't we have equal_from if speed
> was such an important issue in case of find_from and match_from?
>
> Cheers,
>
> Salix
>
> P.S.: Even match_from doesn't replace equal_from because length(s)
> can be easily 999999999 or something like that.
I agree that it's not a perfect replacement (especially in the pathological
case you mentioned), but is it something that would be used a lot? The
find_from() and match_from() routines were solutions to problems that
people had, whereas equal_from() doesn't seem to have the same demand.
The typical use cases for the *from()s were parsing some sort of string.
Perhaps replacing all occurrences of a certain set of characters, or
tokenizing based on a comma or a tab. There were many repetitive uses
of the function, and it gave a significant speed up. Is there a
similar use case for equal_from()?
I just don't think there's much gain in adding equal_from() to the
interpreter. The next obvious question would be: Why isn't there a
compare_from(). And the same argument applies.
Matt
5. Re: question on func equal_from
- Posted by Salix <salix at f?eem?il.hu>
Jul 26, 2007
-
Last edited Jul 27, 2007
> The typical use cases for the *from()s were parsing some sort of string.
> Perhaps replacing all occurrences of a certain set of characters, or
> tokenizing based on a comma or a tab. There were many repetitive uses
> of the function, and it gave a significant speed up. Is there a
> similar use case for equal_from()?
>
I think there is. I regularly use similar repetitive uses of the equal
function to find (many) keywords in long texts.
But my message is rather just a question that helps me to understand
how to argue and support a new feature to be implemented in the next
official relase...
(Although secretly I hoped some positive replies. 
)
Best regards,
Salix
P.S.: Actually my match_from bug report is linked to the very same
example. Instead of
constant tx="very long sequence"
for i=1 to length(tx) by 1 do
if i>7 and equal("https://",tx[i-7..i]) then
-- do something
elsif i>6 and equal("http://",tx[i-7..i]) then
-- do something
elsif i>5 and equal("ftp://",tx[i-7..i]) then
-- do something
end if
end for
I would use
for i=1 to length(tx) by 1 do
if match_from("https://",tx[1..i],i-7) then
-- do something
elsif match_from("http://",tx[1..i],i-6) then
-- do something
elsif match_from("ftp://",tx[1..i],i-5) then
-- do something
end if
end for
because it is nicer, although slower. (But with equal_from
it could be equally fast but even nicer!) :-]
6. Re: question on func equal_from
- Posted by c.k.lester <euphoric at ckles?er.com>
Jul 26, 2007
-
Last edited Jul 27, 2007
Salix wrote:
>
> constant tx="very long sequence"
>
> for i=1 to length(tx) by 1 do
> if i>7 and equal("https://",tx[i-7..i]) then
> -- do something
> elsif i>6 and equal("http://",tx[i-7..i]) then
> -- do something
> elsif i>5 and equal("ftp://",tx[i-7..i]) then
> -- do something
> end if
> end for
I admit I don't know what your data looks like, but
that seems too complicated and inefficient. why not
do something like this:
i = match("https://",tx)
if i = 7 then
elsif i = 6 then
elsif i = 5 then
end if
7. Re: question on func equal_from
- Posted by jacques deschênes <desja at ?lobetrotte?.net>
Jul 26, 2007
-
Last edited Jul 27, 2007
I'm not found of pushing everything in the core interpreter, it will become
overwheighted and more difficult to maintain.
A this time I would rather see:
1) adding object support
2) adding error handling support
As those 2 are parts of most used modern language.
Some are afraid of oop but it's really easy to catch.
jacques Deschênes
Salix wrote:
>
> jacques deschênes wrote:
> >
> >
> > equal_from() seem pointless to me as one can do, as you mention in your own
> > message:
> > }}}
<eucode>
> > r = match(x,s)=i -- no exertal perenthesis needed
> > </eucode>
{{{
> >
> > regards,
> > jacques deschênes
> >
>
> I do not think so.
>
> Let's assume i=1000000. It means that x starts at position 1000000 in
> sequence s. The match routine needs to go through the first 999999
> elements of s to be able to return a result. (The result is 1000000.)
>
> It is obviously a lot more time than jumping to position 1000000 and
> to see if x is there. (But to jump there you would need to make sure
> a few things including that 1000000<=length(s) and 1000000>=1.)
>
> I haven't included a test code here but give a try.
>
> So, my question remains. Why don't we have equal_from if speed
> was such an important issue in case of find_from and match_from?
>
> Cheers,
>
> Salix
>
> P.S.: Even match_from doesn't replace equal_from because length(s)
> can be easily 999999999 or something like that.
8. Re: question on func equal_from
- Posted by Kenneth Rhodes <ken_rhodes30436 at ya?oo.com>
Jul 26, 2007
-
Last edited Jul 27, 2007
jacques deschênes wrote:
>
> I'm not found of pushing everything in the core interpreter, it will become
I think you meant "fond", Jacques! 
overwheighted and more difficult to maintain.
> A this time I would rather see:
> 1) adding object support
> 2) adding error handling support
>
> As those 2 are parts of most used modern language.
> Some are afraid of oop but it's really easy to catch.
>
> jacques Deschênes
>
I'm no programmer, yet as an observer of how Euphoria over
the past decade or so, it appears to me that the lack of native
OOP support has been a factor in its lack of popularity.
I gather that routine_id(st) has enabled clever Euphoria
programmers to implement OOP in Euphoria, but somewhat
awkwardly and at the cost of speed. Mike Nelson, a brilliant
Euphoria programmer, has contributed perhaps 4 or 5 generations
of OOP Euphoria libraries - and he is currently working on yet another
one, "Methodica", which he considers to be a new language based on
Euphoria. More on Methodica here:
http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=7&toYear=C&postedBy=&keywords=methodica
Methodica sounds to me like a high level fork of Euphoria. Mike stated
in one of his posts that he would not attempt backwards compatibility
with Euphoria.
Would an effort to implement OOP in Euphoria be able to exploit
the talent of Mike Nelson, or someone like hime, toward the development
of Euphoria proper?
Would an efficient implementation of OOP in Euphoria require a
complete rewrite of the "C" front-end?
Didn't someone, perhaps Derek Parnell, suggest or even start a
project to implement Euphoria with OOP in "D"? Are their lessons
to be learned from his efforts?
Ken Rhodes
Folding at Home: http://folding.stanford.edu/
100% MicroSoft Free
SuSE Linux 10.0
No AdWare, SpyWare, or Viruses!
Life is Good,
9. Re: question on func equal_from
- Posted by ChrisBurch3 <crylex at g?ail.com>
Jul 26, 2007
-
Last edited Jul 27, 2007
jacques deschênes wrote:
>
> I'm not found of pushing everything in the core interpreter, it will become
> overwheighted and more difficult to maintain.
> A this time I would rather see:
> 1) adding object support
Sorry, I feel very strongly about this. Euphoria is NOT an OOP language, and
should NEVER become so at its core. Using the add on libraries is fine for those
that wish to do so, otherwise get off 'my' procedurals. There are many other
simpler
clearer ways of resorting to solutions rather than resorting to overly complex
and
needlessly obscure object orientated techniques - this is not the spirit of
Euphoria.
> 2) adding error handling support
Do we not already have that? Admittedly it may not be the catch all that other
languages have, but does it not serve its purpose? Is it not flexible enough
to adapt with a little ingenuity on the part of the programmer?
>
> As those 2 are parts of most used modern language.
> Some are afraid of oop but it's really easy to catch.
Again, sorry, I have to disagree. Its not easy to learn, and it adds a totally
unnecessary
level of complexity to any programming task. All of the arguments in favour of
oop can be equally dismissed by any procedural technique. If you want to use
objects
use an OOP language (C++, C#, Delphi, Visual Basic etc etc - Euphoria is not
trying to compete with these - is it?)
Regards
Chris
>
> jacques Deschênes
>
>
> Salix wrote:
> >
> > jacques deschênes wrote:
> > >
> > >
> > > equal_from() seem pointless to me as one can do, as you mention in your
> > > own
> > > message:
> > > }}}
<eucode>
> > > r = match(x,s)=i -- no exertal perenthesis needed
> > > </eucode>
{{{
> > >
> > > regards,
> > > jacques deschênes
> > >
> >
> > I do not think so.
> >
> > Let's assume i=1000000. It means that x starts at position 1000000 in
> > sequence s. The match routine needs to go through the first 999999
> > elements of s to be able to return a result. (The result is 1000000.)
> >
> > It is obviously a lot more time than jumping to position 1000000 and
> > to see if x is there. (But to jump there you would need to make sure
> > a few things including that 1000000<=length(s) and 1000000>=1.)
> >
> > I haven't included a test code here but give a try.
> >
> > So, my question remains. Why don't we have equal_from if speed
> > was such an important issue in case of find_from and match_from?
> >
> > Cheers,
> >
> > Salix
> >
> > P.S.: Even match_from doesn't replace equal_from because length(s)
> > can be easily 999999999 or something like that.
10. Re: question on func equal_from
Salix wrote:
> So, my question remains. Why don't we have equal_from if speed
> was such an important issue in case of find_from and match_from?
One of the reasons why find_from and match_from were needed is that the only way
to get at the fast scan code is to pass a slice. But an equal_from does not do a
scan, nor do you need to create a slice. You can instead code:
function match_at(sequence x, sequence s, integer pos)
if not length(x) then ?9/0 end if
if length(s)<pos+length(x)-1 then return false end if
for i=1 to length(x) do
if not equal(s[pos],x[i]) then return false end if
pos+=1
end for
return true
end function
Now I do not know what the actual gain might be were that coded in the back-end,
but it would be small, not the 100-fold gain I am fairly confident I could show
with either match_from or find_from.
HTH,
Pete
Ps it is not quite the same as r=(match(x,s)=i) in cases where match finds an
instance of x earlier on in s, eg match_at("the", "the the", 4) should yield true
but r would be false since 1<>4.
11. Re: question on func equal_from
I think Pete's reply gives me an answer for my original question. Thank you!
I haven't described in details the problem I'm trying to solve, and so
c.k.lester's suggestion doesn't really fit the case. At the same time
Pete's code is pretty close to the one I keep the best solution.
(I just skip the internal loop and named it string_end(x,s,pos).)
Thanks again!
Regards,
Salix
12. Re: question on func equal_from
Salix wrote:
>
> jacques deschênes wrote:
> >
> >
> > equal_from() seem pointless to me as one can do, as you mention in your own
> > message:
> > }}}
<eucode>
> > r = match(x,s)=i -- no exertal perenthesis needed
> > </eucode>
{{{
> >
> > regards,
> > jacques deschênes
> >
>
> I do not think so.
>
> Let's assume i=1000000. It means that x starts at position 1000000 in
> sequence s. The match routine needs to go through the first 999999
> elements of s to be able to return a result. (The result is 1000000.)
>
> It is obviously a lot more time than jumping to position 1000000 and
> to see if x is there. (But to jump there you would need to make sure
> a few things including that 1000000<=length(s) and 1000000>=1.)
>
> I haven't included a test code here but give a try.
>
> So, my question remains. Why don't we have equal_from if speed
> was such an important issue in case of find_from and match_from?
>
> Cheers,
>
> Salix
>
> P.S.: Even match_from doesn't replace equal_from because length(s)
> can be easily 999999999 or something like that.
There are several questions in the above one.
Is this function useful?
Yes, I use an equivalent rather often. I wish Euphoria had a "soft" sequence
assignment operator which would copy only what fits in the target sequence. Then
the function wouldn't be too useful. But this strays off topic.
Is the name right?
I'd suggest slice_at() rather, but don't care a lot.
Is it necessary to modify the interpreter to add it to the language?
I don't think so. Because of the way the interpreter is implemented, you won't
gain much by internalising code like this
function slice_at(seuence slice,sequence target,integer pstartpoint)
-- handle some negative indexes
integer pos, lt,ls
pos=startpoint
lt = length(target)
ls = length(slice)
if pos<0 then -- handle legitimate negative indexes
pos += 1+lt
end if
if pos<1 or pos>lt then
crash_message(
sprintf("slice_at(): %d is an invalid start point",startpoint))
?1/0
end if
if ls=0 then -- what's the point of matching an empty sequence?
return -1
end if
if pos+ls-1>lt then -- slice too long to fit at this point
return 0
end if
for i=1 to ls do
if compare(target[pos],slice[i]) then
return 0 -- slices differ
end if
pos += 1
end for
return 1 -- slice are equal
end function
The C code in be_execute.c wouldn't look much different, traslation is nearly
verbatim.
Is this a worthwhile addition to misc.e?
I'd say yes, as well as standard stuff to insert an element, delete an element,
insert a slice, replace a slice and such.
Oh, that is, if misc.e doesn't fork to sequence.e. After all, if misc.e includes
both math.e and sequence.e at the end, no code will break, I think.
CChris
13. Re: question on func equal_from
ChrisBurch3 wrote:
>
> jacques deschênes wrote:
> >
> > I'm not found of pushing everything in the core interpreter, it will become
> > overwheighted and more difficult to maintain.
> > A this time I would rather see:
> > 1) adding object support
>
> Sorry, I feel very strongly about this. Euphoria is NOT an OOP language, and
> should NEVER become so at its core. Using the add on libraries is fine for
> those
> that wish to do so, otherwise get off 'my' procedurals. There are many other
> simpler
> clearer ways of resorting to solutions rather than resorting to overly complex
> and
> needlessly obscure object orientated techniques - this is not the spirit of
> Euphoria.
>
>
> > 2) adding error handling support
>
> Do we not already have that? Admittedly it may not be the catch all that other
> languages have, but does it not serve its purpose? Is it not flexible enough
> to adapt with a little ingenuity on the part of the programmer?
>
> >
> > As those 2 are parts of most used modern language.
> > Some are afraid of oop but it's really easy to catch.
>
> Again, sorry, I have to disagree. Its not easy to learn, and it adds a totally
> unnecessary
> level of complexity to any programming task. All of the arguments in favour
> of
> oop can be equally dismissed by any procedural technique. If you want to use
> objects
> use an OOP language (C++, C#, Delphi, Visual Basic etc etc - Euphoria is not
> trying to compete with these - is it?)
>
> Regards
>
> Chris
> >
> > jacques Deschênes
> >
> >
> > Salix wrote:
> > >
> > > jacques deschênes wrote:
> > > >
> > > >
> > > > equal_from() seem pointless to me as one can do, as you mention in your
> > > > own
> > > > message:
> > > > }}}
<eucode>
> > > > r = match(x,s)=i -- no exertal perenthesis needed
> > > > </eucode>
{{{
> > > >
> > > > regards,
> > > > jacques deschênes
> > > >
> > >
> > > I do not think so.
> > >
> > > Let's assume i=1000000. It means that x starts at position 1000000 in
> > > sequence s. The match routine needs to go through the first 999999
> > > elements of s to be able to return a result. (The result is 1000000.)
> > >
> > > It is obviously a lot more time than jumping to position 1000000 and
> > > to see if x is there. (But to jump there you would need to make sure
> > > a few things including that 1000000<=length(s) and 1000000>=1.)
> > >
> > > I haven't included a test code here but give a try.
> > >
> > > So, my question remains. Why don't we have equal_from if speed
> > > was such an important issue in case of find_from and match_from?
> > >
> > > Cheers,
> > >
> > > Salix
> > >
> > > P.S.: Even match_from doesn't replace equal_from because length(s)
> > > can be easily 999999999 or something like that.
While I completely disagree with each and every statement above, let me add a
couple remarks.
Euphoria doesn't have to be an OO language, and never has been. However, why
shouldn't it _allow_ OO programming? If you don't like it, just don't use the
relevant feature, why do you want to force your opinion upon us? And if it allows
OO programming, it can hardly be done in external libraries. It can be done, but
so inefficiently.
For _certain_ types of programming tasks, OO makes coding lightning simple and
maintainable. While everything OO can be done in a non OO way - machine language
is not OO after all -, it is so at the cost of hacks, convoluted execution flows
and much more pain, for a slowed down result. Why should we have to choose
between Euphoria and C++? Let the language accommodate both types of programming.
After all, this is what Methodica is trying to achieve if I got it right - I
can't wait to see something rolling off from there.
CChris
14. Re: question on func equal_from
CChris wrote:
>
> ChrisBurch3 wrote:
> >
> > jacques deschênes wrote:
> > >
> > > I'm not found of pushing everything in the core interpreter, it will
> > > become
> > > overwheighted and more difficult to maintain.
> > > A this time I would rather see:
> > > 1) adding object support
> >
> > Sorry, I feel very strongly about this. Euphoria is NOT an OOP language, and
> > should NEVER become so at its core. Using the add on libraries is fine for
> > those
> > that wish to do so, otherwise get off 'my' procedurals. There are many other
> > simpler
> > clearer ways of resorting to solutions rather than resorting to overly
> > complex
> > and
> > needlessly obscure object orientated techniques - this is not the spirit of
> > Euphoria.
> >
> >
> > > 2) adding error handling support
> >
> > Do we not already have that? Admittedly it may not be the catch all that
> > other
> > languages have, but does it not serve its purpose? Is it not flexible enough
> > to adapt with a little ingenuity on the part of the programmer?
> >
> > >
> > > As those 2 are parts of most used modern language.
> > > Some are afraid of oop but it's really easy to catch.
> >
> > Again, sorry, I have to disagree. Its not easy to learn, and it adds a
> > totally
> > unnecessary
> > level of complexity to any programming task. All of the arguments in favour
> > of
> > oop can be equally dismissed by any procedural technique. If you want to use
> > objects
> > use an OOP language (C++, C#, Delphi, Visual Basic etc etc - Euphoria is not
> > trying to compete with these - is it?)
> >
> > Regards
> >
> > Chris
> > >
> > > jacques Deschênes
> > >
> > >
> > > Salix wrote:
> > > >
> > > > jacques deschênes wrote:
> > > > >
> > > > >
> > > > > equal_from() seem pointless to me as one can do, as you mention in
> > > > > your own
> > > > > message:
> > > > > }}}
<eucode>
> > > > > r = match(x,s)=i -- no exertal perenthesis needed
> > > > > </eucode>
{{{
> > > > >
> > > > > regards,
> > > > > jacques deschênes
> > > > >
> > > >
> > > > I do not think so.
> > > >
> > > > Let's assume i=1000000. It means that x starts at position 1000000 in
> > > > sequence s. The match routine needs to go through the first 999999
> > > > elements of s to be able to return a result. (The result is 1000000.)
> > > >
> > > > It is obviously a lot more time than jumping to position 1000000 and
> > > > to see if x is there. (But to jump there you would need to make sure
> > > > a few things including that 1000000<=length(s) and 1000000>=1.)
> > > >
> > > > I haven't included a test code here but give a try.
> > > >
> > > > So, my question remains. Why don't we have equal_from if speed
> > > > was such an important issue in case of find_from and match_from?
> > > >
> > > > Cheers,
> > > >
> > > > Salix
> > > >
> > > > P.S.: Even match_from doesn't replace equal_from because length(s)
> > > > can be easily 999999999 or something like that.
>
Hi
I've had fewer glasses of wine now, so I'm less militant.
> While I completely disagree with each and every statement above, let me add
> a couple remarks.
Of course you do - that is the nature of the 'war' between oop and procedural
(non-oop) programming.
>
> Euphoria doesn't have to be an OO language, and never has been. However, why
> shouldn't it _allow_ OO programming? If you don't like it, just don't use the
> relevant feature, why do you want to force your opinion upon us? And if it
> allows
> OO programming, it can hardly be done in external libraries. It can be done,
> but so inefficiently.
If OOP is implememented in the core of Euphoria, will it degrade its current
efficiency / speed levels? If it doesn't, then I have no 'object'ion whatsoever
to having it added. You are right, I do not wish to impose my opinions on
anyone else, and you can do whatever you wish the language, as long as
1. It doesn't degrade it (speed / efficiency / code maintanability etc)
2. Doesn't break backward compatability
As I've said so many times before, there are many better programmers out there
than myself (yourself included Chris), who I have great respect for, but at the
end of the day, the developers are a relatively mall proportion of euphoria
users,
and you should be equally careful that you also don't impose your opinions on
others,
just because you believe it is the right thing to do.
>
> For _certain_ types of programming tasks, OO makes coding lightning simple and
> maintainable. While everything OO can be done in a non OO way - machine
> language
> is not OO after all -, it is so at the cost of hacks, convoluted execution
> flows
> and much more pain, for a slowed down result. Why should we have to choose
> between
> Euphoria and C++? Let the language accommodate both types of programming.
> After
> all, this is what Methodica is trying to achieve if I got it right - I can't
> wait to see something rolling off from there.
I once had an argument on another board about OOP versus procedural programming
-
it turns out there is no right or wrong answer - use the tool you for the task.
I did find this 'reference' though.
http://www.geocities.com/tablizer/oopbad.htm
Contrary to what you may believe, I am not trying to stagnate the language, and
if
oop could be integrated into euphoria invisibly, and painlessly, then that
would be fantastic, what I am trying to caution against is progressing too
fast, and leaving behind all the faithful users, and deviating the language
from its core principals (which is what keeps me programming in it.)
Chris
>
> CChris
15. Re: question on func equal_from
ChrisBurch2 wrote:
>
> CChris wrote:
> >
> > ChrisBurch3 wrote:
> > >
> > > jacques deschênes wrote:
> > > >
> > > > I'm not found of pushing everything in the core interpreter, it will
> > > > become
> > > > overwheighted and more difficult to maintain.
> > > > A this time I would rather see:
> > > > 1) adding object support
> > >
> > > Sorry, I feel very strongly about this. Euphoria is NOT an OOP language,
> > > and
> > > should NEVER become so at its core. Using the add on libraries is fine for
> > > those
> > > that wish to do so, otherwise get off 'my' procedurals. There are many
> > > other
> > > simpler
> > > clearer ways of resorting to solutions rather than resorting to overly
> > > complex
> > > and
> > > needlessly obscure object orientated techniques - this is not the spirit
> > > of
> > > Euphoria.
> > >
> > >
> > > > 2) adding error handling support
> > >
> > > Do we not already have that? Admittedly it may not be the catch all that
> > > other
> > > languages have, but does it not serve its purpose? Is it not flexible
> > > enough
> > > to adapt with a little ingenuity on the part of the programmer?
> > >
> > > >
> > > > As those 2 are parts of most used modern language.
> > > > Some are afraid of oop but it's really easy to catch.
> > >
> > > Again, sorry, I have to disagree. Its not easy to learn, and it adds a
> > > totally
> > > unnecessary
> > > level of complexity to any programming task. All of the arguments in
> > > favour
> > > of
> > > oop can be equally dismissed by any procedural technique. If you want to
> > > use
> > > objects
> > > use an OOP language (C++, C#, Delphi, Visual Basic etc etc - Euphoria is
> > > not
> > > trying to compete with these - is it?)
> > >
> > > Regards
> > >
> > > Chris
> > > >
> > > > jacques Deschênes
> > > >
> > > >
> > > > Salix wrote:
> > > > >
> > > > > jacques deschênes wrote:
> > > > > >
> > > > > >
> > > > > > equal_from() seem pointless to me as one can do, as you mention in
> > > > > > your
> own</font></i>
> > > > > > message:
> > > > > > }}}
<eucode>
> > > > > > r = match(x,s)=i -- no exertal perenthesis needed
> > > > > > </eucode>
{{{
> > > > > >
> > > > > > regards,
> > > > > > jacques deschênes
> > > > > >
> > > > >
> > > > > I do not think so.
> > > > >
> > > > > Let's assume i=1000000. It means that x starts at position 1000000 in
> > > > > sequence s. The match routine needs to go through the first 999999
> > > > > elements of s to be able to return a result. (The result is 1000000.)
> > > > >
> > > > > It is obviously a lot more time than jumping to position 1000000 and
> > > > > to see if x is there. (But to jump there you would need to make sure
> > > > > a few things including that 1000000<=length(s) and 1000000>=1.)
> > > > >
> > > > > I haven't included a test code here but give a try.
> > > > >
> > > > > So, my question remains. Why don't we have equal_from if speed
> > > > > was such an important issue in case of find_from and match_from?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Salix
> > > > >
> > > > > P.S.: Even match_from doesn't replace equal_from because length(s)
> > > > > can be easily 999999999 or something like that.
> >
> Hi
>
> I've had fewer glasses of wine now, so I'm less militant.
>
> > While I completely disagree with each and every statement above, let me add
> > a couple remarks.
> Of course you do - that is the nature of the 'war' between oop and procedural
> (non-oop) programming.
>
> >
> > Euphoria doesn't have to be an OO language, and never has been. However, why
> > shouldn't it _allow_ OO programming? If you don't like it, just don't use
> > the
> > relevant feature, why do you want to force your opinion upon us? And if it
> > allows
> > OO programming, it can hardly be done in external libraries. It can be done,
> > but so inefficiently.
>
> If OOP is implememented in the core of Euphoria, will it degrade its current
> efficiency / speed levels? If it doesn't, then I have no 'object'ion
> whatsoever
> to having it added. You are right, I do not wish to impose my opinions on
> anyone else, and you can do whatever you wish the language, as long as
>
> 1. It doesn't degrade it (speed / efficiency / code maintanability etc)
> 2. Doesn't break backward compatability
>
> As I've said so many times before, there are many better programmers out there
> than myself (yourself included Chris), who I have great respect for, but at
> the
> end of the day, the developers are a relatively mall proportion of euphoria
> users,
> and you should be equally careful that you also don't impose your opinions on
> others,
> just because you believe it is the right thing to do.
>
> >
> > For _certain_ types of programming tasks, OO makes coding lightning simple
> > and
> > maintainable. While everything OO can be done in a non OO way - machine
> > language
> > is not OO after all -, it is so at the cost of hacks, convoluted execution
> > flows
> > and much more pain, for a slowed down result. Why should we have to choose
> > between
> > Euphoria and C++? Let the language accommodate both types of programming.
> > After
> > all, this is what Methodica is trying to achieve if I got it right - I can't
> > wait to see something rolling off from there.
>
> I once had an argument on another board about OOP versus procedural
> programming
> -
> it turns out there is no right or wrong answer - use the tool you for the
> task.
> I did find this 'reference' though.
>
> <a
> href="http://www.geocities.com/tablizer/oopbad.htm">http://www.geocities.com/tablizer/oopbad.htm</a>
>
> Contrary to what you may believe, I am not trying to stagnate the language,
> and if
> oop could be integrated into euphoria invisibly, and painlessly, then that
> would be fantastic, what I am trying to caution against is progressing too
> fast, and leaving behind all the faithful users, and deviating the language
> from its core principals (which is what keeps me programming in it.)
>
> Chris
>
I had read this paper already, and it has left me unconvinced. Also, if I
thought that OOP is THE way to go, I'd be only in the Eiffel forum, not here as
wel (WEL is Eiffel's win32lib, sort of, but with a very strong GTK accent). OOP
must not be forced on anyone, but preferrably allowed to anyone.
Since Eiffel is a class based object lanuage, I see it as nearly incompatible
with Eu.
From having worked with the souce files Eu uses, I don't think there would be
any performance problem in parsing source code that would have OO constructs
inside. Polymorphic sites will take longer than regular routine calls because of
the added indirection, but that won't slow down the regular calls - perhaps a
couple extra tests, you'll notice a .003% slowdown. Flexibility and speed are two
roads that eventually go in different directions, even if they can be made to
travel together for a while.
The only thing which could be a problem is with type checking. The current way
Eu checks basic types is extremely fast, but extremely inflexible, and nearly
blocks any attempt to have more native types, like C srings, machine size
integers, classes or whatnot. Building a more flexible system which would be
almost as fast is probably doable, but it's not for the faint of heart.
CChris
16. Re: question on func equal_from
ChrisBurch2 wrote:
>
> If OOP is implememented in the core of Euphoria, will it degrade its current
> efficiency / speed levels? If it doesn't, then I have no 'object'ion
> whatsoever
> to having it added. You are right, I do not wish to impose my opinions on
> anyone else, and you can do whatever you wish the language, as long as
>
> 1. It doesn't degrade it (speed / efficiency / code maintanability etc)
> 2. Doesn't break backward compatability
>
I believe that ooeu satisfies these conditions. I wouldn't, however, claim
that it is a 'full' OO system. It lacks real polymorphism, although I've
thought about it, and I think it could be done quite reasonably.
There's probably a slight slowdown in the front end, but I doubt that it's
significant, especially for code that doesn't use any of the OO features.
The il code is actually 100% vanilla eu code. Basically, the front end just
converts an OO-call to normal euphoria calls (kinda like C++ does). For
example:
euclass Foo( sequence f )
-- Declaring variables inside of a euclass define the members of a euclass.
-- Automatic constants are created: Foo.baz can be used, and would equal
-- 1. Or dot notation is available for variables of type Foo: foo.baz
integer baz
function Foo() : Foo -- the ": Foo" just lets the front end know
-- the return type of the function
return {0}
end function
procedure bar()
? this
end procedure
end euclass
Foo foo
foo = Foo() -- calls the Foo constructor to initialize foo
-- calls the Foo.bar() method, which internally, really looks
-- like bar( Foo this ), and the procedure call is equivalent
-- to bar( foo )
foo.bar()
? foo.baz -- equivalent to foo[Foo.baz], or foo[1]
Again, this code would emit normal euphoria il code, no back-end magic
required. I think it does need (as CChris alluded) some run-time type
checking enhancement, as well as virtual routines, which would require
some back-end magic, but, again, shouldn't affect non-OO code at all.
For some tasks, OO languages drive me nuts, but there are other times when
they really do make some things a lot easier.
Matt
