I find it mildly distracting that I can't do this:

void xyz() { ... }

void abc()
{
     if (...)
        return xyz();
     else blah blah blah;
}

I can do it if xyz and abc return values, but not if they don't. I have to 
instead
      if (...)
      {
         xyz();
         return;
      }

which significantly expands a function that has lots of such dispatches. It 
also makes it unclear to the casual reader that this is a tail call.


Also, I realized I tend to have larger functions than necessary because most 
languages I'm using don't let me nest functions.  For example, I have an 
output list, two error bars, and a point. I want to add the point (or a few) 
to the list if it's within the two error bars.  I do this several times.

In Pascal or Ada or something, I could do something ilke
     MaybeAddPoint(x, y);
as the call, and MaybeAddPoint being nested would let it access the other 
locals. But in C or C# or Java, I have to do
     MaybeAddPoint(x, y, errlo, errhi, output);
where errlo, errhi, and output are the same value for every call of the 
function.  Hence, when it's only two or three calls, with lots of those 
kinds of constant-for-all-calls arguments, I find I sometimes wind up 
inlining the stuff, because that's just as clear as passing half a dozen 
"parameters" that aren't really parameters at all, but rather the 
environment they're working in.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 02/05/2011 18:26, Darren New wrote:
> I find it mildly distracting that I can't do this:
>
> void xyz() { ... }
>
> void abc()
> {
> if (...)
> return xyz();
> else blah blah blah;
> }
>
> I can do it if xyz and abc return values, but not if they don't. I have
> to instead
> if (...)
> {
> xyz();
> return;
> }
>
> which significantly expands a function that has lots of such dispatches.
> It also makes it unclear to the casual reader that this is a tail call.

How about just

   if (...)
   {xyz(); return;}
   else...

That's slightly less load.

Of course, The Real WTF is "functions" that return void. ;-)

> Also, I realized I tend to have larger functions than necessary because
> most languages I'm using don't let me nest functions.

No comment. ;-)

Post a reply to this message

On 5/3/2011 1:43, Invisible wrote:
> That's slightly less load.

Still ugly, and non-standard formatting. :-)

> Of course, The Real WTF is "functions" that return void. ;-)

Like functions that return unit are better?

>> Also, I realized I tend to have larger functions than necessary because
>> most languages I'm using don't let me nest functions.
>
> No comment. ;-)

I realize that this is the primary semantic difference between "Algol-like 
languages" and "C-like languages", with the use of punctuation instead of 
keywords being the syntactic primary difference.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 03/05/2011 16:40, Darren New wrote:
> On 5/3/2011 1:43, Invisible wrote:
>> That's slightly less load.
>
> Still ugly, and non-standard formatting. :-)

Yeah. It's about the best you can do though.

>> Of course, The Real WTF is "functions" that return void. ;-)
>
> Like functions that return unit are better?

How many of those can you name?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I find it mildly distracting that I can't do this:

> void xyz() { ... }

> void abc()
> {
>      if (...)
>         return xyz();
>      else blah blah blah;
> }

  What's wrong with:

void abc()
{
     if (...)
        xyz();
     else blah blah blah;
}

  (Structured programming purists would recommend doing it like that
because there's no early return.)

-- 
                                                          - Warp

Post a reply to this message

On 5/3/2011 8:43, Invisible wrote:
>>> Of course, The Real WTF is "functions" that return void. ;-)
>>
>> Like functions that return unit are better?
>
> How many of those can you name?

Not many, but then I work in languages where functions can return void. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 5/3/2011 8:50, Warp wrote:
>    What's wrong with:

The "else" doesn't end the function, and I tend to have several of these in 
a row, and sometimes it's inside a loop, etc.

>    (Structured programming purists would recommend doing it like that
> because there's no early return.)

I could restructure things, sure, but then it's even more verbose and unlike 
my initial thought processes.  Structured programming wouldn't let me return 
a value from the middle of the function either.  It's the asymmetry between 
a return after a void call and a return after a value-producing call that is 
ugly.


(I had to giggle yesterday when I added an "else break" as the last 
statement of a do-while loop, too.)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 5/3/2011 8:43, Invisible wrote:
> >>> Of course, The Real WTF is "functions" that return void. ;-)
> >>
> >> Like functions that return unit are better?
> >
> > How many of those can you name?

> Not many, but then I work in languages where functions can return void. ;-)

  Well, if we go to the strict definition of "function", that's not the
only problem. For one, strict functions must always return the same value
for the same parameters and must not have side-effects. (Hence eg. rand()
is not a true function.)

-- 
                                                          - Warp

Post a reply to this message

On 5/3/2011 11:36, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> On 5/3/2011 8:43, Invisible wrote:
>>>>> Of course, The Real WTF is "functions" that return void. ;-)
>>>>
>>>> Like functions that return unit are better?
>>>
>>> How many of those can you name?
>
>> Not many, but then I work in languages where functions can return void. ;-)
>
>    Well, if we go to the strict definition of "function",

That too. And I would wonder how realistic it is to have a strict function 
returning a "value" that the type system prevents you from ever seeing. 
(I.e., the stuff you use to order calculations in a pure language like Haskell.)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 03/05/2011 08:02 PM, Darren New wrote:

> That too. And I would wonder how realistic it is to have a strict
> function returning a "value" that the type system prevents you from ever
> seeing. (I.e., the stuff you use to order calculations in a pure
> language like Haskell.)

I'm not sure what you're talking about.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message