Re: Experiment: functional concepts in C

[vippstar@gmail.com]

On Nov 17, 1:43 pm, Ertugrul Söylemez <e...@ertes.dew rote:

Hello people,
>
I thought it would be funny to try to bring functional concepts into the
C language. If anyone is interested, I have published the results on my
blog [1].
>
[1] http://blog.ertes.de/2008/11/obscure...rspective.html

Well your blog entry starts with

C is probably the most uninteresting programming language in the world.

which is untrue and a bad way to start an article.

Reading further, in your code
<http://ertes.de/cfact/cfact1.c>

It seems you want to obfuscate your code, since you have things like

puts("_Expectin g one argument.\0Inva lid integer." + jv); /* vippstar: jv is return value of setjmp */

Line 34 you return a value other than 0, EXIT_SUCCESS and
EXIT_FAILURE, which doesn't need to be meaningful.

The other 3 source files (cfact[2,3,4].c) are not standard C.

[Bartc]

Re: Experiment: functional concepts in C

vippstar@gmail. com wrote:

On Nov 17, 1:43 pm, Ertugrul Söylemez <e...@ertes.dew rote:

Reading further, in your code
<http://ertes.de/cfact/cfact1.c>
>
It seems you want to obfuscate your code, since you have things like
>

>puts("_Expecti ng one argument.\0Inva lid integer." + jv); /*
>vippstar: jv is return value of setjmp */

I had a look to see if the OP had really put in the comment just for your
benefit. He hadn't.

--
Bartc

[vippstar@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 5:36 pm, Ertugrul Söylemez <e...@ertes.dew rote:

vipps...@gmail. com wrote:

Reading further, in your code
<http://ertes.de/cfact/cfact1.c>

>

It seems you want to obfuscate your code, since you have things like

>

puts("_Expectin g one argument.\0Inva lid integer." + jv); /*
vippstar: jv is return value of setjmp */

>
Yes, the first version was indeed just a funny thing, which started it
all. I'm not happy with the result though, because of what you
mentioned.
>
The latter three versions, those which are not standard C, are more
interesting. They implement something, which is totally natural in
functional languages, but which turns an imperative language into a
comprehensibili ty hell, without needing to artifically obfuscate code
like in the first version. I'd love to implement them in standard C,
but as said in another post and in the blog, that was almost impossible.

The reason I mentioned the other three sources are not standard C is
because I did not comment on them.
If it's discussion/proposal for new C features, comp.lang.c is not the
right newsgroup. (comp.std.c would be better)
At most, your original message classifies as spam. Moreover, it's
usually better to just publish your article on usenet instead of
providing a web link.

[Sean G. McLaughlin]

Re: Experiment: functional concepts in C

vippstar@gmail. com writes:

On Nov 17, 1:43 pm, Ertugrul Söylemez <e...@ertes.dew rote:

>Hello people,
>>
>I thought it would be funny to try to bring functional concepts into the
>C language. If anyone is interested, I have published the results on my
>blog [1].
>>
>[1] http://blog.ertes.de/2008/11/obscure...rspective.html

>
Well your blog entry starts with
>

>C is probably the most uninteresting programming language in the world.

>
which is untrue and a bad way to start an article.

You have misquoted the OP by omitting the subordinate clause and making
the main clause a sentence standing on its own. The original text is,
for those who are too lazy to read the article,

"C is probably one of the most uninteresting programming languages in
the world, *from a language theory standpoint.*"

[Aatu Koskensilta]

Re: Experiment: functional concepts in C

vippstar@gmail. com writes:

At most, your original message classifies as spam.

No, his original message doesn't. At worst the post classifies as
off-topic.

--
Aatu Koskensilta (aatu.koskensil ta@uta.fi)

"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus

[s0suk3@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 7:57 am, vippstar@gmail. com wrote:

Line 34 you return a value other than 0, EXIT_SUCCESS and
EXIT_FAILURE, which doesn't need to be meaningful.

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

The other 3 source files (cfact[2,3,4].c) are not standard C.

Unsurprisingly, considering that the original post talked about
"bringing functional concepts into the C language."

Sebastian

[Keith Thompson]

Re: Experiment: functional concepts in C

s0suk3@gmail.co m writes:

On Nov 17, 7:57 am, vippstar@gmail. com wrote:

>Line 34 you return a value other than 0, EXIT_SUCCESS and
>EXIT_FAILURE , which doesn't need to be meaningful.

>
Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

They're meaningful for any conforming hosted C implementation. Can
you cite an implementation where they're not?

[...]

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[s0suk3@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 3:46 pm, Keith Thompson <kst-u@mib.orgwrote:

s0suk3@gmail.co m writes:

On Nov 17, 7:57 am, vippstar@gmail. com wrote:

Line 34 you return a value other than 0, EXIT_SUCCESS and
EXIT_FAILURE, which doesn't need to be meaningful.

>

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

>
They're meaningful for any conforming hosted C implementation.

Then there is no conforming hosted C implementation. No compiler could
possibly predict how all the programs in a system will interpret exit
codes from other programs.

Note: When I said "environmen t" in my previous post, I didn't just
mean the operating system. Any program can execute another program and
interpret its exit status however it wants.

Sebastian

[Keith Thompson]

Re: Experiment: functional concepts in C

Since this is no longer relevant to comp.lang.funct ional, I'm
redirecting followups.

s0suk3@gmail.co m writes:

On Nov 17, 3:46 pm, Keith Thompson <kst-u@mib.orgwrote:

>s0suk3@gmail.co m writes:

On Nov 17, 7:57 am, vippstar@gmail. com wrote:
>Line 34 you return a value other than 0, EXIT_SUCCESS and
>EXIT_FAILURE , which doesn't need to be meaningful.

>>

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

>>
>They're meaningful for any conforming hosted C implementation.

>
Then there is no conforming hosted C implementation. No compiler could
possibly predict how all the programs in a system will interpret exit
codes from other programs.
>
Note: When I said "environmen t" in my previous post, I didn't just
mean the operating system. Any program can execute another program and
interpret its exit status however it wants.

Every hosted system I'm familiar with has a convention for
interpreting status codes. For example, Unix uses 0 for success, and
OpenVMS uses odd numbers for success. Certainly there's nothing
preventing any individual program running on such a system from
violating those conventions -- but so what? The command line
interpreter (e.g., the shell on Unix) is required to follow the
conventions; see, for example, the behavior of the "if" and "while"
statements in the Bourne shell.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[s0suk3@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 4:14 pm, Keith Thompson <kst-u@mib.orgwrote:

Since this is no longer relevant to comp.lang.funct ional, I'm
redirecting followups.
>
s0suk3@gmail.co m writes:

On Nov 17, 3:46 pm, Keith Thompson <kst-u@mib.orgwrote:

s0suk3@gmail.co m writes:
On Nov 17, 7:57 am, vippstar@gmail. com wrote:
Line 34 you return a value other than 0, EXIT_SUCCESS and
EXIT_FAILURE, which doesn't need to be meaningful.

>

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

>

They're meaningful for any conforming hosted C implementation.

>

Then there is no conforming hosted C implementation. No compiler could
possibly predict how all the programs in a system will interpret exit
codes from other programs.

>

Note: When I said "environmen t" in my previous post, I didn't just
mean the operating system. Any program can execute another program and
interpret its exit status however it wants.

>
Every hosted system I'm familiar with has a convention for
interpreting status codes.

Exactly. They're conventions, not rules (at least not usually).

> For example, Unix uses 0 for success, and
OpenVMS uses odd numbers for success.  Certainly there's nothing
preventing any individual program running on such a system from
violating those conventions -- but so what? The command line
interpreter (e.g., the shell on Unix) is required to follow the
conventions; see, for example, the behavior of the "if" and "while"
statements in the Bourne shell.

It acts as a scripting language interpreter so it's obvious that it
will follow those conventions. But there might be other (OS native)
kinds of program launchers; for example, how about a GUI file browser
(such as KDE's Dolphin or Windows' "My PC")? For such launchers the
return codes will be less important. I at least have never heard about
how they interpret return codes, but if they do, they'll probably have
more freedom in choosing how to interpret them (and they may do so in
an unconventional way).

Sebastian

[Keith Thompson]

Re: Experiment: functional concepts in C

s0suk3@gmail.co m writes:

On Nov 17, 4:14 pm, Keith Thompson <kst-u@mib.orgwrote:

>Since this is no longer relevant to comp.lang.funct ional, I'm
>redirecting followups.
>>
>s0suk3@gmail.co m writes:

On Nov 17, 3:46 pm, Keith Thompson <kst-u@mib.orgwrote:
>s0suk3@gmail.co m writes:
On Nov 17, 7:57 am, vippstar@gmail. com wrote:
>Line 34 you return a value other than 0, EXIT_SUCCESS and
>EXIT_FAILURE , which doesn't need to be meaningful.

>>

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

>>

>They're meaningful for any conforming hosted C implementation.

>>

Then there is no conforming hosted C implementation. No compiler could
possibly predict how all the programs in a system will interpret exit
codes from other programs.

>>

Note: When I said "environmen t" in my previous post, I didn't just
mean the operating system. Any program can execute another program and
interpret its exit status however it wants.

>>
>Every hosted system I'm familiar with has a convention for
>interpreting status codes.

>
Exactly. They're conventions, not rules (at least not usually).
>

>> For example, Unix uses 0 for success, and
>OpenVMS uses odd numbers for success.  Certainly there's nothing
>preventing any individual program running on such a system from
>violating those conventions -- but so what? The command line
>interpreter (e.g., the shell on Unix) is required to follow the
>conventions; see, for example, the behavior of the "if" and "while"
>statements in the Bourne shell.

>
It acts as a scripting language interpreter so it's obvious that it
will follow those conventions. But there might be other (OS native)
kinds of program launchers; for example, how about a GUI file browser
(such as KDE's Dolphin or Windows' "My PC")? For such launchers the
return codes will be less important. I at least have never heard about
how they interpret return codes, but if they do, they'll probably have
more freedom in choosing how to interpret them (and they may do so in
an unconventional way).

Certainly an application that invokes another program can do whatever
it likes, or do nothing, with the returned status.

But here's what the standard says (C99 7.20.4.3p5, describing the
exit() function):

Finally, control is returned to the host environment. If the value
of status is zero or EXIT_SUCCESS, an implementation-defined form
of the status _successful termination_ is returned. If the value
of status is EXIT_FAILURE, an implementation-defined form of the
status _unsuccessful termination) is returned. Otherwise the
status returned is implementation-defined.

Will you at least agree that returning a value of zero, EXIT_SUCCESS,
or EXIT_FAILURE is more meaningful, as far as the C language
requirements are concerned, than returning other values?

If not, I don't think there's anything more to be said.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[s0suk3@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 7:09 pm, Keith Thompson <kst-u@mib.orgwrote:

s0suk3@gmail.co m writes:

On Nov 17, 4:14 pm, Keith Thompson <kst-u@mib.orgwrote:

Since this is no longer relevant to comp.lang.funct ional, I'm
redirecting followups.

>

s0suk3@gmail.co m writes:
On Nov 17, 3:46 pm, Keith Thompson <kst-u@mib.orgwrote:
s0suk3@gmail.co m writes:
On Nov 17, 7:57 am, vippstar@gmail. com wrote:
Line 34 you return a value other than 0, EXIT_SUCCESS and
EXIT_FAILURE, which doesn't need to be meaningful.

>

Whether the return status is meaningful or not is completely dependent
on the environment that executes the program. Even 0, EXIT_SUCCESS and
EXIT_FAILURE might not be meaningful (though, at least for 0, this
would be very rare).

>

They're meaningful for any conforming hosted C implementation.

>

Then there is no conforming hosted C implementation. No compiler could
possibly predict how all the programs in a system will interpret exit
codes from other programs.

>

Note: When I said "environmen t" in my previous post, I didn't just
mean the operating system. Any program can execute another program and
interpret its exit status however it wants.

>

Every hosted system I'm familiar with has a convention for
interpreting status codes.

>

Exactly. They're conventions, not rules (at least not usually).

>

> For example, Unix uses 0 for success, and
OpenVMS uses odd numbers for success.  Certainly there's nothing
preventing any individual program running on such a system from
violating those conventions -- but so what? The command line
interpreter (e.g., the shell on Unix) is required to follow the
conventions; see, for example, the behavior of the "if" and "while"
statements in the Bourne shell.

>

It acts as a scripting language interpreter so it's obvious that it
will follow those conventions. But there might be other (OS native)
kinds of program launchers; for example, how about a GUI file browser
(such as KDE's Dolphin or Windows' "My PC")? For such launchers the
return codes will be less important. I at least have never heard about
how they interpret return codes, but if they do, they'll probably have
more freedom in choosing how to interpret them (and they may do so in
an unconventional way).

>
Certainly an application that invokes another program can do whatever
it likes, or do nothing, with the returned status.
>
But here's what the standard says (C99 7.20.4.3p5, describing the
exit() function):
>
    Finally, control is returned to the host environment. If the value
    of status is zero or EXIT_SUCCESS, an implementation-defined form
    of the status _successful termination_ is returned. If the value
    of status is EXIT_FAILURE, an implementation-defined form of the
    status _unsuccessful termination) is returned. Otherwise the
    status returned is implementation-defined.
>
Will you at least agree that returning a value of zero, EXIT_SUCCESS,
or EXIT_FAILURE is more meaningful, as far as the C language
requirements are concerned, than returning other values?

Yes. And compilers will usually provide meaningful values for
EXIT_SUCCESS and EXIT_FAILURE.

But the point is not whether those values are meaningful or not; the
point is that compilers can't predict the kinds of applications that
will execute programs and interpret their return codes.

But yes, in general, 0, EXIT_SUCCESS and EXIT_FAILURE are reasonable
values to return, even though it can't be *guaranteed* that the parent
process will always interpret the status as you intended.

Sebastian

[Keith Thompson]

Re: Experiment: functional concepts in C

s0suk3@gmail.co m writes:

On Nov 17, 7:09 pm, Keith Thompson <kst-u@mib.orgwrote:

[...]

>Will you at least agree that returning a value of zero, EXIT_SUCCESS,
>or EXIT_FAILURE is more meaningful, as far as the C language
>requirements are concerned, than returning other values?

>
Yes. And compilers will usually provide meaningful values for
EXIT_SUCCESS and EXIT_FAILURE.
>
But the point is not whether those values are meaningful or not;

[...]

Re-read the thread; that was exactly the point.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[s0suk3@gmail.com]

Re: Experiment: functional concepts in C

On Nov 17, 8:39 pm, Keith Thompson <kst-u@mib.orgwrote:

s0suk3@gmail.co m writes:

On Nov 17, 7:09 pm, Keith Thompson <kst-u@mib.orgwrote:

[...]

Will you at least agree that returning a value of zero, EXIT_SUCCESS,
or EXIT_FAILURE is more meaningful, as far as the C language
requirements are concerned, than returning other values?

>

Yes. And compilers will usually provide meaningful values for
EXIT_SUCCESS and EXIT_FAILURE.

>

But the point is not whether those values are meaningful or not;

>
[...]
>
Re-read the thread; that was exactly the point.

OK, I should have said "meaningful in general" or "meaningful in
regard to the standard". Other than that, the point that the exit
status *can't* always be meaningful still remains.

Sebastian

[Nick Keighley]

Re: Experiment: functional concepts in C

On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi. ..@uta.fiwrote:

vipps...@gmail. com writes:

At most, your original message classifies as spam.

>
No, his original message doesn't. At worst the post classifies as
off-topic.

yes