Re: Experiment: functional concepts in C

[vippstar]

On Nov 17, 1:43 pm, Ertugrul Söylemez <[e-mail]:

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("_Expecting one argument.\0Invalid 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]

vi******@gmail.com wrote:

On Nov 17, 1:43 pm, Ertugrul Söylemez <[e-mail]:

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("_Expecting one argument.\0Invalid 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]

On Nov 17, 5:36 pm, Ertugrul Söylemez <[e-mail]:

[e-mail] 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("_Expecting one argument.\0Invalid 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
comprehensibility 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]

vi******@gmail.com writes:

On Nov 17, 1:43 pm, Ertugrul Söylemez <[e-mail]:

>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]

vi******@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 (aa**************@uta.fi)

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

[s0suk3]

On Nov 17, 7:57*am, vi******@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]

s0****@gmail.com writes:

On Nov 17, 7:57*am, vi******@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_Keith) ks***@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]

On Nov 17, 3:46*pm, Keith Thompson <ks***@mib.orgwrote:

s0****@gmail.com writes:

On Nov 17, 7:57*am, vi******@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 "environment" 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]

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

s0****@gmail.com writes:

On Nov 17, 3:46*pm, Keith Thompson <ks***@mib.orgwrote:

>s0****@gmail.com writes:

On Nov 17, 7:57*am, vi******@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 "environment" 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_Keith) ks***@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]

On Nov 17, 4:14*pm, Keith Thompson <ks***@mib.orgwrote:

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

s0****@gmail.com writes:

On Nov 17, 3:46*pm, Keith Thompson <ks***@mib.orgwrote:

s0****@gmail.com writes:
On Nov 17, 7:57*am, vi******@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 "environment" 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]

s0****@gmail.com writes:

On Nov 17, 4:14*pm, Keith Thompson <ks***@mib.orgwrote:

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

s0****@gmail.com writes:

On Nov 17, 3:46*pm, Keith Thompson <ks***@mib.orgwrote:
s0****@gmail.com writes:
On Nov 17, 7:57*am, vi******@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 "environment" 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_Keith) ks***@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]

On Nov 17, 7:09*pm, Keith Thompson <ks***@mib.orgwrote:

s0****@gmail.com writes:

On Nov 17, 4:14*pm, Keith Thompson <ks***@mib.orgwrote:

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

s0****@gmail.com writes:
On Nov 17, 3:46*pm, Keith Thompson <ks***@mib.orgwrote:
s0****@gmail.com writes:
On Nov 17, 7:57*am, vi******@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 "environment" 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]

s0****@gmail.com writes:

On Nov 17, 7:09*pm, Keith Thompson <ks***@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_Keith) ks***@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]

On Nov 17, 8:39*pm, Keith Thompson <ks***@mib.orgwrote:

s0****@gmail.com writes:

On Nov 17, 7:09*pm, Keith Thompson <ks***@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]

On 17 Nov, 16:17, Aatu Koskensilta <[e-mail]:

[e-mail] writes:

At most, your original message classifies as spam.

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

yes

[vippstar]

On Nov 17, 10:46 pm, Keith Thompson <[e-mail]:

[e-mail] writes:

On Nov 17, 7:57 am, [e-mail] 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?

He is a troll, why are you wasting your time?

[Kenny McCormack]

In article <e2**********************************@r15g2000prh. googlegroups.com>,
<vi******@gmail.comwrote:

>On Nov 17, 10:46 pm, Keith Thompson <[e-mail]:

>[e-mail] writes:

On Nov 17, 7:57 am, [e-mail] 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?

He is a troll, why are you wasting your time?

Believe me in this: If there is one thing Keith Thompson has lots and
lots of, it is time (on his hands).

[s0suk3]

On Nov 18, 7:24*am, vi******@gmail.com wrote:

On Nov 17, 10:46 pm, Keith Thompson <[e-mail]:

[e-mail] writes:

On Nov 17, 7:57 am, [e-mail] 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?

He is a troll, why are you wasting your time?

I'd like to remind you of a thread, and especially of a particular
post:

http://groups.google.com/group/comp....e5393c60e40b19

where it was proven who of the two of us is a troll. (You yourself
admitted it; read the last line.)

Sebastian

[vippstar]

On Nov 18, 10:25 pm, Ertugrul Söylemez <[e-mail]:

Nick Keighley <nick_keighley_nos[80][e-mail]:

On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi[81][e-mail]:

vipps[82][e-mail] writes:

At most, your original message classifies as spam.

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

yes

Hm... Yes what?

Although I'm in some sense not entitled to judge, I wouldn't consider my
original post spam. Since this is a C group, it's off-topic in that I'm
talking about implementing closures using non-standard GCC features.

Spam: off-topic message luring views.
Your post: interesting off-topic discussion seeking different POVs.
At worst: spam.

If you disagree, that's fine. I don't think it was such an important
statement nor an outrageous insult (nor an insult at all in fact) so
let's just move on.

This is true and fine and great and everything, but I'm very
disappointed by the responses, because all I got was being flamed off
for using extensions, not a single comment on the actual subject.

You haven't been flamed yet, unless you see messages I don't.

Nobody cared about the theoretical value in the (latter three) source
codes. It feels like nobody of the original responders even read the
article -- where I pointed out that I used non-standard features! -- or
bothered about understanding the code.

Because your message was off-topic. There's another possibility that
some cared, but chosen not to pollute this newsgroup with more off-
topic messages. Another reason to be on-topic.

By the way, people break standards all the time.

True, but of little value. People break the law all the time as well -
that doesn't mean the law shouldn't exist, nor the opposite, that the
law is perfect.

If standards limit you
in what you can do for no apparent reason, they are bound to be broken,
with POSIX probably being the best example, or do you GNU users set
POSIXLY_CORRECT? I don't.

The reason might not be apparent, but it exists. If you have any REAL
queries about the reason a feature was included/excluded from C, you
can ask here. For example, you could ask the reason the standard
doesn't require the execution environment to free the memory allocated
by malloc, realloc, calloc upon program termination. You'll probably
get an answer similar to "feature X couldn't be supported in system Y
- Y being old, new, future, imaginary system"

As for POSIXLY_CORRECT, well, that's another off-topic query. As far
as the C standard is concerned, POSIXLY_CORRECT is an identifier for
the programmer, not the implementation. What POSIX programmers should
actually do is a query for comp.unix.programmer, but since it's a
quick one:

IEEE-1003.1-2004:
<http://www.opengroup.org/onlinepubs/009695399/basedefs/
xbd_chap02.html>

The system shall [...], and shall set the symbolic constant _POSIX_VERSION to the value 200112L.

An on-topic remark: _POSIX_VALUE is an identifier for the
implementation, because it starts with an underscore and that
underscore is followed by an uppercase letter.

On the other hand, lexical closures in C
_are_ a bad extension, but being useful, fast and elegant wasn't the
point of my code anyway. It was a theoretical experiment.

You've already been told this is off-topic. Please don't bring more
off-topic statements for fact-checking.

[Kenny McCormack]

In article <b3**********************************@i18g2000prf. googlegroups.com>,
<vi******@gmail.comwrote nothing of value:
<flushed>

You are such a tool...

[Keith Thompson]

vi******@gmail.com writes:

On Nov 18, 10:25 pm, Ertugrul Söylemez <[e-mail]:

>Nick Keighley <nick_keighley_nos[80][e-mail]:

On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi[81][e-mail]:

vipps[82][e-mail] writes:

At most, your original message classifies as spam.

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

yes

Hm... Yes what?

>Although I'm in some sense not entitled to judge, I wouldn't consider my
original post spam. Since this is a C group, it's off-topic in that I'm
talking about implementing closures using non-standard GCC features.

Spam: off-topic message luring views.
Your post: interesting off-topic discussion seeking different POVs.
At worst: spam.

No, that's not what the word "spam" means. Spam on Usenet is an
excessively cross-posted message; the most commonly accepted meaning
is anything that exceeds the Breidbart Index. A single message posted
to a single newsgroup might be inappropriate, but it cannot be spam.

[...]

>If standards limit you
in what you can do for no apparent reason, they are bound to be broken,
with POSIX probably being the best example, or do you GNU users set
POSIXLY_CORRECT? I don't.

[...]

>
As for POSIXLY_CORRECT, well, that's another off-topic query. As far
as the C standard is concerned, POSIXLY_CORRECT is an identifier for
the programmer, not the implementation. What POSIX programmers should
actually do is a query for comp.unix.programmer, but since it's a
quick one:

IEEE-1003.1-2004:
<http://www.opengroup.org/onlinepubs/009695399/basedefs/
xbd_chap02.html>

>The system shall [...], and shall set the symbolic constant _POSIX_VERSION to the value 200112L.

An on-topic remark: _POSIX_VALUE is an identifier for the
implementation, because it starts with an underscore and that
underscore is followed by an uppercase letter.

<OT>That doesn't have much to do with POSIXLY_CORRECT, which is the
name of an environment variable, not a C identifier.</OT>

[...]

--
Keith Thompson (The_Other_Keith) ks***@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"

[vippstar]

On Nov 19, 1:05 am, Keith Thompson <[e-mail]:

[e-mail] writes:

Spam: off-topic message luring views.

No, that's not what the word "spam" means. Spam on Usenet is an
excessively cross-posted message; the most commonly accepted meaning
is anything that exceeds the Breidbart Index. A single message posted
to a single newsgroup might be inappropriate, but it cannot be spam.

I don't really want to argue with definitions for English words, but I
think the jargon file disagrees with you.
<http://catb.org/jargon/html/S/spam.html>
In particular, see 2, "this is _often_ done with cross-posting
[...]" (emphasis added by me)

<snip>

<OT>That doesn't have much to do with POSIXLY_CORRECT, which is the
name of an environment variable, not a C identifier.</OT>

Whatever POSIXLY_CORRECT is, it's defined in a standard other than C
(and for that matter, POSIX). C (and POSIX) says POSIXLY_CORRECT is an
identifier in the programmers namespace, which means he is under
complete control of what it is.

[Phil Carmody]

Ertugrul Söylemez <[e-mail]:

vi******@gmail.com wrote:

This is true and fine and great and everything, but I'm very
disappointed by the responses, because all I got was being flamed
off for using extensions, not a single comment on the actual
subject.

You haven't been flamed yet, unless you see messages I don't.

Your interpretation may be different.

Nobody cared about the theoretical value in the (latter three)
source codes. It feels like nobody of the original responders even
read the article -- where I pointed out that I used non-standard
features! -- or bothered about understanding the code.

Because your message was off-topic. There's another possibility that
some cared, but chosen not to pollute this newsgroup with more off-
topic messages. Another reason to be on-topic.

Being standards-compliant is one thing, simply being counter-innovative
is another. What do we need comp.std.c for, if this newsgroup is about
and only about standard C, and if going beyond it is evil?

You're confusing talking about the standard and talking about
programming using the standard. For example, I rarely have any
interest in discussions about upcoming propositions and drafts
of the standard, so I don't generally hang aroung comp.std.c.
Yet I have a strong interest in programming portable C, so I
do hang around here. I don't see the two groups as being much
more related than a French linguistics group is to a French
chat group, or a beer-drinkers group is to a brewing group.

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.

[Keith Thompson]

vi******@gmail.com writes:

On Nov 19, 1:05 am, Keith Thompson <[e-mail]:

>[e-mail] writes:

Spam: off-topic message luring views.

No, that's not what the word "spam" means. Spam on Usenet is an
excessively cross-posted message; the most commonly accepted meaning
is anything that exceeds the Breidbart Index. A single message posted
to a single newsgroup might be inappropriate, but it cannot be spam.

I don't really want to argue with definitions for English words,

.... and yet ...

but I
think the jargon file disagrees with you.
<http://catb.org/jargon/html/S/spam.html>
In particular, see 2, "this is _often_ done with cross-posting
[...]" (emphasis added by me)

I don't disagree with the jargon file; if you'll read the rest of the
entry, you'll see that the first two meanings have largely fallen into
disuses.

Meaning 2 describes what I'd call "trolling", i.e., posting something
inflammatory with the intent of starting an argument. I don't think
that's what the OP intended to do.

<snip>

><OT>That doesn't have much to do with POSIXLY_CORRECT, which is the
name of an environment variable, not a C identifier.</OT>

Whatever POSIXLY_CORRECT is, it's defined in a standard other than C
(and for that matter, POSIX).

I'm not sure that it's defined in any standard. For purposes of this
newsgroup, it suffices to say that it's not defined in the C standard
(and nobody has suggested that it is). The previous poster mentioned
POSIXLY_CORRECT in passing in the context of talking about conforming
or not conforming to standards. (GNU software often doesn't quite
conform to POSIX by default; setting POSIXLY_CORRECT causes it to
conform more closely.) It was a real-world example meant to
illustrate a point.

C (and POSIX) says POSIXLY_CORRECT is an
identifier in the programmers namespace, which means he is under
complete control of what it is.

POSIXLY_CORRECT in this context *is not an identifier*. It's the name
of an environment variable, which means it's a string whose address
you could pass to getenv(). If you want to mention that it's
off-topic, fine, but why go off on a tangent about how that particular
character string could be used as an identifier in a C program?

--
Keith Thompson (The_Other_Keith) ks***@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"

[James Kuyper]

Ertugrul Söylemez wrote:

vi******@gmail.com wrote:

....

Being standards-compliant is one thing, simply being counter-innovative
is another. What do we need comp.std.c for, if this newsgroup is about
and only about standard C,

comp.std.c is for discussions about the C standard. comp.lang.c is for
discussions about how to use the language defined by that standard.
Proposed changes to the standard are on-topic in comp.std.c, and
off-topic in comp.lang.c. If you are talking about an extension to C
that you do not propose standardizing, it's off-topic in both groups.

I have no idea what's on-topic in comp.lang.functional.

... and if going beyond it is evil?

Going beyond the standard isn't evil, just off-topic. You're wasting
time (yours and other peoples) by discussing it here, just as you would
be wasting time going to a butcher shop when you're trying to buy flowers.

....

By the way, according to your view, GCC and most other compilers are not
C compilers. They compile some language derived from C.

gcc has a mode that fully-conforms to C90, making it definitely a C
compiler when used in that mode. It has another mode that comes pretty
close to fully conforming to C99. It is "almost" a C compiler when used
in that mode.

....

>>By the way, people break standards all the time.

True, but of little value. People break the law all the time as well -
that doesn't mean the law shouldn't exist, nor the opposite, that the
law is perfect.

Your view appears to be that in a law-related newsgroup, one shouldn't
talk about the limits of law and/or about breaking it.

comp.std.c is the equivalent of a "law-related" group in this context,
and discussion of changes to the standard would certainly be on-topic there.

[Richard Tobin]

In article <20*********************@ertes.de>,
Ertugrul Söylemez <[e-mail]:

>Being standards-compliant is one thing, simply being counter-innovative
is another. What do we need comp.std.c for, if this newsgroup is about
and only about standard C, and if going beyond it is evil? Where should
I post this instead? In my opinion, this _is_ a C-related topic, at
least because it shows something that is difficult to implement in
standard C.

There is no agreement about what is topical in comp.lang.c.
Originally it was very broad, often including discussions about unix.
At some point several of the most prolific posters seem to have
decided that only discussion of standard C was acceptable. If they
have succeeded in imposing this view, it is only by repeated
assertion, so they can have no complaint if the issue swings the other
way.

So if you feel (as I do) that discussion of improvements to C is
reasonable in comp.lang.c, I suggest that you just go ahead and
discuss them, and ignore the complaints. Don't waste your time
arguing about topicality.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[vippstar]

On Nov 19, 4:44 am, Keith Thompson <[e-mail]:

[e-mail] writes:

<snip>

Whatever POSIXLY_CORRECT is, it's defined in a standard other than C
(and for that matter, POSIX).

I'm not sure that it's defined in any standard. For purposes of this
newsgroup, it suffices to say that it's not defined in the C standard
(and nobody has suggested that it is). The previous poster mentioned
POSIXLY_CORRECT in passing in the context of talking about conforming
or not conforming to standards. (GNU software often doesn't quite
conform to POSIX by default; setting POSIXLY_CORRECT causes it to
conform more closely.) It was a real-world example meant to
illustrate a point.

C (and POSIX) says POSIXLY_CORRECT is an
identifier in the programmers namespace, which means he is under
complete control of what it is.

POSIXLY_CORRECT in this context *is not an identifier*. It's the name
of an environment variable, which means it's a string whose address
you could pass to getenv(). If you want to mention that it's
off-topic, fine, but why go off on a tangent about how that particular
character string could be used as an identifier in a C program?

Because I completely missed what Ertugrul said/illustrated with
POSIXCLY_CORRECT. I see it now that you pointed it out, thanks.

[dj3vande]

In article <20*********************@ertes.de>,
Ertugrul SC6ylemez <[e-mail]:

>This is true and fine and great and everything, but I'm very
disappointed by the responses, because all I got was being flamed off
for using extensions, not a single comment on the actual subject.
Nobody cared about the theoretical value in the (latter three) source
codes. It feels like nobody of the original responders even read the
article -- where I pointed out that I used non-standard features! -- or
bothered about understanding the code.

Your original subject is something I have some interest in, and my
initial impression was that you're going about it in entirely the wrong
way.
If I get the opportunity to do so before the article expires from my
newsserver (which may or may not happen), I intend to take a close
enough look at it to come up with something coherent and substantial to
say. But that will take a bit longer than noticing and pointing out
that you're using ill-advised extensions that most of the world doesn't
have available would.

>By the way, people break standards all the time. If standards limit you
in what you can do for no apparent reason, they are bound to be broken,

....and if you're lucky, you will soon realize why the standard imposes
that restriction. (If you're not lucky, you won't reach that
realization until you have a large mess of non-compliant stuff to deal
with.)

>with POSIX probably being the best example, or do you GNU users set
POSIXLY_CORRECT? I don't.

This (or equivalent mental discipline) is in fact recommended by most
of the people I know who regularly use GNU tools. They've all been
bitten at one time or another by assuming GNU extensions where they
don't exist and can't be added.
dave

--
Dave Vandervies dj3vande at eskimo dot com

>[P]rotect the originals with something that has sharp teeth, long tentacles
and a big appetite. --Alexander Schreiber and Michel

In other words: Keep it with you. Buijsman in the scary devil monastery

[dj3vande]

[Followup-To trimmed to comp.lang.c only]

In article <20*********************@ertes.de>,
Ertugrul SC6ylemez <[e-mail]:

>vi******@gmail.com wrote:

>Because your message was off-topic. There's another possibility that
some cared, but chosen not to pollute this newsgroup with more off-
topic messages. Another reason to be on-topic.

Being standards-compliant is one thing, simply being counter-innovative
is another.

Your innovation is my users' heap of useless code. The whole point of
standardization *is* to limit innovation in the interface, to
facilitate innovation at the next level up by giving users a consistent
platform to build on.

If you want to make a better compiler, that kind of innovation would be
welcomed by (many of the) people here, but it's not really appropriate
for discussion here; there are other places to talk about playing with
compilers and hacking on any particular compiler you want to start
with.
If you want to use (or implement) language features that C doesn't
have, then, well, you're not using C anymore, so it's kind of useless
to talk about it in comp.lang.c.

But if you want to do something new and interesting and implement it in
C, *that*'s (part of) what this newsgroup is here for. Despite what
our resident trolls and whiners would have you believe, there's plenty
of room for innovation there, and most of that room is *created by* the
fact that we have a standard language to build on and don't have to
worry about whether I'm using the same compiler you are.

(If you want to discuss whether some extension to the language would be
useful, that's kind of a grey area; but it's more off-topic than
on-topic, and it's more likely to be tolerated when it's coming from
people who already have a history of making interesting contributions
that are unambiguously on-topic.)

Where should
I post this instead? In my opinion, this _is_ a C-related topic, at
least because it shows something that is difficult to implement in
standard C.

Building functional abstractions in C is a C-related topic and is
appropriate for discussion here.
Building functional abstractions in GCC's not-quite-C default language
is appropriate for discussion in places intended for discussion of
programming in GCC's not-quite-C default language.
Learning to recognize the difference is the first step on the path to
wisdom.

>By the way, according to your view, GCC and most other compilers are not
C compilers. They compile some language derived from C.

Adding "by default" in appropriate places would make that sentence
perfectly correct.
One of the few bits of compiler-specific information that's generally
considered acceptable here is how to make the compiler speak C and not
its own C-like dialect. (For GCC it's '-ansi -pedantic' for C90, and
'-std=c99 -pedantic' for a partial C99 implementation.)

>You've already been told this is off-topic. Please don't bring more
off-topic statements for fact-checking.

You told me. I'm unable to find any etiquette or posting rules. This
is a C-related topic. The group name suggests it's on-topic.

For etiquette and posting rules,
<http://www.clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
is probably a good place to start.
(It may or may not be mentioned somewhere there, but a thick skin and a
willingness to learn are both pretty much essential.)
(It is rather unfortunate that most of the comments you got were on the
parts of your post that used GCC extensions; there's an interesting and
on-topic discussion hiding in the parts of your post that are
restricted to standard C.)
dave

--
Dave Vandervies dj3vande at eskimo dot com

>[P]rotect the originals with something that has sharp teeth, long tentacles
and a big appetite. --Alexander Schreiber and Michel

In other words: Keep it with you. Buijsman in the scary devil monastery

[Richard Tobin]

In article <gg**********@rumours.uwaterloo.ca>,
<dj******@csclub.uwaterloo.ca.invalidwrote:

>Your innovation is my users' heap of useless code. The whole point of
standardization *is* to limit innovation in the interface, to
facilitate innovation at the next level up by giving users a consistent
platform to build on.

This is a false dichotomy. Having unstandardised extensions doesn't
prevent you from coding to the standard.

>If you want to make a better compiler, that kind of innovation would be
welcomed by (many of the) people here, but it's not really appropriate
for discussion here; there are other places to talk about playing with
compilers and hacking on any particular compiler you want to start
with.

And this is another bogus argument. If I want to discuss an extension
or change to C or C compilation, why on earth should I necessarily
want to do so in the context of some particular compiler? I may not
even be a compiler hacker, and merely want to discuss it in the
abstract.

>If you want to use (or implement) language features that C doesn't
have, then, well, you're not using C anymore, so it's kind of useless
to talk about it in comp.lang.c.

Only if by "C" you mean exclusively "standardised C", which many of
us don't.

I encourage anyone with interesting ideas for C, that aren't
specific to some particular platform, to discuss them here.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[CBFalconer]

dj******@csclub.uwaterloo.ca.invalid wrote:

Ertugrul SC6ylemez <[e-mail]:

>vi******@gmail.com wrote:

>>Because your message was off-topic. There's another possibility
that some cared, but chosen not to pollute this newsgroup with
more off-topic messages. Another reason to be on-topic.

Being standards-compliant is one thing, simply being counter-
innovative is another.

Your innovation is my users' heap of useless code. The whole
point of standardization *is* to limit innovation in the
interface, to facilitate innovation at the next level up by
giving users a consistent platform to build on.

If you want to make a better compiler, that kind of innovation
would be welcomed by (many of the) people here, but it's not
really appropriate for discussion here; there are other places
to talk about playing with compilers and hacking on any
particular compiler you want to start with.

If you want to use (or implement) language features that C
doesn't have, then, well, you're not using C anymore, so it's
kind of useless to talk about it in comp.lang.c.

But if you want to do something new and interesting and
implement it in C, *that*'s (part of) what this newsgroup is
here for. Despite what our resident trolls and whiners would
have you believe, there's plenty of room for innovation there,
and most of that room is *created by* the fact that we have a
standard language to build on and don't have to worry about
whether I'm using the same compiler you are.

This is just about the best description I have seen of c.l.c
topicality. Note, in your last paragraph, that the 'new and
interesting' part can be thoroughly described by publishing its
code, written in standard C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Aatu Koskensilta]

vi******@gmail.com writes:

Spam: off-topic message luring views.
Your post: interesting off-topic discussion seeking different POVs.
At worst: spam.

You're quite mistaken as to what spam is.

--
Aatu Koskensilta (aa**************@uta.fi)

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

[Aatu Koskensilta]

Ertugrul Söylemez <[e-mail]:

By the way, the idea was inspired by The Evolution of a Haskell
Programmer [1]. I thought, it would be funny to try to implement some
of those examples in C. Unfortunately C's type system is not
Turing-complete.

Neither is Haskell's.

--
Aatu Koskensilta (aa**************@uta.fi)

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

[Aatu Koskensilta]

Ertugrul Söylemez <[e-mail]:

Haskell's type system gives me the same computational power as Haskell
itself. Maybe I missed something?

Yes. You're missing the fact that Haskell's type system, as defined by
the Haskell report, does not give you the same computational power as
Haskell itself.

--
Aatu Koskensilta (aa**************@uta.fi)

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

[dj3vande]

In article <gg**********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

>In article <gg**********@rumours.uwaterloo.ca>,
<dj******@csclub.uwaterloo.ca.invalidwrote:

>>Your innovation is my users' heap of useless code. The whole point of
standardization *is* to limit innovation in the interface, to
facilitate innovation at the next level up by giving users a consistent
platform to build on.

This is a false dichotomy. Having unstandardised extensions doesn't
prevent you from coding to the standard.

And how, exactly, does that help me when somebody presents a
potentially-interesting idea expressed using extensions I don't have?

>>If you want to make a better compiler, that kind of innovation would be
welcomed by (many of the) people here, but it's not really appropriate
for discussion here; there are other places to talk about playing with
compilers and hacking on any particular compiler you want to start
with.

And this is another bogus argument. If I want to discuss an extension
or change to C or C compilation, why on earth should I necessarily
want to do so in the context of some particular compiler?

If you'd read my entire post, you would have noticed that I addressed
exactly that point a few lines down; and had you spent a few
milliseconds thinking about it, instead of just trying to play chatbot
with it, that should have enough of a clue to realize that the part
you're replying to wasn't intended to address that particular case at
all.

>>If you want to use (or implement) language features that C doesn't
have, then, well, you're not using C anymore, so it's kind of useless
to talk about it in comp.lang.c.

Only if by "C" you mean exclusively "standardised C", which many of
us don't.

So how would *you* define C, then? "Anything my compiler compiles"?
Not very useful to the rest of us. "Anything anybody's compiler
compiles"? Not very useful to *anybody*. Some subset of that? Where
do you draw the line? (Oh, Look! Some international group that
specializes in defining things has published a definition of some
programming language called "C"! Why don't we use that? That way we
know we're all talking about the same thing!)
dave

--
Dave Vandervies dj3vande at eskimo dot com
Other than that, your abstract needs to be completely rewritten. Fortunately,
that's something that can be left until the rest of your document has been
completely rewritten. --Simon G Best in comp.theory