Experiment: functional concepts in C

[Ertugrul Söylemez]

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


Greets,
Ertugrul.

 

[Nick Keighley]

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

your code seems to have no whitespace in it including newlines.
I can't be bothered to re-layout it to make it readable.

(it could be a problem with my browser of course)

ah. It looks ok if I look at the source. It isn't HTML

 

[vippstar]

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

 

[Phil Carmody]

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

"I have written four versions of the factorial function in C
[...]
Version 2 — using function pointer continuations"

[ which contains:
void fact(int x, void (*e)(char *), void (*k)(int)) {
void mulCont(int y) {
k(x*y);
}
... ]

Version 3 — implementing algebraic lists and folds using closures

[ which contains:
void cons(int x, list xs, void (*k)(list)) {
void concat(void (*end)(), void (*more)(int)) {
more(x);
xs(end, more);
}
... ]

Version 4 — lambda calculus with fixpoint operator

[ which contains:
void fix(int (*f)(int (*)(int), int), void (*k)(int (*)(int))) {
int ldf(int x) {
int y;
... ]
"""


Perhaps you'd like to reword the introduction to say "I have written
four versions of the factorial function, one of which is in C and
the rest of them are not in C."?

Phil

 

[Kenny McCormack]

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

your code seems to have no whitespace in it including newlines.
I can't be bothered to re-layout it to make it readable.

(it could be a problem with my browser of course)

It displays fine in lynx. You should try it.

ah. It looks ok if I look at the source. It isn't HTML

It displays fine in lynx. You should try it.

Note to vippy: Of course it isn't standard C. That is stipulated early
on.

 

[Bartc]

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

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

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

 

[Richard Tobin]

your code seems to have no whitespace in it including newlines.
I can't be bothered to re-layout it to make it readable.

(it could be a problem with my browser of course)

ah. It looks ok if I look at the source. It isn't HTML

It's served with the mime type text/x-csrc. If your browser
treats that as HTML, it does indeed have a problem.

(My browser sensibly opens it in emacs.)

-- Richard

 

[Ertugrul Söylemez]

[...]

Yes, the latter three solutions are not standard C, but I pointed this
out in the article. Implementing closures without this GCC extension is
near to impossible without implementing full garbage collection and some
notion of 'thunks'. About the blog entry starting, vippstar, you're
right. I adjusted it.

Thank you all for your comments.


Greets,
Ertugrul.

 

[Ertugrul Söylemez]

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

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

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.


Greets,
Ertugrul.

 

[vippstar]

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]

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

At most, your original message classifies as spam.

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

 

[Ertugrul Söylemez]

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

No, no, I added this later in response to vippstar's comment, and I
pointed this out here. Sorry for the confusion.


Greets,
Ertugrul.

 

[s0suk3]

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]

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?

[...]

 

[s0suk3]

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.

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.

 

[s0suk3]

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





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

 

[s0suk3]

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]

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.