## Can function pointers be "fixed"

Whilst thinking on the subject of language design, specifically lowish-level (C++ level), I came up against the seeming brick wall of function pointers. Now, whilst function declarations can be modified to allow for such niceties as closures, coroutines and multiple return values, function pointers, it seems, can never be harnessed for the power of good. The reason for this seems to be the way that functions are declared in C-type languages, i.e. completely differently from data and, I might add, rightly so. I much prefer:
 int doIt(int a) CODE 
or even something along the lines of:
 int,int iHandle:swapInt(int a, int b) CODE 
as a more elaborate coroutine with a multiple returns and a handle to its own instance, compared to more object based delcarations:

 (int)function(int) doIt = new (int)function(int) CODE 
(note: this is just an example in a sugarless but statically typed language, I'm sure there are nicer ways of having OOP function declaration)
which, in any case also brings up the question of integrating return types into the declaration (hint: Pascal is also very ugly)
However, even for the modest simple function, the C function pointer of
 int(*fp)(int); 

is just completely whack compared to the rest of the data declarations.
 int a; char c; int(*fp)(int); 
(spot the odd one out)

So my question is this, has anyone encountered a statically-typed function/funcpointer declaration system that is at all elegant?

-DNQ

## Comment viewing options

### Seems to me...

It seems to me that you're stuck thinking at the level of syntax, and in particular the rather awful syntax of C function pointers. Your question seems to be: is there a better syntax than C's for function types? The answer is absolutely yes. I would look at Haskell or any of the ML languages. For a curly-brace language with similar function type syntax, see Scala.

### Confusing function pointers and function labels

It appears to me that you are confusing function pointers with function labels here. Or more precisely, that the absence of any type distinction between procedure objects and procedure labels in higher-order languages makes this whole issue moderately confusing.

In response to Matt, this is not merely a syntax issue. There is an expressiveness issue here that Haskell, ML, and BitC all need to address. The problem is that the C declaration:

int(* const fp)(int);

defines a non-mutable location. I'm sure that there is an external declaration hack available in practice, but core ML cannot express this. Haskell, for its part, cannot express:

int(* fp)(int);

BitC can handle either, but we did not find it necessary to make the declaration of labels v. procedures awkwardly distinct in BitC. Any mutable value of (fn...) type gets a location and is really a pointer. An immutable function pointer (the second case) can be written explicitly.

So yes, function pointers can be fixed. In addition to the beneficial effects on syntax this helps to limit inbreeding.

### if I understand what you're

if I understand what you're suggesting, why not just include refs as part of the type?

a -> b -> c,

you could specify a mixture:

a -> ref (b -> c)

I think we'd be subject to some monomorphic types at that point, however, and this might be even better in Haskell as impurity impacting resolving funcs would be clearer too.

 (fn (int int) (int int int)) 
 (fn (int int) (pair int (pair int int)))