Walter Bright wrote:

>> OK, so there might be a "import std.c.stdio;" to
>> insert in a couple of files to make them compile ?
> 
> I mean the parrot moved <g>.

No, it didn't, that was you hitting the cage! ;-)

Too bad.
--anders

Walter Bright wrote:
> Anders F Björklund wrote:
>> Walter Bright wrote:
>>
>>> It just moved.
>>
>> OK, so there might be a "import std.c.stdio;" to
>> insert in a couple of files to make them compile ?
> 
> I mean the parrot moved <g>.

what parrot?

Hasan Aljudy wrote:
> 
> 
> Walter Bright wrote:
>> Anders F Björklund wrote:
>>> Walter Bright wrote:
>>>
>>>> It just moved.
>>>
>>> OK, so there might be a "import std.c.stdio;" to
>>> insert in a couple of files to make them compile ?
>>
>> I mean the parrot moved <g>.
> 
> what parrot?

This parrot:

http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm

IMO, it's right up there with "Who's on First", although Palin and Cleese's delivery on the small screen is far more hilarious than what you'll see on the page.


And now for something completely different.

-- 
- EricAnderton at yahoo

Pragma wrote:

> This parrot:
> 
> http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm

See also:
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/5838.html

> And now for something completely different.

Indeed. Those sketches are for another programming language. :-)

--anders

Walter Bright wrote:

> I tried this back in the '80s. It's one of those things that sure sounds like a good idea. The problem is, there are just too many cases where the return value is legitimately ignored (like printf's), so you wind up filling your code with chaff like:
> 
> 	cast(void) printf( ... );
> 
> After a few dozen of those, it starts looking like a bad idea <g>.

Well, it depends on a particular syntax. In Nemerle for example it's just

" _ = SomeFunc();"

-- 
AKhropov

Andrei Khropov wrote:
> Walter Bright wrote:
> 
>> I tried this back in the '80s. It's one of those things that sure sounds like
>> a good idea. The problem is, there are just too many cases where the return
>> value is legitimately ignored (like printf's), so you wind up filling your
>> code with chaff like:
>>
>> 	cast(void) printf( ... );
>>
>> After a few dozen of those, it starts looking like a bad idea <g>.
> 
> Well, it depends on a particular syntax. In Nemerle for example it's just 
> 
> " _ = SomeFunc();"
> 

That's true! How about: "void = printf()", similar to the void initializer "int[] x = void;"

L.

On Thu, 05 Oct 2006 12:26:11 +0300, Lionello Lunesu <lio@lunesu.remove.com> wrote:

> Andrei Khropov wrote:
>> Walter Bright wrote:
>>
>>> I tried this back in the '80s. It's one of those things that sure sounds like
>>> a good idea. The problem is, there are just too many cases where the return
>>> value is legitimately ignored (like printf's), so you wind up filling your
>>> code with chaff like:
>>>
>>> 	cast(void) printf( ... );
>>>
>>> After a few dozen of those, it starts looking like a bad idea <g>.
>>  Well, it depends on a particular syntax. In Nemerle for example it's just  " _ = SomeFunc();"
>>
>
> That's true! How about: "void = printf()", similar to the void initializer "int[] x = void;"
>
> L.

Well, I ignore return values of functions a lot.

For example, 'eraseFile()' returns true if a file was deleted or false on failure. Usually I don't care what the return value is: if the file couldn't be deleted, too bad, there is not much that I can do about it (except possibly notify the user by opening a message box, but that's not always wanted).

The return value of such functions is a 'side effect', not the main thing. Lets say that these functions belong to a group A. There are also functions whose 'main thing' is their return value. There may or may not be some 'side effects' when they are called. These functions belong to a group B.

Clearly you wouldn't want to do any extra work when calling functions of the group A. Or have warning/error messages with them. However, with the group B that would be ok.

One solution could be to tell the compiler that a function belongs to the group B. For example:

pure double sqrt(double val);

void func() {
    double x;

    sqrt(2.0);      //error
    x = sqrt(2.0);  //ok
}

Notice a new keyword 'pure'.

Kristian wrote:
> On Thu, 05 Oct 2006 12:26:11 +0300, Lionello Lunesu <lio@lunesu.remove.com> wrote:
> 
>> Andrei Khropov wrote:
>>> Walter Bright wrote:
>>>
>>>> I tried this back in the '80s. It's one of those things that sure sounds like
>>>> a good idea. The problem is, there are just too many cases where the return
>>>> value is legitimately ignored (like printf's), so you wind up filling your
>>>> code with chaff like:
>>>>
>>>>     cast(void) printf( ... );
>>>>
>>>> After a few dozen of those, it starts looking like a bad idea <g>.
>>>  Well, it depends on a particular syntax. In Nemerle for example it's just  " _ = SomeFunc();"
>>>
>>
>> That's true! How about: "void = printf()", similar to the void initializer "int[] x = void;"
>>
>> L.
> 
> Well, I ignore return values of functions a lot.
> 
> For example, 'eraseFile()' returns true if a file was deleted or false on failure. Usually I don't care what the return value is: if the file couldn't be deleted, too bad, there is not much that I can do about it (except possibly notify the user by opening a message box, but that's not always wanted).

If you don't care whether the file got deleted, why do you delete it in the first place? OK, I know very well what you're trying to say and I do it myself all the time, but I'll also admit that it's sloppy programming.

Furthermore, 'the D way' is to throw an exception, not to return some value that is or is not tested.

By the way, do you often use

try { /* some code*/ } catch (Object o) {/* no code*/}

too? They should, since the same reasoning applies to function throwing an exception.


> The return value of such functions is a 'side effect', not the main thing. Lets say that these functions belong to a group A. There are also functions whose 'main thing' is their return value. There may or may not be some 'side effects' when they are called. These functions belong to a group B.

eraseFile returning 'false' is not a side-effect, it is the main thing not being done. A side effect would be printf returning the number of characters written.

> Clearly you wouldn't want to do any extra work when calling functions of the group A. Or have warning/error messages with them. However, with the group B that would be ok.

Granted, so perhaps it could be a warning message after all. Definately not an error, we've established that.

> One solution could be to tell the compiler that a function belongs to the group B. For example:
> 
> pure double sqrt(double val);
> 
> void func() {
>     double x;
> 
>     sqrt(2.0);      //error
>     x = sqrt(2.0);  //ok
> }
> 
> Notice a new keyword 'pure'.

I like that. It's actually enabling that specific warning/error message on a per function basis. Functions returning handles to resources or fatal return values (mostly C libraries probably) could be tagged with this identifier and the compiler will then make sure the return value is actually used...

This is like a contract, in a way, for the caller of the function (as opposed to contact for the implementor.)

L.

On Thu, 05 Oct 2006 14:45:42 +0300, Lionello Lunesu <lio@lunesu.remove.com> wrote:
> Kristian wrote:
[snip]
> If you don't care whether the file got deleted, why do you delete it in the first place? OK, I know very well what you're trying to say and I do it myself all the time, but I'll also admit that it's sloppy programming.
>
> Furthermore, 'the D way' is to throw an exception, not to return some value that is or is not tested.
>
> By the way, do you often use
>
> try { /* some code*/ } catch (Object o) {/* no code*/}
>
> too? They should, since the same reasoning applies to function throwing an exception.

Ok, ok, maybe my 'eraseFile()' example wasn't the best one... :)

I can't resist (sorry) pointing out that sometimes it's ok to silently ignore errors. ;) For example, there is a program that creates a temporary file. When the program is exited, the file will be deleted. Now, if the file cannot be deleted for some reason, what could you do? Notify the user with a message box telling that "Cannot delete the XXX file." or "Please delete the XXX file, or else!..." (that would annoy me, at least), or silently accept the fact that the file cannot be deleted and exit the program? *grin*

(Thanks for pointing out the usage of exceptions in D, though.)


>> Clearly you wouldn't want to do any extra work when calling functions of the group A. Or have warning/error messages with them. However, with the group B that would be ok.
>
> Granted, so perhaps it could be a warning message after all. Definately not an error, we've established that.

A warning message with an ability to turn it off? Or as I would prefer, a warning with an ability turn it on (it's off by default)?

Kristian wrote:
> On Thu, 05 Oct 2006 14:45:42 +0300, Lionello Lunesu <lio@lunesu.remove.com> wrote:
>> Kristian wrote:
> [snip]
>> If you don't care whether the file got deleted, why do you delete it in the first place? OK, I know very well what you're trying to say and I do it myself all the time, but I'll also admit that it's sloppy programming.
>>
>> Furthermore, 'the D way' is to throw an exception, not to return some value that is or is not tested.
>>
>> By the way, do you often use
>>
>> try { /* some code*/ } catch (Object o) {/* no code*/}
>>
>> too? They should, since the same reasoning applies to function throwing an exception.
> 
> Ok, ok, maybe my 'eraseFile()' example wasn't the best one... :)
> 
> I can't resist (sorry) pointing out that sometimes it's ok to silently ignore errors. ;) For example, there is a program that creates a temporary file. When the program is exited, the file will be deleted. Now, if the file cannot be deleted for some reason, what could you do? Notify the user with a message box telling that "Cannot delete the XXX file." or "Please delete the XXX file, or else!..." (that would annoy me, at least), or silently accept the fact that the file cannot be deleted and exit the program? *grin*

Like I said: point taken :)

>>> Clearly you wouldn't want to do any extra work when calling functions of the group A. Or have warning/error messages with them. However, with the group B that would be ok.
>>
>> Granted, so perhaps it could be a warning message after all. Definately not an error, we've established that.
> 
> A warning message with an ability to turn it off? Or as I would prefer, a warning with an ability turn it on (it's off by default)?

In D, warnings are off by default. You explicitly ask for warnings using -w.

L.