1. New slice operator
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> > Performing bound checking in an include file is a waste of time, since the
> > backend
> > will perform some bound checking regardless. Testing twice doesn't add any
> > value
> > and wastes CPU. Even more so as thee operations easily occur in loops.
>
> Bounds checking was the wrong word. What I mean to say is: I want up to the
> first 30 items in a sequence. That's all I need. That's all I want to display.
> So, to do that currently you must:
>
> }}}
<eucode>
> if length(s) > 30 then
> s = s[1..30]
> end if
> puts(1, s)
> </eucode>
{{{
>
> Now, you can simply:
>
> }}}
<eucode>
> puts(1, head(s, 30))
> </eucode>
{{{
>
How about this:
puts(1,s[1~30])
Matt wrote:
> My thought is, "Is there really a need for this stuff?" There are better
> ways to do this in euphoria. This seems like a very BASIC-y way to do
> things. I don't think we should include this in the standard library.
With the introduction of a new slice operator (~ in the above expression) it's
possible to do what you want with functions like left()/head(), right()/tail()
and mid(). This would respect the Euphoria style.
I know that a new operator cannot be implemented in the standard library, but
possibly the modification in the Euphoria source code (front and backend) isn't
difficult. You would use the new slice operator when you DON'T know the length of
a sequence, otherwise you continue to use the original slice operator '..' to
have bounds checking.
A possible definition of the new operator '~' is:
s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
I think this should be made in backend C-code. The implementation could use
conditional statements instead of min and max functions.
Then I think we would have the following equivalences:
left(s,a) =: s[1~a]
right(s,a) =: s[$-a+1~$]
mid(s,a,b) =: s[a~b]
Note that, by the definition, the new operator '~' would continue to alert when
b<a-1 like the '..' operator. For all other cases there wouldn't be any
restriction in a and b. If you access a range outside of a sequence, it results
in {}.
Some advantages:
1) Use Euphoria style;
2) Can use less characters than the function call;
3) Less functions to learn and memorize, more international syntax;
4) Less functions to conflict with;
Disadvantages:
1) Modification in the front and backend code;
2) Learn a new operator;
Examples:
name = "John"
name = name[1~35]
puts(1,name) -- "John"
name = "John Doe"
name = name[$-3+1~$]
puts(1,name) -- "Doe"
For a test of the definition:
function max(atom a, atom b)
if a > b then return a
else return b
end if
end function
function min(atom a, atom b)
if a < b then return a
else return b
end if
end function
function tilde(sequence s, atom a, atom b)
printf(1,"s[%d~%d] = ",{a,b})
return s[min(max(1,a),$+1) .. min($,b)]
end function
sequence s
s = {0,1,2,3,4}
?tilde(s,0,1)
?tilde(s,-1,1)
?tilde(s,1,5)
?tilde(s,1,10)
?tilde(s,6,10)
?tilde(s,3,2)
Results:
s[0~1] = {0}
s[-1~1] = {0}
s[1~5] = {0,1,2,3,4}
s[1~10] = {0,1,2,3,4}
s[6~10] = {}
s[3~2] = {}
This post doesn't mean that I'm against the implementation of that functions in
the standard library. This is just an idea that maybe makes sense??
Regards,
Fernando
2. Re: New slice operator
Fernando Bauer wrote:
> A possible definition of the new operator '~' is:
> s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
You're really trying to aggravate those of us with US keyboards, aren't you? :D
How about the colon, instead?
x[1:4]
That's a little easier.
3. Re: New slice operator
c.k.lester wrote:
>
> Fernando Bauer wrote:
> > A possible definition of the new operator '~' is:
> > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
>
> You're really trying to aggravate those of us with US keyboards, aren't you?
> :D
After the invention of QWERTY keyboard, nothing more is so bad. 
>
> How about the colon, instead?
>
> x[1:4]
>
> That's a little easier.
I proposed the 'tilde' just because it can represent the idea of range like the
character '-' and it's not used.
How do you distinguish a slice s[a:b] from a variable subscript with a namespace
s[a:b]?
Regards,
Fernando
4. Re: New slice operator
c.k.lester wrote:
>
> Fernando Bauer wrote:
> > A possible definition of the new operator '~' is:
> > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
>
> You're really trying to aggravate those of us with US keyboards, aren't you?
> :D
>
> How about the colon, instead?
>
> x[1:4]
>
> That's a little easier.
It's the same keystrokes, different paws! How is it easier?
Kat
5. Re: New slice operator
c.k.lester wrote:
> How about the colon, instead?
> x[1:4]
> That's a little easier.
Euphoria Manual, 2.2.6 Slicing of Sequences
A sequence of consecutive elements may be selected by giving the starting
and ending element numbers. If y has the value: {"fred", "george", "mary"}
then it can be sliced using horizontal colon or vertical colon. Using
horizontal colon: y[1..2] is {"fred", "george"} but y[3..9] will result in
run-time error. If vertical colon is used, y[1:2] will give the same
result, but y[3:9] will result in {"mary"}, the same effect achieved as if
you used y[3..3].
What a ...
Every programmer newbie will use : instead of .. because of the avoidance
of error.
6. Re: New slice operator
Kat wrote:
>
> It's the same keystrokes, different paws! How is it easier?
I don't have to reach all the way up to the top row, corner key!!!!1!!!1!1!1
:P
7. Re: New slice operator
yuku wrote:
>
> run-time error. If vertical colon is used, y[1:2] will give the same
> result, but y[3:9] will result in {"mary"}, the same effect achieved as if
> you used y[3..3].
What the?! Is that real? I never knew Euphoria did that.
8. Re: New slice operator
Fernando Bauer wrote:
> How about this:
> }}}
<eucode>
> puts(1,s[1~30])
> </eucode>
{{{
>
> Matt wrote:
> > My thought is, "Is there really a need for this stuff?" There are better
> > ways to do this in euphoria. This seems like a very BASIC-y way to do
> > things. I don't think we should include this in the standard library.
>
> With the introduction of a new slice operator (~ in the above expression) it's
> possible to do what you want with functions like left()/head(), right()/tail()
> and mid(). This would respect the Euphoria style.
> I know that a new operator cannot be implemented in the standard library, but
> possibly the modification in the Euphoria source code (front and backend)
> isn't
> difficult. You would use the new slice operator when you DON'T know the length
> of a sequence, otherwise you continue to use the original slice operator '..'
> to have bounds checking.
> A possible definition of the new operator '~' is:
> s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
>
> I think this should be made in backend C-code. The implementation could use
> conditional statements instead of min and max functions.
> Then I think we would have the following equivalences:
> left(s,a) =: s[1~a]
> right(s,a) =: s[$-a+1~$]
> mid(s,a,b) =: s[a~b]
>
> Note that, by the definition, the new operator '~' would continue to alert
> when
> b<a-1 like the '..' operator. For all other cases there wouldn't be any
> restriction
> in a and b. If you access a range outside of a sequence, it results in {}.
> Some advantages:
> 1) Use Euphoria style;
> 2) Can use less characters than the function call;
> 3) Less functions to learn and memorize, more international syntax;
> 4) Less functions to conflict with;
>
> Disadvantages:
> 1) Modification in the front and backend code;
> 2) Learn a new operator;
>
> Examples:
> }}}
<eucode>
> name = "John"
> name = name[1~35]
> puts(1,name) -- "John"
> name = "John Doe"
> name = name[$-3+1~$]
> puts(1,name) -- "Doe"
> </eucode>
{{{
>
> For a test of the definition:
>
> }}}
<eucode>
> function max(atom a, atom b)
> if a > b then return a
> else return b
> end if
> end function
>
> function min(atom a, atom b)
> if a < b then return a
> else return b
> end if
> end function
>
> function tilde(sequence s, atom a, atom b)
> printf(1,"s[%d~%d] = ",{a,b})
> return s[min(max(1,a),$+1) .. min($,b)]
> end function
>
> sequence s
> s = {0,1,2,3,4}
> ?tilde(s,0,1)
> ?tilde(s,-1,1)
> ?tilde(s,1,5)
> ?tilde(s,1,10)
> ?tilde(s,6,10)
> ?tilde(s,3,2)
> </eucode>
{{{
>
> Results:
> s[0~1] = {0}
> s[-1~1] = {0}
> s[1~5] = {0,1,2,3,4}
> s[1~10] = {0,1,2,3,4}
> s[6~10] = {}
> s[3~2] = {}
>
> This post doesn't mean that I'm against the implementation of that functions
> in the standard library. This is just an idea that maybe makes sense??
>
> Regards,
> Fernando
This is an interesting proposal. I was thinking more about the head/tail issue
today.
Hey, I guess almost anything is better than car/cdr!
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
9. Re: New slice operator
Jason Gade wrote:
>
> Fernando Bauer wrote:
> > How about this:
> > }}}
<eucode>
> > puts(1,s[1~30])
> > </eucode>
{{{
> >
> > Matt wrote:
> > > My thought is, "Is there really a need for this stuff?" There are better
> > > ways to do this in euphoria. This seems like a very BASIC-y way to do
> > > things. I don't think we should include this in the standard library.
I think this is all rather redundant. We already have
a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
10. Re: New slice operator
Shawn Pringle wrote:
>
> Jason Gade wrote:
> >
> > Fernando Bauer wrote:
> > > How about this:
> > > }}}
<eucode>
> > > puts(1,s[1~30])
> > > </eucode>
{{{
> > >
> > > Matt wrote:
> > > > My thought is, "Is there really a need for this stuff?" There are
> > > > better
> > > > ways to do this in euphoria. This seems like a very BASIC-y way to do
> > > > things. I don't think we should include this in the standard library.
>
> I think this is all rather redundant. We already have
> a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
The object is to return all of the elements up to either the end or 30,
whichever is longer. The normal slice operator would return an error if length(s)
< 30.
I'm not proposing it, I just think that it's an interesting topic for
discussion. Fernando proposed it.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
11. Re: New slice operator
- Posted by don cole <doncole at pacbell.n??>
Apr 26, 2008
-
Last edited Apr 27, 2008
Jason Gade wrote:
>
> Shawn Pringle wrote:
> >
> > Jason Gade wrote:
> > >
> > > Fernando Bauer wrote:
> > > > How about this:
> > > > }}}
<eucode>
> > > > puts(1,s[1~30])
> > > > </eucode>
{{{
> > > >
> > > > Matt wrote:
> > > > > My thought is, "Is there really a need for this stuff?" There are
> > > > > better
> > > > > ways to do this in euphoria. This seems like a very BASIC-y way to do
> > > > >
> > > > > things. I don't think we should include this in the standard library.
> >
> > I think this is all rather redundant. We already have
> > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
>
> The object is to return all of the elements up to either the end or 30,
> whichever
> is longer. The normal slice operator would return an error if length(s) <
> 30.
As it should.
If the coder is asking for something longer that he/she has created then
he/she should get an error.
I think the coding is just perfect the way it is.
> I'm not proposing it, I just think that it's an interesting topic for
> discussion.
> Fernando proposed it.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
Don Cole
12. Re: New slice operator
- Posted by Jason Gade <jaygade at y?hoo.?om>
Apr 26, 2008
-
Last edited Apr 27, 2008
don cole wrote:
>
> Jason Gade wrote:
> >
> > Shawn Pringle wrote:
> > >
> > > Jason Gade wrote:
> > > >
> > > > Fernando Bauer wrote:
> > > > > How about this:
> > > > > }}}
<eucode>
> > > > > puts(1,s[1~30])
> > > > > </eucode>
{{{
> > > > >
> > > > > Matt wrote:
> > > > > > My thought is, "Is there really a need for this stuff?" There are
> > > > > > better
> > > > > > ways to do this in euphoria. This seems like a very BASIC-y way to
> > > > > > do
> > > > > > things. I don't think we should include this in the standard
> > > > > > library.
> > >
> > > I think this is all rather redundant. We already have
> > > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
> >
> > The object is to return all of the elements up to either the end or 30,
> > whichever
> > is longer. The normal slice operator would return an error if length(s) <
> > 30.
>
> As it should.
>
> If the coder is asking for something longer that he/she has created then
>
> he/she should get an error.
>
> I think the coding is just perfect the way it is.
>
> > I'm not proposing it, I just think that it's an interesting topic for
> > discussion.
> > Fernando proposed it.
> >
> > --
> > A complex system that works is invariably found to have evolved from a
> > simple
> > system that works.
> > --John Gall's 15th law of Systemantics.
> >
> > "Premature optimization is the root of all evil in programming."
> > --C.A.R. Hoare
> >
> > j.
>
>
> Don Cole
Although I wasn't in the IRC discussion, I just read the logs and I see that the
consensus was to stick with "head()" and "tail()" in the standard library, with
which I can agree.
No need to add new operators. It was worth discussing, though.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: New slice operator
- Posted by CChris <christian.cuvier at agri?ultur?.gouv.fr>
Apr 27, 2008
-
Last edited Apr 28, 2008
c.k.lester wrote:
>
> Fernando Bauer wrote:
> > A possible definition of the new operator '~' is:
> > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)]
>
> You're really trying to aggravate those of us with US keyboards, aren't you?
> :D
>
> How about the colon, instead?
>
> x[1:4]
>
> That's a little easier.
So, is s[x:y] a single or slice assignment? No one can tell.
CChris
14. Re: New slice operator
- Posted by CChris <christian.cuvier at agric??ture.gouv.fr>
Apr 27, 2008
-
Last edited Apr 28, 2008
don cole wrote:
>
> Jason Gade wrote:
> >
> > Shawn Pringle wrote:
> > >
> > > Jason Gade wrote:
> > > >
> > > > Fernando Bauer wrote:
> > > > > How about this:
> > > > > }}}
<eucode>
> > > > > puts(1,s[1~30])
> > > > > </eucode>
{{{
> > > > >
> > > > > Matt wrote:
> > > > > > My thought is, "Is there really a need for this stuff?" There are
> > > > > > better
> > > > > > ways to do this in euphoria. This seems like a very BASIC-y way to
> > > > > > do
> > > > > > things. I don't think we should include this in the standard
> > > > > > library.
> > >
> > > I think this is all rather redundant. We already have
> > > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
> >
> > The object is to return all of the elements up to either the end or 30,
> > whichever
> > is longer. The normal slice operator would return an error if length(s) <
> > 30.
>
> As it should.
>
> If the coder is asking for something longer that he/she has created then
>
> he/she should get an error.
>
> I think the coding is just perfect the way it is.
>
> > I'm not proposing it, I just think that it's an interesting topic for
> > discussion.
> > Fernando proposed it.
> >
> > --
> > A complex system that works is invariably found to have evolved from a
> > simple
> > system that works.
> > --John Gall's 15th law of Systemantics.
> >
> > "Premature optimization is the root of all evil in programming."
> > --C.A.R. Hoare
> >
> > j.
>
>
> Don Cole
No, no and no!
Do you really think a function that checks whether the next word is "while"
should error out if the line is shorter than 5 chars? You wind up with this
function Equals(sequence s,integer i,sequence pattern)
if i<1 or i>length(s)-length(pattern)+1 then
return 0
else
return equal(s[i..i+length(pattern)-1],pattern)
end if
end function
Look at the amount of generated code (use Matt's ildisasm out of curiosity), and
wonder why we get more code where less many checks are actually needed.
Both hard (the current way) and soft slice assignments are needed. I'd vote for
Ricardo's ~ suggestion.
CChris
15. Re: New slice operator
- Posted by Jeremy Cowgar <jeremy at c??gar.com>
Apr 27, 2008
-
Last edited Apr 28, 2008
CChris wrote:
>
> No, no and no!
> Do you really think a function that checks whether the next word is "while"
> should error out if the line is shorter than 5 chars? You wind up with this
> }}}
<eucode>
> function Equals(sequence s,integer i,sequence pattern)
> if i<1 or i>length(s)-length(pattern)+1 then
> return 0
> else
> return equal(s[i..i+length(pattern)-1],pattern)
> end if
> end function
> </eucode>
{{{
> Look at the amount of generated code (use Matt's ildisasm out of curiosity),
> and wonder why we get more code where less many checks are actually needed.
> Both hard (the current way) and soft slice assignments are needed. I'd vote
> for Ricardo's ~ suggestion.
>
In the new standard lib, there is head(), tail() now that do what you are
suggesting. head("next", 10) -- "next"
--
Jeremy Cowgar
http://jeremy.cowgar.com
