Experiment: functional concepts in C
Ertugrul Söylemez
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.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
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
--
Nick Keighley
vipp...@gmail.com
> 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
--
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 /.
Kenny McCormack
Nick Keighley <nick_keigh...@hotmail.com> wrote:
>On 17 Nov, 11:43, Ertugrul Söylemez <e...@ertes.de> wrote:
>> 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
>
>> 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
Richard Tobin
Nick Keighley <nick_keigh...@hotmail.com> wrote:
>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
--
Please remember to mention me / in tapes you leave behind.
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.
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
>
> > 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.
vipp...@gmail.com
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
> On Nov 17, 1:43 pm, Ertugrul Söylemez <e...@ertes.de> wrote:
>> 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.
--
Aatu Koskensilta (aatu.kos...@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Ertugrul Söylemez
> vipp...@gmail.com writes:
>
> > 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.*"
No, no, I added this later in response to vippstar's comment, and I
pointed this out here. Sorry for the confusion.
s0s...@gmail.com
> 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
> On Nov 17, 7:57 am, vipp...@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"
s0s...@gmail.com
> s0s...@gmail.com writes:
> > On Nov 17, 7:57 am, vipp...@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
redirecting followups.
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.
s0s...@gmail.com
> Since this is no longer relevant to comp.lang.functional, I'm
> redirecting followups.
>
> s0s...@gmail.com writes:
> > On Nov 17, 3:46 pm, Keith Thompson <ks...@mib.org> wrote:
> >> s0s...@gmail.com writes:
> >> > On Nov 17, 7:57 am, vipp...@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
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.
s0s...@gmail.com
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
>> 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.
s0s...@gmail.com
> s0s...@gmail.com writes:
> > On Nov 17, 7:09 pm, Keith Thompson <ks...@mib.org> wrote:
> [...]
> >> 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
> 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
vipp...@gmail.com
> >> 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
Believe me in this: If there is one thing Keith Thompson has lots and
lots of, it is time (on his hands).
s0s...@gmail.com
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
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.
Kenny McCormack
>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.
vipp...@gmail.com
> Nick Keighley <nick_keighley_nos[80]...@hotmail.com> wrote:
> > On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi[81]...@uta.fi> wrote:
>
> > > vipps[82]...@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
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
<vipp...@gmail.com> wrote nothing of value:
<flushed>
You are such a tool...
Keith Thompson
> On Nov 18, 10:25 pm, Ertugrul Söylemez <e...@ertes.de> wrote:
>> Nick Keighley <nick_keighley_nos[80]...@hotmail.com> wrote:
>> > On 17 Nov, 16:17, Aatu Koskensilta <aatu.koskensi[81]...@uta.fi> wrote:
>>
>> > > vipps[82]...@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
>
> 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>
[...]
vipp...@gmail.com
> 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.
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.
>
> 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? 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.
> > 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.
> > 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.
> > 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.
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.
Ertugrul Söylemez
> In article <20081118212...@ertes.de>,
> Ertugrul Söylemez <e...@ertes.de> 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. 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
Phil Carmody
> vipp...@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 /.
Ertugrul Söylemez
> Ertugrul Söylemez <e...@ertes.de> writes:
>
> > 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.
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.
Keith Thompson
> On Nov 19, 1:05 am, Keith Thompson <ks...@mib.org> wrote:
>> vipps...@gmail.com 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?
James Kuyper
> vipp...@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.
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
Ertugrul Söylemez <e...@ertes.de> 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, 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.
Richard Tobin
Keith Thompson <ks...@mib.org> wrote:
>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.
Keith Thompson
> In article <ln63mk2...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>>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.
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.
Kenny McCormack
Richard Tobin <ric...@cogsci.ed.ac.uk> wrote:
>In article <ln63mk2...@nuthaus.mib.org>,
>Keith Thompson <ks...@mib.org> wrote:
>
>>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.
Uh oh. You're in trouble now.
Expect massive flaming to be coming your way, from the likes of
KeithyWeithy and VippyVippy.
FWIW, and I may be wrong, but I thought you *were* one of the regs/butt-buddy
club. Have you had a recent religious-experience/conversion? If so,
praise the lord (I saw the light!)
Phil Carmody
> In article <ln63mk2...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:
>
>>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.
You seem to be conflating the concepts of "extending C", and
"coming up with your own C-like language". Extending C is
changing C, i.e. modifying the standard that defines C.
Richard Tobin
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>You seem to be conflating the concepts of "extending C", and
>"coming up with your own C-like language". Extending C is
>changing C, i.e. modifying the standard that defines C.
I disagree with this, but I think I've expressed my opinion
often enough over the last few years, so we'll just have to
continue disagreeing.
vipp...@gmail.com
> > 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.
dj3v...@csclub.uwaterloo.ca.invalid
Ertugrul SC6ylemez <e...@ertes.de> 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.
>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
dj3v...@csclub.uwaterloo.ca.invalid
In article <20081119014...@ertes.de>,
Ertugrul SC6ylemez <e...@ertes.de> wrote:
>vipp...@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.)
Richard Tobin
<dj3v...@csclub.uwaterloo.ca.invalid> wrote:
>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.
CBFalconer
> Ertugrul SC6ylemez <e...@ertes.de> wrote:
>> vipp...@gmail.com wrote:
>>
>>> Because your message was off-topic. There's another possibility
>>> that some cared, but chosen not to pollute this newsgroup with
>>
>> Being standards-compliant is one thing, simply being counter-
>
> 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
> 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 (aatu.kos...@uta.fi)
"Wovon man nicht sprechen kann, darüber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
Aatu Koskensilta
> 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.
Ertugrul Söylemez
> Ertugrul Söylemez <e...@ertes.de> writes:
>
> > 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.
Haskell's type system gives me the same computational power as Haskell
itself. Maybe I missed something?
Aatu Koskensilta
> 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.
--
Ertugrul Söylemez
> In article <gg1n7n$pf6$1...@rumours.uwaterloo.ca>,
> <dj3v...@csclub.uwaterloo.ca.invalid> wrote:
>
> > 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.
Well, some people think, I wanted to discuss an extension. That was by
no means my intention. I picked up a classic language and tried to take
it to its limits by trying to incorporate functional concepts into it.
That was the experiment.
My conclusion is that without extensions, C is not flexible enough to do
this. Of course, C is a Turing-complete general purpose language, so
there is in theory nothing you couldn't do in C. I showed that this
property is not a feature, but instead simply natural for every general
purpose language. I showed that things, which are very easy to do in
other languages (including imperative languages like Python), is a PITA
to do in C, and this is not related to better library support in other
languages or to the fact that you need to do memory management yourself.
It's really related to the nature of the C language itself.
> I encourage anyone with interesting ideas for C, that aren't specific
> to some particular platform, to discuss them here.
Yes, I agree here, but I like to note that I never proposed additions or
changes to C.
dj3v...@csclub.uwaterloo.ca.invalid
Richard Tobin <ric...@cogsci.ed.ac.uk> wrote:
>In article <gg1n7n$pf6$1...@rumours.uwaterloo.ca>,
> <dj3v...@csclub.uwaterloo.ca.invalid> wrote:
>
>>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
Jon Harrop
> Ertugrul Söylemez <e...@ertes.de> writes:
>> 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.
I think you mean Haskell 98 and he doesn't. Regardless, Haskell 98 is almost
entirely unused today (GHC's extended Haskell is the defacto standard).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Aatu Koskensilta
> Aatu Koskensilta wrote:
>
> > 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.
>
> I think you mean Haskell 98 and he doesn't. Regardless, Haskell 98 is almost
> entirely unused today (GHC's extended Haskell is the defacto standard).
Right. Multi-parameter type classes and functional dependencies in
particular allow us to perform arbitrary computations on the type
level. Such magic has its charm, though the charm is alas not entirely
unlike that of advanced C++ template magic.
We must not lose sight of the fact this discussion is cross-posted in
comp.lang.c, where all discussion absolutely must be limited to what
is standard conforming. Non-standard extensions of Haskell are thus
obviously even more off-topic than standard Haskell.
Also, when setting follow-ups, its a matter of courtesy to include a
note of that in the body of the post.
In closing, just to please the C crowd:
void main()
Paul Rubin
> [1] http://blog.ertes.de/2008/11/obscure-c-from-new-perspective.html
I hereby nomninate you for membership in "evil geniuses for a better
tomorrow". ;-)
Ertugrul Söylemez
> > [1] http://blog.ertes.de/2008/11/obscure-c-from-new-perspective.html
>
> I hereby nomninate you for membership in "evil geniuses for a better
> tomorrow". ;-)
Oh hehe, I almost forgot that piece of code. It's not that evil. I'm
just abusing a highly imperative language for highly functional
stuff. ;)
BTW, I'll refrain from calling that language "C" again, but rather call
it "a C-like language". The last time I made the mistake to call it "C"
got me flamed off in comp.lang.c. =)
Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
Paul Rubin
> A function returns a value that is passed to another
> function, say
>
> print( read() )
I once wrote an embedded lisp interpreter where you'd write
something like
Lisp_value f() {
mark();
...
print (wrap (read()));
...
release ();
}
Basically the interpreter had a stack of values protected from garbage
collection. wrap(...) would push a value onto the stack and return the
same value. mark() would save a "frame pointer" and push the old frame
pointer onto the stack, and release() would pop back to the saved frame
pointer. Throwing an exception would pop the stack back to the frame
pointer saved by the exception handler. So that temporary value
returned by read() would be protected through the dynamic context of
f(), and of course saving any further references would make it reachable
by gc. This really wasn't too bad. If you wanted to use read/print in
a loop you could put the value in a mutable cell in order to avoid
unwanted stack growth, something like:
Lisp_value x = Nil;
wrap_ref(&x);
for (...) {
x = read();
print (x);
}
> - When parts of the argument structure are shared,
> they possibly should not be freed.
>
> - A client of »print« might pass in objects with
> static or automatic storage duration, which
> should not be freed at all.
Well sure, but such sharing would be discovered by a tracing gc.
> In the end, one might invest more time in thinking about
> memory management than about the actual programming problem.
Maybe for a high performance system. The simple-minded thing that I did
was fairly easy to use and worked reliably, though I guess it
may have had some efficiency shortcomings, and couldn't have handled
an evaluation model that allowed (e.g.) saved continuations.
jacob navia
> Ertugrul =?UTF-8?B?U8O2eWxlbWV6?= <e...@ertes.de> writes:
>> I thought it would be funny to try to bring functional
>> concepts into the C language.
>
> functional programming difficult in C.
>
snip...
>
> In the end, one might invest more time in thinking about
> memory management than about the actual programming problem.
>
> So, I believe, this is the real problem, when one tries
> to do functional programming in C.
>
It depends what "C" you are using.
lcc-win proposes a garbage collector in its standard distribution.
All the problems above are solved with a gc
jacob navia
> Paul Rubin <no.e...@nospam.invalid> writes:
>> Well sure, but such sharing would be discovered by a tracing gc.
>
> /not have/ a GC. So I infer that functional programming,
> therefore, is difficult or nearly impossible (beyond a
> certain level of complexity) in C.
>
I have been proposing a garbage collector forC since 2004. The
garbage collector is a part of thestandard lcc-win distribution.
The same collector is available for most workstation environments.
jacob
jacob navia
> ISO/IEC 9899:1999 (E).
>
The gc is a library, like a graphics library or a network library.
Are you implying that you can't do network programming in C because "network" doesn't appear in the
standard?
The standard doesn't speak a word about graphics either. You can't do graphics in C then?
Your viewpoint of limiting C to what is explicitly said in the standard is just another way of the old:
"You can't do anything serious in C"
and then (implicitly)
"Use C++" or whatever
ld
> Paul Rubin <no.em...@nospam.invalid> writes:
> >Well sure, but such sharing would be discovered by a tracing gc.
>
> /not have/ a GC. So I infer that functional programming,
> therefore, is difficult or nearly impossible (beyond a
> certain level of complexity) in C.
I have already answered to this kind of question recently. You don't
need a GC, just a richer set of ownership rules. In the C Object
System (100% C lib) I use new, delete and autoDelete (delayed delete)
for object creation/destruction and retain, release and autoRelease
(delayed release) for object ownership. The reason why there is a
difference between creation and ownership comes from the possibility
to convert a posteriori an existing code back and forth to something
semi-gc where all new do an autoDelete and no delete are required from
the user (and obviously the rule does not apply to retain/release life-
cycle). Since I have adopted these rules with _local_ balance (new <->
delete/autoDelete, retain <-> release/autoRelease), I don't have
anymore memory leaks.
Once you have ownership, you need few more concepts to be able to
program in C as you would in Lisp (and beyond). Another (big) step is
the implementation of generic closures (high order functions and high
order messages) and there you need the full expressive power of COS...
cheers,
ld.
Keith Thompson
[...]
> Your viewpoint of limiting C to what is explicitly said in the
> standard is just another way of the old:
>
> "You can't do anything serious in C"
>
> and then (implicitly)
>
> "Use C++" or whatever
You wouldn't be waging a campaign against C99, would you?
--
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"
ld
> ld <laurent.den...@gmail.com> writes:
> >I have already answered to this kind of question recently.
> >You don't need a GC, just a richer set of ownership rules.
>
I mentioned the list of messages in my post. You can find the semantic
explanation in the paper
http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos-draft-dls09.pdf
or in the slides
http://cos.cvs.sourceforge.net/viewvc/cos/doc/slides-cos.pdf
You can also read the doc on ownership and memory management from the
Apple dev center since they use autoRelease pools for more than a
decade in Cocoa (and still nowadays despite of the introduction of the
GC with Objective-C 2.0).
The code can be browsed on the cvs repository (things in CosBase are
stable but on CosStd and CosExt are unstable).
cheers,
ld.
Paul Rubin
>>Well sure, but such sharing would be discovered by a tracing gc.
>
> /not have/ a GC. So I infer that functional programming,
> therefore, is difficult or nearly impossible (beyond a
> certain level of complexity) in C.
The functional programming would only work on a certain class of objects
within the C program, that are collected by an internal gc. Sometimes
what this leads to is called "Greenspun's Tenth Law" ;-).
There are also so-called conservative gc's for C and C++ (that treat all
data words as possible heap pointers) but at least as a matter of
principle, those can be considered unsatisfying.
Anyway I came late into this thread, but I don't think anyone was
proposing to embed Haskell as cpp macros or anything like that ;-). The
idea is just that it's possible for one's C programs to be influenced by
functional style, and to implement some nontrivial functional constructs
through a few coding disciplines supported by some utility functions.
BGB / cr88192
"Paul Rubin" <no.e...@nospam.invalid> wrote in message
news:7x7hr5v...@ruckus.brouhaha.com...
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>>Well sure, but such sharing would be discovered by a tracing gc.
>>
>> Yes, the whole point of my post is that C usually does
>> /not have/ a GC. So I infer that functional programming,
>> therefore, is difficult or nearly impossible (beyond a
>> certain level of complexity) in C.
>
> The functional programming would only work on a certain class of objects
> within the C program, that are collected by an internal gc. Sometimes
> what this leads to is called "Greenspun's Tenth Law" ;-).
>
> There are also so-called conservative gc's for C and C++ (that treat all
> data words as possible heap pointers) but at least as a matter of
> principle, those can be considered unsatisfying.
>
yeah.
they can tend to be slow and unreliable, and can be rather ill-behaved for
certain usage patterns...
ideally, it would be preferable to avoid a conservative GC (and instead use
precise GC), but alas, for C, this leads to far too much hassle/overhead
(having to mess with registering and unregistering roots, ...).
the JVM seem to use an alternate strategy for JNI:
references are "local" or "global", where local references have a
constrained lifespan (and may be destroyed after the JNI method returns).
for C, I have ended up developing a sort of pseudo-GC strategy (used mostly
in my compiler internals), where the allocator just sort of naively
allocates from sliding buffers, which may be destroyed/reused when done.
any data to preserved then is, manually, copied elsewhere (although, more
often, it is just discarded, with the result having been "transcribed" into
a different form).
if made automatic, I guess this would be a sort of crude copy-collector.
OTOH, this could be made into a "semi-automatic" API, whereby one could
instruct the system to copy the data, but it goes about the actual logistics
of doing so (likely with the help of user-registered "copy" handlers). (in
the "manual" strategy, usually type-specific data-copying functions are
written for any data needing to be copied...).
but, anyways, the main advantage of this strategy is that it does well for
the usage patterns which seem to pop up in my compiler: producing large
volumes of objects in short bursts, which almost all turn into garbage.
this particular usage-cases tend to kill my main GC (which tends to work
best with a gradual accumulation of garbage at a relatively low rate).
> Anyway I came late into this thread, but I don't think anyone was
> proposing to embed Haskell as cpp macros or anything like that ;-). The
> idea is just that it's possible for one's C programs to be influenced by
> functional style, and to implement some nontrivial functional constructs
> through a few coding disciplines supported by some utility functions.
yeah.
Haskell mixed in with C would be nasty...
well, of note:
I do have support for a "closure" facility in my case (via an API call).
however, I haven't really exactly used it much (except in a few edge cases
where it was needed), and generally it would require manually "capturing"
the bindings in the form of a heap-allocated struct (or similar).
so, in general, it has neither the grace nor the elegance of the FP
analogue.
it tends to be actually more usable just to pass an object with the funtion
embedded in a function pointer (even though) you can't simply call this as
if it were a function pointer. this tends actually to be a lot more
convinient, as well as being faster (via lack of crufty "transfer thunks")
and typically generating less garbage...
jacob navia
>
> C does not have a garbage collector.
>
Many things are left for system libraries, like graphics, network,
garbage collectors, and many other things like (for instance)
directory access, thread management, multiprocessing etc.
All of this can be done in C if you do not arbitrarily restrict
the language to the minimal subset as you are trying to do here.
I have promoted and distributed a garbage collector for C since
several years. People like you (and the other "regs") have always
fought this, so your attitude is not surprising.
What is surprising is that now you refuse even to acknowledge that
a widely distributed implementation of gc exists, and it is used.
Your argument that "it is not part of the text of the standard"
is just ridiculous. The "C" of the standard is not even able to
use a directory effectively and there is NO serious software in C
that uses that minimal subset.
With your attitude there is no software written in C.
jacob navia
>
> http://en.wikipedia.org/wiki/Reference_counting#COM
>
> I believe having read that problems with reference counting
> are a reason, why COM does not get so much support from
> Microsoft anymore, while many major Windows applications
> still use COM. I can not find a direct source for this,
> but the following goes into this direction:
>
> �ｿｽThe messiness of COM (Component Object Model) is
> removed. (...) .NET addresses many of the shortfalls of
> COM, including (...) reference counting (...)�ｿｽ
>
> �ｿｽThe developer controls the lifetime of a COM object.
> AddRef and Release live in infamy. They are methods of
> the IUnknown interface and control the persistence of
> the COM object. If implemented incorrectly, a COM object
> could be released prematurely or, conversely, never be
> released and be the source of memory leaks. The .NET
> memory manager, appropriately named the Garbage
> Collector, is responsible for managing component
> lifetimes for the application - no more AddRef and Release.�ｿｽ
>
> http://www.codeguru.com/csharp/sample_chapter/article.php/c8245/
>
That is why lcc-win proposes a garbage collector, because is the only
sensible solution.
Obviously your agenda is just to demonstrate that C is unable to do
anything. Granted. Go ahead. But you aren't confusing anyone.
gwowen
>
> That is why lcc-win proposes a garbage collector, because is the only
> sensible solution.
And what language do you write your garbage collector in? ;)
Garbage collectors clearly have their place, and an (optional) one
would be a boon to any language that doesn't have one built in. But
there are perfectly good alternatives, besides manual reference
counting. The fact that COM screwed up reference counting, doesn't
mean that reference counting is a non-starter. In many circumstances
a smart pointer is preferable to GC, as it gives a programmer greater
control over deterministic destruction (RAII works a lot better on
managing mutexes than GC, for example -- lock()/unlock() cares about
timing in a way malloc()/free() doesn't). In many circumstance, GC is
preferable to smart pointers, as the programmer doesn't care about
those things.
As ever: There is no silver bullet.
jacob navia
> On Jan 26, 6:37 am, jacob navia <ja...@spamsink.net> wrote:
>> That is why lcc-win proposes a garbage collector, because is the only
>> sensible solution.
>
> And what language do you write your garbage collector in? ;)
>
Boehm's GC is written in plain C. Yes, you can write a GC in C. There
are a few bits and pieces done in assembly, but for the most part
everything is in C.
> Garbage collectors clearly have their place, and an (optional) one
> would be a boon to any language that doesn't have one built in.
True
> But
> there are perfectly good alternatives, besides manual reference
> counting. The fact that COM screwed up reference counting, doesn't
> mean that reference counting is a non-starter.
COM did not "screw it". Reference counting has its drawbacks, that's all.
> In many circumstances
> a smart pointer is preferable to GC, as it gives a programmer greater
> control over deterministic destruction (RAII works a lot better on
> managing mutexes than GC, for example -- lock()/unlock() cares about
> timing in a way malloc()/free() doesn't).
That could be done in C if we had operator overloading, something I have
been trying to promote for years.
> In many circumstance, GC is
> preferable to smart pointers, as the programmer doesn't care about
> those things.
>
Yes.
> As ever: There is no silver bullet.
True. GC has its drawbacks too. For instance if you forget a reference to some
huge object you create an enormous memory leak since the collector can't
free it. Finding out where is that reference can be an incredibly complex
task.
Note that that is a problem for ALL GC's, java, lisp whatever.
Nick Keighley
> gwowen a écrit :
<snip>
> > As ever: There is no silver bullet.
>
> True. GC has its drawbacks too. For instance if you forget a reference to some
> huge object you create an enormous memory leak since the collector can't
> free it. Finding out where is that reference can be an incredibly complex
> task.
>
> Note that that is a problem for ALL GC's, java, lisp whatever.
it has to be, otherwise the garbage collector would have to read your
mind. "ah, I see he has a reference to GiganticDataStructure that he
meant to get rid of. I'll just null it out and re-run gc".
gwowen
> > But
> > there are perfectly good alternatives, besides manual reference
> > counting. The fact that COM screwed up reference counting, doesn't
> > mean that reference counting is a non-starter.
>
> COM did not "screw it". Reference counting has its drawbacks, that's all.
The IUnknown AddRef() and Release() interface is incredibly brittle
and error prone. Making a programmer manage all the references by
hand is a bad idea. AddRef/Release is to reference counting as malloc
()/free() is to memory. It's not consistent to repeatedly recommend
GC for memory, without spotting that the IUnknown is prone to the same
problem.
As the background mechanism, reference counting is fine -- just like
heap allocation is fine. It is forcing the programmer to manage it by
hand that can frequently lead to errors. It's actually probably worse
for interfaces, because most programmers have an idea who the "owner"
of some memory is, which, in my experience, is not necessarily the
case with Interfaces. Also, leaked memory is easily cleaned up at
process exit time -- that's also not necessarily the case for non-
memory resources.
Rob Kendrick
jacob navia <ja...@nospam.org> wrote:
> Your argument that "it is not part of the text of the standard"
> is just ridiculous. The "C" of the standard is not even able to
> use a directory effectively and there is NO serious software in C
> that uses that minimal subset.
You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
piece of software; one of the fastest scripting languages around. And
written entirely in ANSI C with only a handful of concessions (such as
dlopen to allow for extensions).
It's quite easy to write great, reusable, reliable software components
in ANSI C without reaching for OS-specific extensions.
B.
Michael Foukarakis
> gwowen a écrit :
>
> > On Jan 26, 6:37 am, jacob navia <ja...@spamsink.net> wrote:
> >> That is why lcc-win proposes a garbage collector, because is the only
> >> sensible solution.
>
> > And what language do you write your garbage collector in? ;)
>
> Boehm's GC is written in plain C. Yes, you can write a GC in C. There
> are a few bits and pieces done in assembly, but for the most part
> everything is in C.
>
> > Garbage collectors clearly have their place, and an (optional) one
> > would be a boon to any language that doesn't have one built in.
>
> True
>
> > But
> > there are perfectly good alternatives, besides manual reference
> > counting. The fact that COM screwed up reference counting, doesn't
> > mean that reference counting is a non-starter.
>
> COM did not "screw it". Reference counting has its drawbacks, that's all.
It's not in any way convenient for the programmer. The fact that all
parties involved have to consistently count references is as error
prone as simply enforcing the proper use of malloc() & free() and
equivalents, and it has led to notoriously hard to find bugs. Even
Microsoft admitted that COM did, in fact, "screw it" which is why they
favoured tracing GC in .NET, so there's no point in trying to defend
its shortcomings. My personal belief is that *manual* reference
counting is still a bad idea - why do it when you can completely
decouple it from the programmer by providing him with a decent memory
manager? That way, everybody wins. And if you can't do that, just let
the poor guy manage malloc() & free(), why burden him/her with a
crippled interface?
> > In many circumstances
> > a smart pointer is preferable to GC, as it gives a programmer greater
> > control over deterministic destruction (RAII works a lot better on
> > managing mutexes than GC, for example -- lock()/unlock() cares about
> > timing in a way malloc()/free() doesn't).
>
> That could be done in C if we had operator overloading, something I have
> been trying to promote for years.
Operator overloading and lots of preprocessor tricks, correct?
> > As ever: There is no silver bullet.
>
> True. GC has its drawbacks too. For instance if you forget a reference to some
> huge object you create an enormous memory leak since the collector can't
> free it. Finding out where is that reference can be an incredibly complex
> task.
This can be a problem with smart pointers as well. Typical example:
shared_ptr between an automatic pointer and a member of a singleton
(seen it a thousand times..).
jacob navia
> On Tue, 26 Jan 2010 07:26:49 +0100
> jacob navia <ja...@nospam.org> wrote:
>
>> Your argument that "it is not part of the text of the standard"
>> is just ridiculous. The "C" of the standard is not even able to
>> use a directory effectively and there is NO serious software in C
>> that uses that minimal subset.
>
> You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> piece of software; one of the fastest scripting languages around. And
> written entirely in ANSI C with only a handful of concessions (such as
> dlopen to allow for extensions).
>
AN EXTERNAL LIBRARY
That is the same as with C. You link in C statically (or dynamically)
but you can't do any network/graphics/dynamic loading/you-name-it
without having to use external libraries what was my point!
> It's quite easy to write great, reusable, reliable software components
> in ANSI C without reaching for OS-specific extensions.
>
> B.
Of course. Then you use dlopen to load all the OS-specific components!
You have just confirmed what I said:
Using ONLY the minimum mentioned in the standard you can't use directories
graphics, network and many other things that are essential today.
The standard is just a common minimum and a program that uses standard
libraries is written in C and uses extensions like (for instance) a GC.
Richard Tobin
jacob navia <ja...@jspamsink.org> wrote:
>That is why lcc-win proposes a garbage collector, because is the only
>sensible solution.
Is your garbage collector adequate for heavily recursive
functional-style programming? You probably also need good
tail-recursion optimisation. TRO may help garbage collection
if it removes stack frames that would otherwise "hold on" to
garbage.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield
> Stefan Ram a �crit :
>>
>> C does not have a garbage collector.
>>
>
> Many things are left for system libraries, like graphics, network,
> garbage collectors, and many other things like (for instance)
> directory access, thread management, multiprocessing etc.
Right.
> All of this can be done in C if you do not arbitrarily restrict
> the language to the minimal subset as you are trying to do here.
Sure. Nevertheless, if one does not restrict oneself in that way, one
gives up a certain degree of portability - the fewer restrictions one
places on what third-party features one accepts, the less portable one's
code. It seems that you don't place a high value on portability, since
you've basically selected one platform (possibly two) and stuck to it
(them). Not everybody has that freedom.
> I have promoted and distributed a garbage collector for C since
> several years. People like you (and the other "regs") have always
> fought this, so your attitude is not surprising.
Nobody has fought your distribution of a GC. It is true that people in
this newsgroup have objected to your using it as a dumping ground for
advertisements. But if you were to promote it in appropriate channels,
e.g. your web site, nobody could reasonably object to that.
> What is surprising is that now you refuse even to acknowledge that
> a widely distributed implementation of gc exists, and it is used.
He isn't refusing to acknowledge that garbage collectors exist. He's
arguing that C doesn't have one. It doesn't. *You* have one. Your
implementation may well provide one, as an extension. But C itself does
not have one.
> Your argument that "it is not part of the text of the standard"
> is just ridiculous.
No, it's a rational stance.
> The "C" of the standard is not even able to
> use a directory effectively
Perhaps you're not aware that directories are not a universal feature of
filesystems. C has to be able to work on systems where directories
either don't exist at all, or work very differently to what you're used
to. (I can think of at least three, two of which I would call major
commercial systems. The third is Pick, and failing to acknowledge it as
major may be a touch unfair on it. There are probably more than I can
bring to mind, of course.)
> and there is NO serious software in C that uses that minimal subset.
If you define "serious software" as "software that uses extensions",
you're right. It's hard to see in what other way you could be right. I
write pretty serious software in C pretty often, and I write it in that
subset you so disdain. When I do need extensions, which is rare but not
unheard of, they go into their own module in their own wrapper, so that
I can easily find the bits I need to re-write for each new system.
> With your attitude there is no software written in C.
Your reliance on extensions is not an imposition on other people's
ability to cope without them, or to abstract them into isolated modules.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
ld
> ld <laurent.den...@gmail.com> writes:
> >>>You don't need a GC, just a richer set of ownership rules.
> >>Yes, please give me the URI of this set!
>
> This seems to be a library that either uses garbage collection
> or user aided reference counting.
Not a gc but a "kind of reference counting"
There is a difference between reference counting and ownership. The
latter rely on "extended" reference counting to manage automatic
object and static object and should not retain an object referenced
but not owned: e.g. graph's nodes are not retained while graph's
elements are retained. So in practice correct management ownership
means that you stick to DAGs, yes. But there is languages (e.g.
Haskell) where you can only create DAGs, and it doesn't limit their
capabilities.
> I was hoping for ownership rules for plain C objects or
> linked C data structures.
I don't see the problem to turn structure into objects (in the OO
sens).
> C does not have a garbage collector.
Boehm gc. But GCs have other problems:
- memory overhead
- non deterministic finalization
- hidden change in algorithm complexity
- tuned for some "classical use" but could be inefficient for
unexpected cases
- ...
> A reference counter is an additional subobject that must be
> added to all objects to be managed in this way.
Right. And as far you have to manage objects (in the OO sens), you
will have to do it in one way or another, this is inherent to objects
with dynamic lifetime. As you will have to bound objects to their
class in OO class-based model.
> This URI list rules for reference counting with COM (using
> "AddRef" and "Release"):
>
> http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting
>
> And this URI lists some of the problems with reference counting:
>
> http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting_2
But ownership means no cycle. Two objects cannot _own_ each other. If
you fall into such case, it's probably because the design (or the
understanting of ownership) is incorrect and need to lifting (e.g.
introduce a manager for these objects). Brute reference counting is
dangerous, yes, but ownership isn't. Unfortunately, many programmers
don't make the difference.
> Another URI:
>
> "Bugs caused by incorrect reference counting in COM
> systems are notoriously hard to resolve"
My rules are _local_ (same scope) so I never have incorrect reference
counting.
a+, ld.
ld
> Anyway I came late into this thread,
we all came late, the thread started in 2008 ;-)
> but I don't think anyone was
> proposing to embed Haskell as cpp macros or anything like that ;-).
I did something close with COS because once you have implemented loop
in cpp, you get a functional language (with gc) ;-) So I get things
like map, foldl, foldr, filter, etc...
See chaos-pp on sourceforge for a serious lib like this, mine is
focused (and limited) for COS.
> The
> idea is just that it's possible for one's C programs to be influenced by
> functional style, and to implement some nontrivial functional constructs
> through a few coding disciplines supported by some utility functions.
Right. The library of COS is mainly written in a functional style
inspired by Haskell. For example, you can look at
http://cos.cvs.sourceforge.net/viewvc/cos/CosStd/include/cos/gen/algorithm.h?view=markup
where each generic function (in the CLOS sens) with a 'fun' parameter
expect a functor (closure).
cheers,
ld.
bartc
"Rob Kendrick" <nn...@rjek.com> wrote in message
news:20100126094...@trite.i.flarn.net.i.flarn.net...
> On Tue, 26 Jan 2010 07:26:49 +0100
> jacob navia <ja...@nospam.org> wrote:
>
>> Your argument that "it is not part of the text of the standard"
>> is just ridiculous. The "C" of the standard is not even able to
>> use a directory effectively and there is NO serious software in C
>> that uses that minimal subset.
>
> You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> piece of software; one of the fastest scripting languages around.
Is it? Just downloaded a copy (5.1.4); only two of the examples provided had
any meaning to me:
FIB.LUA: Fib(36): about 14 seconds (Python: 16 secs, Ruby 8 secs; my own
interpreted language: 1.5 secs)
FACTORIAL.LUA: modified to calculate 12! ten million times: ~250 secs. After
getting rid of some fancy function handling (under the comment 'function
closures are powerful'), and using straight recursion: ~25 secs (my lang:
2.6 secs).
Perhaps it's weak on recursion, but then: "i=0; while i<100000000 do i=i+1
end " took ~12 secs (my lang: 0.6 secs)
Just a brief test of course and perhaps I missed out some essential switch
such as /FAST...(I've heard of something called LuaJIT, I doubt this is it
though)
> And
> written entirely in ANSI C with only a handful of concessions (such as
> dlopen to allow for extensions).
I don't use straight ANSI C...
> It's quite easy to write great, reusable, reliable software components
> in ANSI C without reaching for OS-specific extensions.
For interpreter projects, which are really speed critical, I just use
whatever is necessary for performance.
If Lua likes to distribute itself as source code, then I can see some of the
point of restricting itself to a language subset which will compile anywhere
(but I used a binary download, where there shouldn't be a problem with
tweaking to each platform).
--
Bartc
Rob Kendrick
"bartc" <ba...@freeuk.com> wrote:
>
> "Rob Kendrick" <nn...@rjek.com> wrote in message
> news:20100126094...@trite.i.flarn.net.i.flarn.net...
> > On Tue, 26 Jan 2010 07:26:49 +0100
> > jacob navia <ja...@nospam.org> wrote:
> >
> >> Your argument that "it is not part of the text of the standard"
> >> is just ridiculous. The "C" of the standard is not even able to
> >> use a directory effectively and there is NO serious software in C
> >> that uses that minimal subset.
> >
> > You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> > piece of software; one of the fastest scripting languages around.
>
> Is it? Just downloaded a copy (5.1.4); only two of the examples
> provided had any meaning to me:
The included things are tests, and not optimal examples. Try the
examples on the alioth shootout:
http://shootout.alioth.debian.org/
Note the comparisons to Python and Ruby. The mandelbrot one's
especially amusing: the single-threaded Lua implementation is faster
than the multi-threaded Perl one that's using four CPUs.
B.
Ian Collins
>
>>> In many circumstances
>>> a smart pointer is preferable to GC, as it gives a programmer greater
>>> control over deterministic destruction (RAII works a lot better on
>>> managing mutexes than GC, for example -- lock()/unlock() cares about
>>> timing in a way malloc()/free() doesn't).
>> That could be done in C if we had operator overloading, something I have
>> been trying to promote for years.
>
> Operator overloading and lots of preprocessor tricks, correct?
Operator overloading and constructors/destructors, which are additions
that Jacob has vehemently opposed in the past. Smart pointers and RAII
in general can't work without them. Even with preprocessor tricks, RAII
can't be done in C.
--
Ian Collins
Ian Collins
>
> lcc-win proposes a garbage collector in its standard distribution.
> All the problems above are solved with a gc
As they say on the BBC, other distributions with a garbage collector are
available. The Boehm GC has been used on many platforms. It is
distributed with Sun Studio for example.
I don't see other platforms actively promoting it like you do, perhaps
they should? It can be a very useful diagnostic tool as well as a
collector.
--
Ian Collins
Ian Collins
> jacob navia <ja...@nospam.org> writes:
>> It depends what "C" you are using.
>
> I thought about something along the lines of
> ISO/IEC 9899:1999 (E).
>
Tat is a bit of a silly argument, as Jacob points out, gc is just
another library.
--
Ian Collins
Nick
> Stefan Ram a écrit :
You can do almost everything for a fully featured web application in C.
Even graphics entirely in ISO C (because you generate the graphic file
using standard bit and file handling, and leave it to the browser to
render).
My web site runs on a C scripting language. It does use some
non-standard libraries, but only in fairly recent incarnations (where I
want some database and other functionality).
Without user editing, you can do everything at the website below in ISO
C. You read from stdin or getenv, you write to stdout. You access your
files with fopen etc. What more do you need.
Oh, and the scripting language uses reference counting, not garbage
collection. You can do that in standard C as well.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Ian Collins
> Ian Collins <ian-...@hotmail.com> writes:
>>> I thought about something along the lines of
>>> ISO/IEC 9899:1999 (E).
>> Tat is a bit of a silly argument
>
Oh come on now, Jacob pointed out that GC is an appropriate tool to use
when implementing functional concepts in C. It is in the same way as
sockets are an appropriate tool if someone wanted to write a
client/server application in C.
>> , as Jacob points out, gc is just another library.
>
> I have teaching assignments usually defined by a certain
> language, for example �to teach C (Java, C++, ...)� either
> for beginners or for students who already were in the
> beginners class.
So you have a set of requirement for your assignment and you stick to
them. That doesn't negate the fact that GC is an appropriate tool to
use when implementing functional concepts in C. What if your assignment
were to teach functional concepts in C?
--
Ian Collins
Robert Latest
> That could be done in C if we had operator overloading, something I have
> been trying to promote for years.
Why do you need operator overloading in C? Just use C++ in a C-like way,
and be done with it.
robert
Kaz Kylheku
... and, more or less, one that you don't even call!!!
Code written to ISO/IEC 9899 can leak memory, without invoking undefined
behavior, and we can patch that leak by /externally/ imposing garbage
collection.
Flash Gordon
Unless you have one of the corner cases where garbage collection breaks
a program.
Also, some types of GC library are unacceptable for some types of
application because they impose overheads at a time outside your
control, potentially when you are in a time critical portion of the code.
I can see it being extremely useful in some situations and problematic
in others.
--
Flash Gordon