Experiment: functional concepts in C

[Kenny McCormack]

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]

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.

Phil

 

[Richard Tobin]

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.

-- Richard

 

[vippstar]

(e-mail address removed) writes:

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.


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

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

 

[dj3vande]

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

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

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

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

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

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


dave

--
Dave Vandervies dj3vande at eskimo dot com

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

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

 

[dj3vande]

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

(e-mail address removed) wrote:

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 told me. I'm unable to find any etiquette or posting rules. This
is a C-related topic. The group name suggests it's on-topic.

For etiquette and posting rules,
<http://www.clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
is probably a good place to start.
(It may or may not be mentioned somewhere there, but a thick skin and a
willingness to learn are both pretty much essential.)


(It is rather unfortunate that most of the comments you got were on the
parts of your post that used GCC extensions; there's an interesting and
on-topic discussion hiding in the parts of your post that are
restricted to standard C.)


dave

--
Dave Vandervies dj3vande at eskimo dot com

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

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

 

[Richard Tobin]

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

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

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

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

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

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

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

-- Richard

 

[CBFalconer]

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.

 

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

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]

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?


Greets,
Ertugrul.

 

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

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.


Greets,
Ertugrul.

 

[dj3vande]

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?

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.

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

 

[Aatu Koskensilta]

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.

 

[Stefan Ram]

I thought it would be funny to try to bring functional
concepts into the C language.

To me, a lack of automatic memory management makes
functional programming difficult in C.

How does one usually deal with the following problem?

A function returns a value that is passed to another
function, say

print( read() )

. Now, one would like to see it this way that the value
is created by »read« and consumed by »print«.

When the size and structure of the value is dynamic, »read«
will allocate parts of the value.

So, when »print« is »consuming« the value, it seems
natural for »print« to call »free« on this value later.

But there, the problems start:

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

One might work out a set of rules to deal with all this,
but I believe programming is much more complicate this way.

I believe some people have a concept of »ownership« of
objects with allocated storage duration that might be
passed or not be passed with those objects. But we do not
have common guidelines in C for this ownership transfer?

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.

 

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

 

[Stefan Ram]

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.