Experiment: functional concepts in C

[s0suk3]

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]

(e-mail address removed) writes:

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

yes

 

[vippstar]

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]

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]

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.lang.c/msg/7ce5393c60e40b19

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

Sebastian

 

[Ertugrul Söylemez]

yes

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.

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.

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,
with POSIX probably being the best example, or do you GNU users set
POSIXLY_CORRECT? I don't. 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.


Greets,
Ertugrul.

 

[Kenny McCormack]

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.

That's all you'll ever get here (in clc). It's the way it is.
They do this all over Usenet now - all they do is pick on you - because
there's just no psycho-sexual benefit to the poster for doing anything
else. But it is worse here than anywhere else.

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.

Welcome to CLC. We hope you enjoy your stay.

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,
with POSIX probably being the best example, or do you GNU users set
POSIXLY_CORRECT? I don't. 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.

People here don't brook nonsense like "theoretical experiment"s.

 

[vippstar]

vipps[82][email protected] 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]

<flushed>

You are such a tool...

 

[Keith Thompson]

On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi[81][email protected]> wrote:

vipps[82][email protected] 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>

[...]

 

[vippstar]

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)

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

 

[Ertugrul Söylemez]

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

Your interpretation may be different.

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? 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.

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

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.

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

This is a discussion forum, not a support forum.

As for POSIXLY_CORRECT, well, that's another off-topic query. [...]

That was not a query at all.

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.


Greets,
Ertugrul.

 

[Ertugrul Söylemez]

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.

That's all you'll ever get here (in clc). It's the way it is. They
do this all over Usenet now [...]

I can't confirm that, but yes, I expected much more positive answers
here. It seems that C is so uninteresting from a language-theoretic
standpoint that people are restricted to writing code and finding errors
in code (with using extensions being considererd one) rather than
talking a bit about the language itself and its design. The latter was
my intention.

In the functional language world, for example, this is way different.
Those people generally welcome theoretical discussions, experiments and
even criticism about the language, because one of the key points of
functional programming is to improve our way of coding and even
thinking. And it works. I'd happily replace C as the system language
by any comparably low-level functional language.

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. On the other hand, if I haven't overlooked something
obvious, with recursive #includes, the preprocessor is.

[1] http://www.willamette.edu/~fruehr/haskell/evolution.html


Greets,
Ertugrul.

 

[Phil Carmody]

Your interpretation may be different.


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

 

[Ertugrul Söylemez]

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.

There is of course nothing wrong with that. Feel free not to
participate in this thread.

I'm talking both about the language and about programming in it (or how
doing certain things is difficult). This discussion is, of course, by
no means productive, but as said, I never intended to contribute useful
code. I thought, some people would like to discuss the theoretical
aspects of C, or at least find my code amusing.

After all, I could have written the same code without using extensions.
It's just that it would be ten times as long and ten times as
incomprehensible.


Greets,
Ertugrul.

 

[James Kuyper]

(e-mail address removed) 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.

....

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.

 

[Keith Thompson]

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-c-from-new-perspective.html

Of the four programs you posted, three of them depend on a
non-standard extension, namely nested function definitions. As such,
they are, in my opinion, examples of using function concepts in a
C-like language (namely GNU C), not in C itself. (I wonder if similar
things could be done using only standard C -- but I don't wonder
enough to spend a whole lot of time thinking about it.)

If you think that these three programs are an argument in favor of
adding features to C itself, then comp.std.c would be the best place
to make that argument. I offer no opinion (at least for now) on
whether it would be a good idea.

Going back to the first program, it is in standard C, but some of the
coding is quite obscure. For example, in one place you write:
puts("_Expecting one argument.\0Invalid integer." + jv);
where jv has been set to either 1 or 25 in a call to longjmp. Some
other problems I found:

Your factorial function is declared to return an int, but it doesn't
return a value, and the call doesn't attempt to use the returned
value. (The result is returned via longjmp().)

You use the atoi() function, which invokes undefined behavior for
certain arguments.

Your variable names are unnecessarily terse. You use the name "p"
both for a static int in the factorial function, and for a jmp_buf.
If you want to illustrate an unconventional technique, I think it's
best to make the rest of the code as clear as possible.

Here's my version of your program:

/* Factorial function using continuations in C.
* Copyright (C) 2008, Ertugrul Söylemez
* Modified by Keith Thompson
*/

#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>

enum error_code {
no_error,
bad_arg_count,
invalid_integer
};

static char *errors[] = {
/* no_error (unused) */ NULL,
/* bad_arg_count */ "Expecting one argument.\n",
/* invalid_integer */ "Invalid integer.\n"
};


void factorial(int x, jmp_buf err, jmp_buf print) {
static int product;
jmp_buf recurse;
int jv;

product = 1;
if (x < 0) longjmp(err, invalid_integer);
jv = setjmp(recurse);
if (!jv) longjmp(recurse, x);

product *= jv;
if (jv > 1) longjmp(recurse, jv-1);
longjmp(print, product);
}


int main(int argc, char **argv) {
jmp_buf err;
jmp_buf print;
int jv;
int x;
char *endptr;

jv = setjmp(err);
if (jv) {
fputs(errors[jv], stderr);
return EXIT_FAILURE;
}

jv = setjmp(print);
if (jv) {
printf("%d\n", jv);
return 0;
}

if (argc != 2) {
longjmp(err, bad_arg_count);
}
x = strtol(argv[1], &endptr, 10);
if (argv[1][0] != '\0' && *endptr == '\0') {
factorial(x, err, print);
}
else {
longjmp(err, invalid_integer);
}
}

 

[Richard Tobin]

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

 

[Richard Tobin]

If you think that these three programs are an argument in favor of
adding features to C itself, then comp.std.c would be the best place
to make that argument.

I think this is quite wrong. It implies that there's no place for
discussion of extending C unless it's with a view to standardising it,
which would be absurdly premature in most cases.

There's a standard for C, but that doesn't mean that anything not
in the standard isn't C.

-- Richard

 

[Keith Thompson]

I think this is quite wrong. It implies that there's no place for
discussion of extending C unless it's with a view to standardising it,
which would be absurdly premature in most cases.

There's a standard for C, but that doesn't mean that anything not
in the standard isn't C.

When I say "adding features to C itself", I'm referring specifically
to making changes to the C standard.

You can add features to a C implementation, but then you're just
implementing extensions on top of C, not changing C itself.

Followups to comp.lang.c.