From: Michael Wojcik on
Charles Richmond wrote:
> A "thunk" was *and* is a method for implementing "call by name". But a
> compiler providing "thunks" has *not* been written for some time now.

That's rather dubious.

We don't know that no one has written a compiler that provides
ALGOL-style thunks recently. To demonstrate that you'd have to prove a

If we relax the definition to allow named as well as anonymous
functions, then someone could argue that get-accessors for properties
are thunks, and those are quite common in modern languages.

Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
From: Michael Wojcik on
(see below) wrote:
> On 24/02/2010 20:37, in article hm6fbd68gp(a), "Michael
> Wojcik" <mwojcik(a)> wrote:
>> (see below) wrote:
>>> But bear in mind that in decent languages arrays are
>>> storable values, so a value array parameter gets copied in toto, unlike C.
>> It will be in C if the array is wrapped in a struct. Letting array
> That is passing a struct, not an array.

Yes, that's what I said. Of course, if the array is the only thing in
the struct, then the distinction is purely syntactic.

>> struct (and not the misnamed "typedef") is C's mechanism for creating
>> new types and ADTs, so if you want a pass-by-value array in C, the
>> correct thing to do is to put it in a struct.
> Yes. Preposterous, isn't it?

Other than the name of the keyword struct, no, it seems pretty
reasonable to me. Parameters should be primitives or ADTs.

Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
From: Michael Wojcik on
glen herrmannsfeldt wrote:
> In comp.arch.fpga Charles Richmond <frizzle(a)> wrote:
> (snip)
>> The dimensions of arrays *used* to have to be compile time
>> constants. Now they have a type of array declared in a function
>> that can have its size depend on an integer passed into the
>> function. (I forget what they call it... maybe a "dynamic array"
>> or something.)
> Yes, but can you do that for an array in a struct.

No. The size of a struct type must be known at compile time, even in C99.

> If you
> pass it in a function call, and it isn't the last argument, how
> will the called routine know where the other arguments are?

If you *could* do this, that'd be an implementation issue, and outside
the scope of the C language. :-)

(Technically, C says nothing about a stack. A conforming C
implementation could use activation frames that contain XML documents
describing each parameter in detail. It could use an indexed file to
implement the call stack. It could implement calls by generating
subprograms on the fly that get their parameters via pipes. If they
get there on the backs of unicorns ridden by nasal demons, that's OK
with the standard too.)

Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
From: Michael Wojcik on
Ahem A Rivet's Shot wrote:
> No, he's saying that C doesn't really implement an array type, the
> var[offset] syntax is just syntactic sugar for *(var + offset) which is why
> things like 3[x] work the same as x[3] in C.

That's not quite correct. C does implement an array type (or, rather,
an array type qualifier which can be used to implement arrays of any
object type); it's just not first-class.

Array access syntax is syntactic sugar for multiply-add-dereference,
but arrays aren't just syntactic sugar, because array definitions
reserve storage and permit initialization. Also, array and pointer
lvalues are interpreted differently, even in contexts where they
former decays to the latter, which is why an external array
declaration is not equivalent to an external declaration of a pointer
to the same object type.[1]

Array types aren't first-class because when used as formal parameters
they're converted to pointer types, and when used as actual parameters
they decay to a pointer to their first element. This is similar to C's
other second-class type, the function type, which decays to a function
pointer in every context except declaration and definition.

[1] Probably the best treatment of this question is in PvdL's _Expert
C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers
Are NOT the Same!", and chapter 9, "More About Arrays".

Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
From: Michael Wojcik on
Scott Lurndal wrote:
> I've never promoted or suggested that one put an array in a struct
> and pass it by value, I frankly think it would be a stupid thing to
> do in a C program.

Is it a stupid idea, or a good one, in all the languages that support
it? Is this just a special attribute of C?

> I was curious if anyone thought passing an array by value was a
> _good_ idea.

It might be if you want the callee to be able to modify its copy of
the array without affecting the caller's. Just like any other
pass-by-value object.

If the callee would have had to make a copy of the array anyway, why
not let the compiler do the work?

Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University