OpenEuphoria

Re: Re[2]: Multitask Feedback

• Posted by Al Getz <Xaxo at aol.com> Sep 24, 2005
• 432 views

D. Newhall wrote:
> 
> Al Getz wrote:
> > 
> > Hi there,
> > 
> > That's a good idea.  I can go either way with this though.  After all,
> > it doesnt take too much to ignore a return value, yet it wouldnt take
> > any new keyword to modify the language either.
> > 
> >   i=seek(fn,a) --i need the return value
> >   seek(fn,a)   --i dont need the return value
> > 
> > It's also hard to believe this would cause many problems, because
> > im wondering who could make an error like these:
> > 
> >   seek(fn,a)  --whoops!  I really needed the return value here! :)
> > 
> >   i=seek(fn,a) --Oh geeze!  I didnt really need the return value here! :)
> > 
> > Would anyone make this kind of error if it worked both ways?
> > 
> > With my C compiler (not sure if this is typical for compilers) it
> > allows you to call Win API functions as either a function when you need
> > the return value:
> >   c=SetColor(new)
> > or as a procedure when you dont:
> >   SetColor(new)
> >   
> > 
> > I think most people do something like this in Euphoria...
> > 
> >   object void --local or global
> >   void=seek(fn,a)
> >   void=SomethingElse()
> >   etc.
> > 
> > although Rob seems to prefer:
> > 
> >   if seek(fn,a) then end if
> > 
> > 
> > Take care,
> > Al
> > 
> > And, good luck with your Euphoria programming!
> > 
> > My bumper sticker: "I brake for LED's"
> > 
> 
> The "problem" with simply ignoring the return value if no variable assignment
> is before
> it is if you forget to put the assignment in when you meant to and your code
> works
> but not correctly and I think that that could be a hard bug to find.
> Especially if
> you're converting C code to Euphoria, for example, since C's open() doesn't
> return
> a value so if you forget the assignment while translating and you do a quick
> scan over
> your code and you forget to make the distinction between C and Euphoria's
> open() it
> might take you a while to figure out where the bug is. While that argument
> does seem
> a  bit forced I can see simply ignoring the return values of functions without
> an assignment
> causing a lot of problems for some programmers because it's not a very
> apparent bug
> and if you didn't define the routines you are using (ie. you're using another
> person's
> library) you might have no idea while your code isn't working.
> 
> 
> Bernie Ryan wrote:
> >
> > derek:
> >    Why not just use this; your way has the overhead of an extra call ?
> >
> >
> > object ignore
> >
> > ignore = seek(fn, 100)
> 
> You can do that too (and many times I do as well) however in most cases the
> extra procedure
> call doesn't add much and I think it's clearer because maybe the variable is
> named
> ignore for some other reason? Also, with this method (and this is simply me
> being a
> lazy programmer) I have a tendency to use the variable ignore in tests and as
> a temporary
> variable rather than redeclare it so I've beeen known to use an "ignored"
> variable
> for a good length of code :P, the procedure version makes sure I can't do
> that.
> 
> 
> The Euphoria Standard Library project :
>     <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
>     <a
>     href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
> 

Hi again Derek,

Sure, i agree that if you 'forget' to type the return variable
it can be a harder bug to track down, but this can happen anyway
if you type
  void=seek()
  ignore=seek()
  ignore(seek())
Same bug, same problem.

The reasoning here is that if you dont think you need the return value
when you really do then the language isnt going to help.  Maybe this
is why my C compiler allows it for API calls...

This style is typical:

procedure DrawThis()
  OldColor=SetColor(NewColor1) --do first color and save original color
  DoSomething()
  SetColor(NewColor2) --do second color
  DoSomething()
  SetColor(NewColor3) --do third color
  DoSomething()
  SetColor(OldColor) --restore original color
end procedure

  The idea is to save the value of OldColor until the very last call,
  where the old color is restored before exiting the function call.
  In some cases, you might have to call SetColor() 20 times without
  needing the return value simply because it isnt used until the
  end.  Without this functionality, you'd have to do this:

procedure DrawThis()
  OldColor=SetColor(NewColor1) --do first color and save original color
  DoSomething()
  void=SetColor(NewColor2) --do second color
  DoSomething()
  void=SetColor(NewColor3) --do third color
  DoSomething()
  SetColor(OldColor) --restore original color
end procedure

and here you'd have to be very careful NOT to do this:

procedure DrawThis()
  OldColor=SetColor(NewColor1) --do first color and save original color
  DoSomething()
  OldColor=SetColor(NewColor2) --do second color
  DoSomething()
  OldColor=SetColor(NewColor3) --do third color
  DoSomething()
  SetColor(OldColor) --restore original color
end procedure

because then the original color would not be restored!



So it looks to me that it's just the burden of responsibility shifts
from possibly creating an error one way, or another.

When we look at:
  seek()
we know any possible variable isnt getting updated, but when we look at:
  void=seek()
we also assume the same, and as someone said, if you arent true to
your own chosen style you may be using 'void' for some other purpose too :)



I really dont mind the way it is now though, i just use 'void' or
something like that.  I like the function call idea too though.
Hey, maybe 'void' should be declared in misc.e :) that way everyone
would be using the same var for an ignored return value.

Or this (he he)

  --file: Void.e
  global object void

You could put your procedure there too...

  global procedure ignore(object x)
  end procedure


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"