Experiment: functional concepts in C

[jacob navia]

Rob Kendrick a écrit :

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

Sure, then graphics, network, and whatever are done by loading

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]

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

 

[ld]

  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]

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

 

[Rob Kendrick]

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]

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]

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]

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.

 

[Nick]

Stefan Ram a écrit :

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.

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.

 

[Stefan Ram]

Tat is a bit of a silly argument

It is not an argument at all, just an answer to a question.

A: How old are you?
B: I am twelve years old.
C: That is a bit of a silly argument.

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

Since C (Java, C++, ...) already is a field large enough,
I fulfil these assignments by teaching the language proper
- not any extensions.

The students who would like to learn C (Java, C++, ...) also
would be disappointed when I would use a lot of time to
teach a special extension library that is available only for
some operating systems, or is not wanted where they work and
then NOT teach some parts of the language proper because the
limited time was spend to teach some extension.

Therefore, I am interested to learn about any rules
regarding memory management /that apply when one is using C
without any extensions/.

 

[Stefan Ram]

I fulfil these assignments by teaching the language proper

(including the standard library.)

 

[Ian Collins]

It is not an argument at all, just an answer to a question.

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.

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?

 

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

Tat is a bit of a silly argument, as Jacob points out, gc is just
another library.

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

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

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.

 

[Michael Foukarakis]

Why do you need operator overloading in C? Just use C++ in a C-like way,
and be done with it.

But then again, you still need/want a garbage collector (hail
unmanaged environments, folks!), and the lack of automatic memory
management in C++ is yet another reason operator overloading is less
than useful. The other reason is exceptions - but you're supposed to
write exception-safe code by using RAII, which means all pointers have
to be "smart", and their copying semantics always defined, and then
you run into C++'s unbelievably complex static binding rules, you get
depressed, and silently give up.

In general, metaprogramming is orders of magnitude harder to achieve
in C++ than C, because of severely bloated language constructs and
rules. My advice would be to either a) learn to manage your own damned
memory or b) give up C and start learning a language that was made by
people with a good grasp of memory management (Java's a good one on
that matter).

I'm sure you'll agree that since this is comp.lang.c, nobody will
choose option (b) for the foreseeable future.

 

[jacob navia]

Michael Foukarakis a écrit :

But then again, you still need/want a garbage collector (hail
unmanaged environments, folks!), and the lack of automatic memory
management in C++ is yet another reason operator overloading is less
than useful. The other reason is exceptions - but you're supposed to
write exception-safe code by using RAII, which means all pointers have
to be "smart", and their copying semantics always defined, and then
you run into C++'s unbelievably complex static binding rules, you get
depressed, and silently give up.

In general, metaprogramming is orders of magnitude harder to achieve
in C++ than C, because of severely bloated language constructs and
rules. My advice would be to either a) learn to manage your own damned
memory or b) give up C and start learning a language that was made by
people with a good grasp of memory management (Java's a good one on
that matter).

I'm sure you'll agree that since this is comp.lang.c, nobody will
choose option (b) for the foreseeable future.

There is option (c), that lcc-win proposes: use the garbage collector!
This allows to write overloaded operators that allocate memory for
new constructs without having any memory leaks in temporary expressions.

 

[gwowen]

There is option (c), that lcc-win proposes: use the garbage collector!
This allows to write overloaded operators that allocate memory for
new constructs without having any memory leaks in temporary expressions.

Or use the Boehm garbage collector with almost any C compiler, or use
Boehm with almost any C++ compiler. Those who do not understand
history are condemned to repeat it.

 

[Robert Latest]

There is option (c), that lcc-win proposes: use the garbage collector!
This allows to write overloaded operators that allocate memory for
new constructs without having any memory leaks in temporary expressions.

And your point is...?

If you need a certain functionality in a C program, you have several
options:

1) Link against a third-party library that implements what you need
2) Implement it yourself
3) Switch to a different language that has the feature built-in
4) Invent a C-like language that has the desired features and write
a full-fledged implementation
5) Convince the Standard Committee to have the desired functionality
in the next release of the C Standard

You seem to be hell-bent on options 4) and 5) while ordinary mortals are
perfectly happy with 1) thru 3).

So again, what's your point?

robert