1. Idea for 'documenting' unused values
Any thoughts about this idea...?
I created an include file (ign.e) that contains ...
without warning
global procedure ignore(object x)
end procedure
with warning
then use it like this ...
include ign.e
function Foo(integer a, integer b)
ignore(a)
ignore(b)
return 0
end function
ignore(Foo(12,2))
In other words, whenever you want to tell people who read your code, that
you are deliberately ignoring a value (eg. a parameter or function return),
you just wrap it inside 'ignore()'.
I *know* it adds the overhead of a useless call, but maybe that's worth
it in the long run. It would be nice if this functionality was built-in
to the language/interpreter.
--
Derek Parnell
Melbourne, Australia
2. Re: Idea for 'documenting' unused values
Derek Parnell wrote:
>
> In other words, whenever you want to tell people who read your code, that
> you are deliberately ignoring a value (eg. a parameter or function return),
> you just wrap it inside 'ignore()'.
The "old way" is faster and just as clean (if not cleaner, just by
saving keystrokes and the overhead of one or more function calls).
VOID = Foo(12,2)
Even IGNORE = Foo(12,2) is one keystroke and two function calls
less than the proposed ignore().
Maybe you could provide a good example that would clearly show a
distinct benefit of ignore().
-=ck
"Programming in a state of EUPHORIA."
3. Re: Idea for 'documenting' unused values
cklester wrote:
>
> Derek Parnell wrote:
> >
> > In other words, whenever you want to tell people who read your code, that
> > you are deliberately ignoring a value (eg. a parameter or function return),
> > you just wrap it inside 'ignore()'.
>
> The "old way" is faster and just as clean (if not cleaner, just by
> saving keystrokes and the overhead of one or more function calls).
>
> VOID = Foo(12,2)
>
> Even IGNORE = Foo(12,2) is one keystroke and two function calls
> less than the proposed ignore().
>
> Maybe you could provide a good example that would clearly show a
> distinct benefit of ignore().
I was trying to create a single approach to handle TWO different situations.
One is when you want to ignore a function return value. And the other
is when you want to ignore passed parameters. Currently we use two or
more different ways to handle these situations.
For ignoring function returns, the common methods are ...
x = func( . . . )
where 'x' is commonly called VOID or junk or whatever...
Another method is ...
if func( .. . .) then end if
But that only works for atomic return values.
For ignoring parameters we have our good friend 'without warning'. The
problems with this is that it can accidently hide warnings we *are*
concerned about (because we forget to turn warnings back on). It also
turns off other warning messages that having nothing to do with
unused parameters -- such as unused local constants, or functions
without any return value, etc...
My approach, with ignore(), handles both situations and is very
specific about what we are doing and with what we are doing it to.
How many people have ways around all those warnings that are generated
by using Win32lib event handlers?
global procedure Click_Button(integer self, integer event, sequence parms)
Most of these handlers never use 'self' or 'event' and only sometimes
use 'parms'.
--
Derek Parnell
Melbourne, Australia
4. Re: Idea for 'documenting' unused values
> How many people have ways around all those warnings that are generated
> by using Win32lib event handlers?
>
> global procedure Click_Button(integer self, integer event, sequence
parms)
>
> Most of these handlers never use 'self' or 'event' and only sometimes
> use 'parms'.
I use VOID for this situation as well:
global procedure Click_Button(integer self, integer event,sequence parms)
VOID=self
VOID=event
5. Re: Idea for 'documenting' unused values
On Tue, 20 Jul 2004 06:25:21 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>Any thoughts about this idea...?
Probably the best solution given the tools available. I will offer
void() or used() as alternative shorter names for the procedure, not
that I'll worry if the consensus goes against me. There is one other
thing I feel the need to mention, which is object(); an utterly,
utterly useless routine which exists only for completeness, and, if
Rob felt so inclined, could do this job with no overhead whatsoever.
Of course it requires an interpreter (etc) change, so that "object(x)"
does not complain "function result must be used or assigned".
I'm not entirely sold on that, "don't "object" if (x) is unused", but
at least it offers no unnecessary pollution of the namespace...
Actually, there may also be a third use: completely unused (and
unassigned) variables. Just occasionally, I've defined the data I know
I *will* need, but am testing before it ever gets used, and I don't
actually want a dummy init, because it may block an error path. It is
pretty damn rare though, since {} or 0 would be ok 99.9% of the time.
Just so you understand: object(x) [with *zero* overhead] kills the
warning message; y=x or somesuch would crash at runtime.
Nothing you could do for that with the current tools anyway.
Can I remind you all that I did state that it is *very* rare, and no,
I don't have an example 
Bad programming practice to boot.
Aside from all that, in the long term (in posetf) I plan to use #()=,
since that marries in with multiple assignment handling, and avoids
the overhead mentioned; obviously not [yet] available in Euphoria.
Whew, so much for a quick reply while my tea brews (stews),
Pete
6. Re: Idea for 'documenting' unused values
On Tue, 20 Jul 2004 07:05:54 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>Another method is ...
>
> if func( .. . .) then end if
>
>But that only works for atomic return values.
>
<reshuffle>
>How many people have ways around all those warnings that are generated
>by using Win32lib event handlers?
I've even used "if sequence({x,y,z}) then end if" before now...
And countless instances of:
if integer(self) or integer(event) or sequence(params) then end if
vs: ignore({self,event,params})
Much better, but would prefer an inline syntax for unused params...
(Any ideas?)
>For ignoring parameters we have our good friend 'without warning'. The
>problems with this is that it can accidently hide warnings we *are*
>concerned about
Ugh, bad memories: Early experience on my first job: warnings flashing
by ten a penny; guess what, first bug I spent *ages* fixing? The
compiler had already warned me and everyone else about, zillions of
times. The dipshit I was working for, who had already spent longer
than should have been allowed looking for that bug and frankly (if he
hasn't been sacked or more likely long since retired by now) would
still be looking for to this day, ended up accusing me of breaking the
system ... because (and I think you all know what I'm about to say)
the warning messages were "wrong" when he recompiled...
<shudder>
Pete
7. Re: Idea for 'documenting' unused values
Derek's idea of an ignore() procedure is excellent in terms of being
self-documenting. If it were implemented in the interpreter, the overhead of
the procedure call could be optimized away, just as is done for then
platform() function.
-- Mike Nelson
8. Re: Idea for 'documenting' unused values
Mike Nelson wrote:
>
> Derek's idea of an ignore() procedure is excellent in terms of being
> self-documenting. If it were implemented in the interpreter, the overhead of
> the procedure call could be optimized away, just as is done for then
> platform() function.
Perhaps I misunderstand the problem, but isn't this about unused parameters
(which must nevertheless be included as placeholders) causing warnings?
If that is the case, then Euphoria should provide a dummy type to be used
as a placeholder, one which wouldn't generate the warning. Should be
easy to implement.
Irv
9. Re: Idea for 'documenting' unused values
irv mullins wrote:
>
> Mike Nelson wrote:
> >
> > Derek's idea of an ignore() procedure is excellent in terms of being
> > self-documenting. If it were implemented in the interpreter, the overhead of
> > the procedure call could be optimized away, just as is done for then
> > platform() function.
>
> Perhaps I misunderstand the problem, but isn't this about unused parameters
> (which must nevertheless be included as placeholders) causing warnings?
No. It is *also* about unused function return values, not just unused
parameters.
> If that is the case, then Euphoria should provide a dummy type to be used
> as a placeholder, one which wouldn't generate the warning. Should be
> easy to implement.
I guess you mean something like ...
procedure Click_Button(integer self, ignore, ignore)
. . .
end procedure
This is a nice idea too. We could expand it to something similar for
function returns...
void = FuncA()
--
Derek Parnell
Melbourne, Australia
10. Re: Idea for 'documenting' unused values
Derek Parnell wrote:
> irv mullins wrote:
>>
>> Mike Nelson wrote:
>>>
>>> Derek's idea of an ignore() procedure is excellent in terms of being
>>> self-documenting. If it were implemented in the interpreter, the overhead of
>>> the procedure call could be optimized away, just as is done for then
>>> platform() function.
>>
>> Perhaps I misunderstand the problem, but isn't this about unused parameters
>> (which must nevertheless be included as placeholders) causing warnings?
>
> No. It is *also* about unused function return values, not just unused
> parameters.
>
>> If that is the case, then Euphoria should provide a dummy type to be used
>> as a placeholder, one which wouldn't generate the warning. Should be
>> easy to implement.
>
> I guess you mean something like ...
>
> procedure Click_Button(integer self, ignore, ignore)
> . . .
> end procedure
>
>
> This is a nice idea too.
Agreed, very nice and straightforward. To make this even more
self-documenting, I think I would prefer something like this:
procedure Click_Button(integer self, ignore event, ignore parms)
. . .
end procedure
I believe this would also require less changes in the Euphoria parser.
> We could expand it to something similar for
> function returns...
>
> void = FuncA()
Maybe the same reserved word could be used to serve this purpose?
ignore = FuncA()
For me as a layman, it looks as if changes in the Euphoria syntax like
these are rather easy to implement. Maybe we can see them already in Eu
2.5? 
Regards,
Juergen
11. Re: Idea for 'documenting' unused values
Juergen Luethje wrote:
[snip]
> Agreed, very nice and straightforward. To make this even more
> self-documenting, I think I would prefer something like this:
>
> procedure Click_Button(integer self, ignore event, ignore parms)
> . . .
> end procedure
>
> I believe this would also require less changes in the Euphoria parser.
>
> Maybe the same reserved word could be used to serve this purpose?
>
> ignore = FuncA()
>
Juergen,
I think you have got it right. This is the best solution I've seen so far.
--
Derek Parnell
Melbourne, Australia
12. Re: Idea for 'documenting' unused values
On Sat, 24 Jul 2004 10:18:59 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>I think I would prefer something like this:
>
>procedure Click_Button(integer self, ignore event, ignore parms)
I would prefer:
procedure Click_Button(integer self, integer, sequence)
ie, if a type is followed immediately by , or ) in the parameter list
then by not specifying any name it is pretty clear you are not going
to reference the parameter.
If block comments are allowed, then
procedure Click_B(integer self, object /*event*/, object /*parms*/)
not only documents what the missing parameters are (should you feel
the need) but also by using object you avoid a tiny bit of type
checking overhead. Without block comments you could code:
procedure Click_B(integer self,
object, --event
object) --parms
Regards,
Pete
