1. Warning error
Hello everybody,
I think I found something like an error.
sequence pastaTops pastaTops={}
That's it I don't use or referrer to pastaTops again in any of my code.
But I do not get, "Warning the sequence pastaTops is not used".
Don Cole
2. Re: Warning error
don cole wrote:
>
> Hello everybody,
>
> I think I found something like an error.
>
> }}}
<eucode>
>
> sequence pastaTops pastaTops={}
>
> </eucode>
{{{
>
> That's it I don't use or referrer to pastaTops again in any of my code.
>
> But I do not get, "Warning the sequence pastaTops is not used".
>
>
> Don Cole
Don:
You did use it when you did this:
pastaTops={}
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
3. Re: Warning error
don cole wrote:
> Hello everybody,
>
> I think I found something like an error.
>
> }}}
<eucode>
>
> sequence pastaTops pastaTops={}
>
> </eucode>
{{{
>
> That's it I don't use or referrer to pastaTops again in any of my code.
>
> But I do not get, "Warning the sequence pastaTops is not used".
I think Euphoria used to catch that, but over the years
people complained about spurious warnings, e.g. they
might have:
ignore = graphics_mode(18) -- if it fails, so what?
or
ignore = getc(0) -- wait for key press
to discard the result returned by a function, but then they'd
be warned about "ignore" not being used.
Perhaps we can re-instate this warning in some cases.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Warning error
don cole wrote:
> }}}
<eucode>
> sequence pastaTops pastaTops={}
> </eucode>
{{{
> I do not get, "Warning the sequence pastaTops is not used".
Yes, that once struck me too. Strictly speaking, you are correct in the sense
that it is not "used", but I think that particular warning applies much more to
routine parameters, where you wouldn't expect explicit assignment.
However, there is a HUGE bulk of legacy code which does exactly this (eg VOID in
win32lib) and you could even end up with eg (untested):
function pwr(atom base, integer raise)
-- returns base^^raise, eg pwr(5,3)=125
atom pwr
pwr=1
for i=1 to raise do
pwr*=base
end for
return pwr
end function
Technically, the i in "for i" is "not used". OK, now I've typed it (;-((), I
guess it is "used" by the end for, but you ought to get the point that strict
enforcement would likely trigger far more scares than help any. Sorry for the
duff example, trying too hard to be different from win32lib's "VOID" I guess.
Bad example aside, I guess if we ever get (agreement on) an elegant method to
ignore return values then this will suddenly become much more pertinent.
Regards,
Pete
PS I vote for {}=xxx(), btw, very Eu-like, as I read it as "nothing becomes
equal to the result of xxx()" or I suppose if you prefer, "store the result of
xxx() in nothing/nowhere". Whereas I never really liked the ~xxx() idea.
Plus it ties up nicely with my plans for multiple assignment, and also I always
found "{}=" dead easy to type, actually easier/faster than "~" even thought it is
three keys(I regularly use) not one(I rarely use).
5. Re: Warning error
Pete Lomax wrote:
> }}}
<eucode>
> function pwr(atom base, integer raise)
> -- returns base^^raise, eg pwr(5,3)=125
> atom pwr
> pwr=1
> for i=1 to raise do
> pwr*=base
> end for
> return pwr
> end function
> </eucode>
{{{
Sometime I code,
sequence pastaqTops
pastaTops={}
Now late at night laying bed, I decide
sequence spagettiStraps
spagettiStraps={}
--tons more code
By now I forgot all about all those (unused)pastaTops.
True the i is not used but it's not declared either. Raise however is
declared and used.
Don Cole
6. Re: Warning error
Pete Lomax wrote:
<snip>
> Regards,
> Pete
> PS I vote for {}=xxx(), btw, very Eu-like, as I read it as "nothing becomes
> equal to the result of xxx()" or I suppose if you prefer, "store the result
> of xxx() in nothing/nowhere". Whereas I never really liked the ~xxx() idea.
> Plus it ties up nicely with my plans for multiple assignment, and also I
> always
> found "{}=" dead easy to type, actually easier/faster than "~" even thought
> it is three keys(I regularly use) not one(I rarely use).
Hi Pete,
Multiple assignment would be terrific but please don't use braces for this.
I much prefer parentheses; e.g.
{a, b, c) = somefunc()
-- Using braces makes it look like sequence formation, which it is not:
{d,e,f} = another_func()
Also, (I may be nit-picking here) when you say "nothing becomes equal to..."
as in "{}=xxx()", the empty braces have a very specific meaning, that is,
"the empty sequence", not "nothing". At least, I find it jarring to look at.
Unless, of course, I've misunderstood your intention. ;)
BTW, I take it you are familiar with Daryl Border's implementation of
multiple assignment called "seqparse" from 2005.
Thanks,
Bob
7. Re: Warning error
Bob Elia wrote:
>
> Pete Lomax wrote:
>
> <snip>
>
> > Regards,
> > Pete
> > PS I vote for {}=xxx(), btw, very Eu-like, as I read it as "nothing becomes
> > equal to the result of xxx()" or I suppose if you prefer, "store the result
> > of xxx() in nothing/nowhere". Whereas I never really liked the ~xxx() idea.
> > Plus it ties up nicely with my plans for multiple assignment, and also I
> > always
> > found "{}=" dead easy to type, actually easier/faster than "~" even thought
> > it is three keys(I regularly use) not one(I rarely use).
>
> Hi Pete,
>
> Multiple assignment would be terrific but please don't use braces for this.
>
> I much prefer parentheses; e.g.
>
> }}}
<eucode>
> {a, b, c) = somefunc()
>
> -- Using braces makes it look like sequence formation, which it is not:
>
> {d,e,f} = another_func()
> </eucode>
{{{
>
> Also, (I may be nit-picking here) when you say "nothing becomes equal to..."
> as in "{}=xxx()", the empty braces have a very specific meaning, that is,
> "the empty sequence", not "nothing". At least, I find it jarring to look at.
>
> Unless, of course, I've misunderstood your intention. ;)
>
> BTW, I take it you are familiar with Daryl Border's implementation of
> multiple assignment called "seqparse" from 2005.
>
> Thanks,
> Bob
Please don't use parentheses or square brackets. Look at the following code:
x=f
(d,e,c)=something()
The interpreter will be confused because f is not supposed to have any
arguments, yet the code reads:
x=f(d,e,c)=something()
Even more irritating, the latter does have a meaning in Eu already, which is
not the one that was intended.
As you can see, replacing parens by square brackets doesn't help, because,
when the comma appears, the interpreter is already subscripting f.
This leaves us with:
* {...}, my preference,
* |...| : pipes are not often easy to tell from square brackets, and, on non
english keyboards, | and [ are on adjacent keys, calling for more typos.
* <...> : will confuse the interpreter. Remember that it is very myopic, and
has to know at each character how it is going to read that character. It
exceptionally looks ahead one char forth so as to read the slice symbol
or relational operators, but that's nearly all.
* perhaps <<...>> would be acceptable.
* perhaps ;...; would be acceptable.
So my vote is for curly braces.
{}=func() doesn't shock me at all. It is an empty sequence of placeholders.
So, no assignment is to take place, since there is no target for assignment.
In my private idEu preprocessor, I use a single _ as placeholder in various
contexts. For instance, I write
a[b[c]][d]=append(_,something)
where _ resolves to the left hand side.
And
{a,_,c}=f
if I wish to ignore the second element in the right hand side. I had coded
the beast so that {}, {_} or _ on the left would all cause no assignment
to take place.
Any thoughts?
CChris
8. Re: Warning error
- Posted by Bob Elia <bobelia200 at netzero.net>
Feb 27, 2007
-
Last edited Feb 28, 2007
CChris wrote:
>
> Bob Elia wrote:
> >
> > Pete Lomax wrote:
> >
> > <snip>
> >
> > > Regards,
> > > Pete
> > > PS I vote for {}=xxx(), btw, very Eu-like, as I read it as "nothing
> > > becomes
> > > equal to the result of xxx()" or I suppose if you prefer, "store the
> > > result
> > > of xxx() in nothing/nowhere". Whereas I never really liked the ~xxx()
> > > idea.
> > > Plus it ties up nicely with my plans for multiple assignment, and also I
> > > always
> > > found "{}=" dead easy to type, actually easier/faster than "~" even
> > > thought
> > > it is three keys(I regularly use) not one(I rarely use).
> >
> > Hi Pete,
> >
> > Multiple assignment would be terrific but please don't use braces for this.
> >
> > I much prefer parentheses; e.g.
> >
> > }}}
<eucode>
> > {a, b, c) = somefunc()
> >
> > -- Using braces makes it look like sequence formation, which it is not:
> >
> > {d,e,f} = another_func()
> > </eucode>
{{{
> >
> > Also, (I may be nit-picking here) when you say "nothing becomes equal to..."
> > as in "{}=xxx()", the empty braces have a very specific meaning, that is,
> > "the empty sequence", not "nothing". At least, I find it jarring to look
> > at.
> >
> > Unless, of course, I've misunderstood your intention. ;)
> >
> > BTW, I take it you are familiar with Daryl Border's implementation of
> > multiple assignment called "seqparse" from 2005.
> >
> > Thanks,
> > Bob
>
> Please don't use parentheses or square brackets. Look at the following code:
> }}}
<eucode>
> x=f
> (d,e,c)=something()
> </eucode>
{{{
> The interpreter will be confused because f is not supposed to have any
> arguments, yet the code reads:
> }}}
<eucode>
> x=f(d,e,c)=something()
> </eucode>
{{{
> Even more irritating, the latter does have a meaning in Eu already, which is
>
> not the one that was intended.
Yes, of course. That slipped by me completely.
>
> As you can see, replacing parens by square brackets doesn't help, because,
> when the comma appears, the interpreter is already subscripting f.
>
> This leaves us with:
> * {...}, my preference,
> * |...| : pipes are not often easy to tell from square brackets, and, on non
> english keyboards, | and [ are on adjacent keys, calling for more typos.
> * <...> : will confuse the interpreter. Remember that it is very myopic, and
> has to know at each character how it is going to read that character. It
> exceptionally looks ahead one char forth so as to read the slice symbol
> or relational operators, but that's nearly all.
> * perhaps <<...>> would be acceptable.
> * perhaps ;...; would be acceptable.
>
> So my vote is for curly braces.
>
> {}=func() doesn't shock me at all. It is an empty sequence of placeholders.
> So, no assignment is to take place, since there is no target for assignment.
>
If {} is okay, then I'd rather not introduce new syntax elements. They might
be needed in the future for something else. Agreed?
> In my private idEu preprocessor, I use a single _ as placeholder in various
> contexts. For instance, I write
> }}}
<eucode>
> a[b[c]][d]=append(_,something)
> </eucode>
{{{
> where _ resolves to the left hand side.
> And
> }}}
<eucode>
> {a,_,c}=f
> </eucode>
{{{
> if I wish to ignore the second element in the right hand side. I had coded
>
> the beast so that {}, {_} or _ on the left would all cause no assignment
> to take place.
>
>
> Any thoughts?
>
> CChris
Thanks, Bob
