1. deepening listed subscripting
Antonio Alessi wrote:
>
> ags wrote:
> >
> > Antonio Alessi wrote:
> > > An expression like:
> > > }}}
<eucode>
> > > newString =
> > > originalString[1..2]&"INSERT"&originalString[5..9]&originalString[27..$]
> > > </eucode>
{{{
> > > could simply become:
> > > }}}
<eucode>
> > > newString = originalString[1..2]&"INSERT"&[5..9]&[27..$]
> > > </eucode>
{{{
> > > It should be plain to implement, I mean more useful than complicated...
> >
> > I don't think that would work very well. What if you wanted to use multiple
> > strings like:
> >
> > }}}
<eucode>
> > newString = originalString[1..2] & "INSERT" & otherString[3..5] & [5..9]
> > </eucode>
{{{
> > What would the "[5..9]" refer to?
>
> Hi Gary,
>
> The last declared sequence, of course. I don't see where the problem arises.
> If I had put to you the same question, which could have been you answer?
>
> antonio
Hi again Gary,
your comment made me deepen a bit this expression,
to make it "work very well".
If we want the same rule to apply to every sequence into the same line,
this seems so not difficult: enough to delimit each with ( ), like this:
newString = originalString[1..2] &"INSERT" &(otherString[3..5] &[7..8]) &[5..9]
In such case, the "[5..9]" could clearly refer to the originalString, and so on.
_________
To this purpose we could even refine as the best syntax setting:
newString = originalString[1..2] &"INSERT" &otherString[3..5][7..8] &[5..9]
where the "&" operator becomes the variables level delimiter,
so that we could have:
a = "abcdefrghjk"
A = "ABCDEFGHJK"
n = "123456789"
newString = a[1..2] & n[5..6] & "-INSERT-" & b[3..5][7..8] & [5..9] & [3..4]
-- a:ab n:56 b:CDE + GH n:56789 a:cd
to get:
newString = "ab56-INSERT-CDEGH56789cd"
no?
antonio
2. Re: deepening listed subscripting
Antonio Alessi wrote:
>
> Antonio Alessi wrote:
> >
> > ags wrote:
> > >
> > > Antonio Alessi wrote:
> > > > An expression like:
> > > > }}}
<eucode>
> > > > newString =
> > > > originalString[1..2]&"INSERT"&originalString[5..9]&originalString[27..$]
> > > > </eucode>
{{{
> > > > could simply become:
> > > > }}}
<eucode>
> > > > newString = originalString[1..2]&"INSERT"&[5..9]&[27..$]
> > > > </eucode>
{{{
> > > > It should be plain to implement, I mean more useful than complicated...
> > >
> > > I don't think that would work very well. What if you wanted to use
> > > multiple
> > > strings like:
> > >
> > > }}}
<eucode>
> > > newString = originalString[1..2] & "INSERT" & otherString[3..5] & [5..9]
> > > </eucode>
{{{
> > > What would the "[5..9]" refer to?
> >
> > Hi Gary,
> >
> > The last declared sequence, of course. I don't see where the problem arises.
> > If I had put to you the same question, which could have been you answer?
> >
> > antonio
>
>
> Hi again Gary,
>
> your comment made me deepen a bit this expression,
> to make it "work very well".
>
> If we want the same rule to apply to every sequence into the same line,
> this seems so not difficult: enough to delimit each with ( ), like this:
> }}}
<eucode>
> newString = originalString[1..2] &"INSERT" &(otherString[3..5] &[7..8])
> &[5..9]
> </eucode>
{{{
> In such case, the "[5..9]" could clearly refer to the originalString, and so
> on.
> _________
>
> To this purpose we could even refine as the best syntax setting:
> }}}
<eucode>
> newString = originalString[1..2] &"INSERT" &otherString[3..5][7..8] &[5..9]
> </eucode>
{{{
> where the "&" operator becomes the variables level delimiter,
> so that we could have:
> }}}
<eucode>
> a = "abcdefrghjk"
> A = "ABCDEFGHJK"
> n = "123456789"
>
> newString = a[1..2] & n[5..6] & "-INSERT-" & b[3..5][7..8] & [5..9] & [3..4]
> -- a:ab n:56 b:CDE + GH n:56789 a:cd
> </eucode>
{{{
> to get:
> }}}
<eucode>
> newString = "ab56-INSERT-CDEGH56789cd"
> </eucode>
{{{
> no?
>
> antonio
That just looks so complecated, it's unreal!! I see where it's all coming from
but the logic is rediculous!
3. Re: deepening listed subscripting
It sure is! Euphoria is supposed to be simple, not a bunch of hard to remember
syntax rules.
Jeremy
4. Re: deepening listed subscripting
Alex Chamberlain wrote:
>
> > To this purpose we could even refine as the best syntax setting:
> > }}}
<eucode>
> > newString = originalString[1..2] &"INSERT" &otherString[3..5][7..8] &[5..9]
> > </eucode>
{{{
> > where the "&" operator becomes the variables level delimiter,
> > so that we could have:
> > }}}
<eucode>
> > a = "abcdefrghjk"
> > A = "ABCDEFGHJK"
> > n = "123456789"
> >
> > newString = a[1..2] & n[5..6] & "-INSERT-" & b[3..5][7..8] & [5..9] & [3..4]
> > -- a:ab n:56 b:CDE + GH n:56789 a:cd
> > </eucode>
{{{
> > to get:
> > }}}
<eucode>
> > newString = "ab56-INSERT-CDEGH56789cd"
> > </eucode>
{{{
> > no?
> >
> > antonio
>
> That just looks so complecated, it's unreal!! I see where it's all coming
> from
> but the logic is rediculous!
Thank you.
The sample above could be the expression of a limit, but could not be:
it always depends on what you have to do.
In Euphoria there are many things that looks so complicated to people, but
once you have acquired they teach you to condense your thoughts.
However "logic" is never "ridiculous", persons may be sometimes.
antonio
5. Re: deepening listed subscripting
Jeremy Peterson wrote:
>
> It sure is! Euphoria is supposed to be simple, not a bunch of hard to
> remember
> syntax rules.
>
> Jeremy
Hi Jeremy,
do you think too that
newString =
originalString[1..2]&"INSERT"&originalString[5..9]&originalString[27..$]
is more simple than:
newString = originalString[1..2]&"INSERT"&[5..9][27..$]
??
antonio
6. Re: deepening listed subscripting
- Posted by D. Newhall <derek_newhall at yahoo.com>
Apr 24, 2006
-
Last edited Apr 25, 2006
Antonio Alessi wrote:
>
> Jeremy Peterson wrote:
> >
> > It sure is! Euphoria is supposed to be simple, not a bunch of hard to
> > remember
> > syntax rules.
> >
> > Jeremy
>
> Hi Jeremy,
>
> do you think too that
>
> newString =
> originalString[1..2]&"INSERT"&originalString[5..9]&originalString[27..$]
>
> is more simple than:
>
> newString = originalString[1..2]&"INSERT"&[5..9][27..$]
>
> ??
>
> antonio
I'd say, no, it's not simpler it's just much more readable and understandable.
7. Re: deepening listed subscripting
D. Newhall wrote:
>
> Antonio Alessi wrote:
> >
> > Jeremy Peterson wrote:
> > >
> > > It sure is! Euphoria is supposed to be simple, not a bunch of hard to
> > > remember
> > > syntax rules.
> > >
> > > Jeremy
> >
> > Hi Jeremy,
> >
> > do you think too that
> >
> > newString =
> > originalString[1..2]&"INSERT"&originalString[5..9]&originalString[27..$]
> >
> > is more simple than:
> >
> > newString = originalString[1..2]&"INSERT"&[5..9][27..$]
> >
> > ??
> >
> > antonio
>
> I'd say, no, it's not simpler it's just much more readable and understandable.
Thank you, for a programmer this is the best appreciation.
We have not always to debate about words here, dealing with Language's
limitations, but contents; although I couldn't think to something that
can be more readable and understandable and is more complicated at a time.
antonio
8. Re: deepening listed subscripting
I think it's better to have it that way. That is the way I'd expect it to be.
Simple? Euphoria is supposed to be a easy language, according to Rob. Adding
stuff like this is, I think going to confuse people when they see in a line:
&[5..9][27..$] It doesn't look like regular eucode. Plus I don't think it's
needed. A change like this will save a little typing, but only if your' in the
habit of using long variable names or something. Just something to think
about...
Jeremy
9. Re: deepening listed subscripting
Jeremy Peterson wrote:
>
> I think it's better to have it that way. That is the way I'd expect it to be.
>
> Simple? Euphoria is supposed to be a easy language, according to Rob. Adding
> stuff like this is, I think going to confuse people when they see in a line:
>
> &[5..9][27..$] It doesn't look like regular eucode. Plus I don't think
> it's needed. A change like this will save a little typing, but only if your'
> in the habit of using long variable names or something. Just something to
> think
> about...
>
> Jeremy
Hello Jeremy,
if &[5..9][27..$] do confuse people, I think it's better those people don't
begin programming at all. Euphoria is much more complex than this, although
is supposed to be an easy language, or it wouldn't be so powerful.
In my opinion, easy does not mean elementary but plain and well structured,
thus allowing to perform very complex actions with ease.
Basic "was" much more simple than Euphoria, but could not reach the half
of the possible EU solutions with the same minimum amount of program lines.
However nobody is compelled to use unfamiliar formulas, even if I believe it
could deal with a typical problem of the first time:
"That is (not) the way I'd expect it to be.".
Truly this enhancement that I suggested is simpler than others in this forum
and I don't understand why so much reactions could arise for.
I could also ask what "regular eucode" means for you, but I don't.
I can just conclude quoting the Rob's answer, since this was not on Euforum:
"Thanks, I'll consider it.
I hadn't thought of that before."
antonio
10. Re: deepening listed subscripting
>From: Antonio Alessi <guest at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: deepening listed subscripting
>Date: Wed, 26 Apr 2006 12:08:48 -0700
>
>posted by: Antonio Alessi <a.admin at myway.it>
>
>Jeremy Peterson wrote:
> >
> > I think it's better to have it that way. That is the way I'd expect it
>to be.
> >
> > Simple? Euphoria is supposed to be a easy language, according to Rob.
>Adding
> > stuff like this is, I think going to confuse people when they see in a
>line:
> >
> > &[5..9][27..$] It doesn't look like regular eucode. Plus I don't think
> > it's needed. A change like this will save a little typing, but only if
>your'
> > in the habit of using long variable names or something. Just something
>to think
> > about...
> >
> > Jeremy
>
>
>Hello Jeremy,
>
>if &[5..9][27..$] do confuse people, I think it's better those people don't
>begin programming at all. Euphoria is much more complex than this, although
>is supposed to be an easy language, or it wouldn't be so powerful.
>
Ah, but it seems you can still be confused. You see, s[5..9][27..$]
currently means nothing. But what if, for example, we had s = {{1, 2, 3, 4,
5}, {6, 7, 8, 9, 10}, {11, 12, 13, 14, 15}, {16, 17, 18, 19, 20}, {21, 22,
23, 24, 25}}, then with your shortcut [2][4..5] would be {6, 7, 8, 9, 10,
{16, 17, 18, 19, 20}, {21, 22, 23, 24, 25}} but if you used regular old
eucode, s[2][4..5] is {9, 10}. Now, you may have very well known that when
you wrote x = s[1] & '3' & [2][4..5] that you wanted x = {1, 2, 3, 4, 5,
'3', 6, 7, 8, 9, 10, {16, 17, 18, 19, 20}, {21, 22, 23, 24, 25}}. But if
someone else is reading that, and all they heard about was the meaning of
s[2][4..5] that we currently have (which is not all too common with arrays),
what would they think the result would be? I would expect x = {1, 2, 3, 4,
5, '3', 9, 10} as a best guess.
Certain shortcuts like $ instead of length(var) or &= made sense.... Some
just make things more confusing. Dangling subscripts are not a good thing.
As someone else mentioned, what happens when there is more than one
sequence? What if the second variable is an atom; should you ignore it? What
if you later change it to a object; would that cause an error? What if it
didn't cause an error, and you accidently had a sequence in that variable;
how hard would it be to find that bug? What if I put parentheses around
things; which comes first? Can I do something like x = s[2] * [4] and expect
it to make sense? Certainly it looks somewhat odd to be doing func(x[2],
[5][3], [6]), doesn't it...
>In my opinion, easy does not mean elementary but plain and well structured,
>thus allowing to perform very complex actions with ease.
>Basic "was" much more simple than Euphoria, but could not reach the half
>of the possible EU solutions with the same minimum amount of program lines.
>
>However nobody is compelled to use unfamiliar formulas, even if I believe
>it
>could deal with a typical problem of the first time:
> "That is (not) the way I'd expect it to be.".
>Truly this enhancement that I suggested is simpler than others in this
>forum
>and I don't understand why so much reactions could arise for.
>
>I could also ask what "regular eucode" means for you, but I don't.
>I can just conclude quoting the Rob's answer, since this was not on
>Euforum:
>
>"Thanks, I'll consider it.
>I hadn't thought of that before."
>
>
>antonio
>
~[ WingZone ]~
http://wingzone.tripod.com/
11. Re: deepening listed subscripting
Elliott S. de Andrade wrote:
>
> Ah, but it seems you can still be confused. You see, s[5..9][27..$]
> currently means nothing. But what if, for example, we had s = {{1, 2, 3, 4,
>
> 5}, {6, 7, 8, 9, 10}, {11, 12, 13, 14, 15}, {16, 17, 18, 19, 20}, {21, 22,
> 23, 24, 25}}, then with your shortcut [2][4..5] would be {6, 7, 8, 9, 10,
> {16, 17, 18, 19, 20}, {21, 22, 23, 24, 25}} but if you used regular old
> eucode, s[2][4..5] is {9, 10}.
Yes, right.
My first suggestion to Rob was s[5..9] &[27..$] where this problem does not
exist; then a first answer to the Gary's question:
>newString = originalString[1..2] & "INSERT" & otherString[3..5] & [5..9]
> What would the "[5..9]" refer to?
brought to:
newString = originalString[1..2] &"INSERT"
&(otherString[3..5] &[7..8]) &[5..9]
and so forth to the polemic, that is not the ground to build any language.
> Certain shortcuts like $ instead of length(var) or &= made sense....
This one [..length( of)] was a request of mine too.
I'm still not confused.
antonio
12. Re: deepening listed subscripting
Elliott S. de Andrade wrote:
>
> Ah, but it seems you can still be confused. You see, s[5..9][27..$]
> currently means nothing. But what if, for example, we had s = {{1, 2, 3, 4,
>
> 5}, {6, 7, 8, 9, 10}, {11, 12, 13, 14, 15}, {16, 17, 18, 19, 20}, {21, 22,
> 23, 24, 25}}, then with your shortcut [2][4..5] would be {6, 7, 8, 9, 10,
> {16, 17, 18, 19, 20}, {21, 22, 23, 24, 25}} but if you used regular old
> eucode, s[2][4..5] is {9, 10}.
Just one correction, since the confusion looks to be contagious.
In fact it seems you are, since s[2][4..5], that I have never mentioned,
is not the same of s[1..2][4..5] that was the object of my example.
Then with my shortcut s[2][4..5] would always and obviously be {9, 10},
while s[1..2][4..5], or s[1..2]&[4..5], could only be
{{1, 2, 3, 4, 5}, {6, 7, 8, 9, 10}, {16, 17, 18, 19, 20}, {21, 22, 23, 24, 25}}
Beyond any personal preference, the difference between s[1..2] and s[1][2]
should clear for everyone.
isn't it?
antonio
13. Re: deepening listed subscripting
Antonio Alessi wrote:
>
(snip stuff from Elliott)
>
> Just one correction, since the confusion looks to be contagious.
>
(snip)
There's the biggest fault with your proposal. If experienced Euphoria programers
are confused about how this would work how would newcomers understand this?
Syntactic simplicity shouldn't take precedence over ease of comprehension.
14. Re: deepening listed subscripting
D. Newhall wrote:
>
> Antonio Alessi wrote:
> >
> (snip stuff from Elliott)
> >
> > Just one correction, since the confusion looks to be contagious.
> >
> (snip)
>
> There's the biggest fault with your proposal. If experienced Euphoria
> programers
> are confused about how this would work how would newcomers understand this?
> Syntactic simplicity shouldn't take precedence over ease of comprehension.
I agree. It's just too confusing. Added to that, I see no real need for a
change like this. How will it make using Eu easier, or faster, or better?
Jeremy
15. Re: deepening listed subscripting
There have been many other things that lots of people wanted added to Euphoria,
like Select case, continue in for loops, and whatnot, but Rob never added them.
I doubt he would add something like this with no apparent value. Maybe that's
why people are so hostile to this, their good suggestions have been turned down
so they are protesting a not-so-good suggestion.
Jeremy
16. Re: deepening listed subscripting
- Posted by ags <eu at 531pi.co.nz>
Apr 28, 2006
Jeremy Peterson wrote:
>
> There have been many other things that lots of people wanted added to
> Euphoria,
> like Select case, continue in for loops, and whatnot, but Rob never added
> them.
> I doubt he would add something like this with no apparent value. Maybe
> that's
> why people are so hostile to this, their good suggestions have been turned
> down
> so they are protesting a not-so-good suggestion.
I think it comes down to (in rough order of importance):
- how easy it would be for Rob to incorporate this into the language
- whether it breaks any existing code
- whether it majorly impacts performance
- how well it can be documented so that there is no confusion
- how useful it is (I don't think this can be first in the list as it is a
subjective opinion).
The first point addresses your post. If it is not extraordinarily complex to
implement in the language or there is no considerable performance impact to doing
it, and it satisfies the above criteria then I am not opposed to it.
I would love to see a 'continue' or 'next' in for loops (I wanted this yesterday
for processing command line options) but if it is too difficult to implement or
hampers performance then I can understand why it is not there.
Another thing to look at is whether it can be implemented in a function and
whether that is OK performance-wise. For listed subscripts, I can imagine it
would be relatively easy to come up with a subscripts(...) function, but would
that be satisfying?
Gary
17. Re: deepening listed subscripting
Jeremy Peterson wrote:
>
> D. Newhall wrote:
> >
> > Antonio Alessi wrote:
> > >
> > (snip stuff from Elliott)
> > >
> > > Just one correction, since the confusion looks to be contagious.
> > >
> > (snip)
> >
> > There's the biggest fault with your proposal. If experienced Euphoria
> > programers
> > are confused about how this would work how would newcomers understand this?
> > Syntactic simplicity shouldn't take precedence over ease of comprehension.
>
> I agree. It's just too confusing. Added to that, I see no real need for a
> change like this. How will it make using Eu easier, or faster, or better?
>
> Jeremy
It will on all three counts, perhaps after some adjustments.
If what you type is closer to how you represent what you want to achieve,
then the language is easier to use. That's how I would define "easier" in
this context.
In the case at hand, you want to extract some pieces of a string to build
up another one. For this purpose, myString[7,2..5,1] is certainly easier
than myString[7]&myString[2..5]&myString[1].
At the same time, it will save typing and probably avoid some silly bugs.
These take longer than any loss of performance you can think of because of
the new syntax - I doubt there's any. So yes, it will make Euphoria faster.
Being spared repetition of meaningful, hence longer variable names makes the
language better indeed because the penalty for a programmer to use easy to
understand names will be alleviated a bit, and because of the clearer code.
To avoid confision, I had been suggesting to keep repeated indices to denote
different subscripting levels, hence the idea of putting a list of indices
and slices inside the same pair of brackets.
Of a more general usefulness would be to have a special symbol stand for the
left hand side of an assignment. '_' looks like a good cancicate to me.
So, to retain only a few characters of a string, you'd code:
some_lengthy_name[with_indexes][and_more]=_[7,2..5,1]
Rewrite this using the current state of the language, and you'll be convinced
I think. This feature is easy to implement in the source, and has a wider
range of uses (how many times did you write: something=append(something,else)?
Yet another pita, only second to the namespace system needing rethinking.
By the way, Rob: you say that you don't want to open that can because
"few people use it anyway". Perhaps "few people use it" because of these
problems that have been precisely discussed at length here.
CChris
18. Re: deepening listed subscripting
CChris wrote:
>
> Jeremy Peterson wrote:
> >
> > D. Newhall wrote:
> > >
> > > Antonio Alessi wrote:
> > > >
> > > (snip stuff from Elliott)
> > > >
> > > > Just one correction, since the confusion looks to be contagious.
> > > >
> > > (snip)
> > >
> > > There's the biggest fault with your proposal. If experienced Euphoria
> > > programers
> > > are confused about how this would work how would newcomers understand
> > > this?
> > > Syntactic simplicity shouldn't take precedence over ease of comprehension.
> >
> > I agree. It's just too confusing. Added to that, I see no real need for a
> > change like this. How will it make using Eu easier, or faster, or better?
> >
> > Jeremy
>
> It will on all three counts, perhaps after some adjustments.
>
> If what you type is closer to how you represent what you want to achieve,
> then the language is easier to use. That's how I would define "easier" in
> this context.
> In the case at hand, you want to extract some pieces of a string to build
> up another one. For this purpose, myString[7,2..5,1] is certainly easier
> than myString[7]&myString[2..5]&myString[1].
>
> At the same time, it will save typing and probably avoid some silly bugs.
> These take longer than any loss of performance you can think of because of
> the new syntax - I doubt there's any. So yes, it will make Euphoria faster.
>
> Being spared repetition of meaningful, hence longer variable names makes the
> language better indeed because the penalty for a programmer to use easy to
> understand names will be alleviated a bit, and because of the clearer code.
>
> To avoid confision, I had been suggesting to keep repeated indices to denote
>
> different subscripting levels, hence the idea of putting a list of indices
> and slices inside the same pair of brackets.
> Of a more general usefulness would be to have a special symbol stand for the
>
> left hand side of an assignment. '_' looks like a good cancicate to me.
> So, to retain only a few characters of a string, you'd code:
>
> some_lengthy_name[with_indexes][and_more]=_[7,2..5,1]
>
> Rewrite this using the current state of the language, and you'll be convinced
>
> I think. This feature is easy to implement in the source, and has a wider
> range of uses (how many times did you write: something=append(something,else)?
> Yet another pita, only second to the namespace system needing rethinking.
>
> By the way, Rob: you say that you don't want to open that can because
> "few people use it anyway". Perhaps "few people use it" because of these
> problems that have been precisely discussed at length here.
>
> CChris
Ok Chris,
one more example can help to focus the convenience.
I don't want to convince anybody, just to point out;
so please look at this.
Let's need to store the position and size of a window; so we type:
WindowBox = getWindowRect( wndw)
to obtain the 4 coordinates: left, top, right, bottom;
hence we have the choice to think and visualize the next step as:
WindowBox[3] = WindowBox[3] -WindowBox[1]
WindowBox[4] = WindowBox[4] -WindowBox[2]
or, to the "opposite", as:
WindowBox[3..4]-= WindowBox[1..2]
but would you use such a program line? it is very "strange" looking;
not easy to read (at first) and not immediate to our eyes and mental.
All the criticism emerged toward the s[5..9][27..$] could be
emphasized here.
However it is undoubtedly the best one in the programming perspective,
thanks to Euyphoria. Yet we know how much the legibility of a program
comes to be strongly conditioned by the available space on the display.
Despite to all that, in most program we will probably find:
WindowBox[3]-= WindowBox[1]
WindowBox[4]-= WindowBox[2]
that seems to be the easiest compromise to acquire; but thit could
tell us that the language's capability is not wholly exploited so far.
Is it our question then:
« what should we expect from Euphoria »
or
« what should we expect from the Euphorians »?
that's to say:
should a program language be adapted to the programmers' mind
or
should the programmers choose a programming language for its quality
and then get the most from?
Rob, it deals only with discovering which of the two
will be capable to change the other in the time.
Regards,
antonio alessi
