Comment by munificent | Hacker News Reader

Comment by munificent | Hacker News Reader

Parent Full thread

> My point is that the concepts "having a datatype, that stores an address" and "reading (typed) data stored at a specific address"

They are different things, but C's syntax was deliberately designed to imply the former from the latter. "Declaration reflects use" is the term they used for it.

The idea is that in something like:

    int *i;

You don't read it like, "Declare a variable 'i' whose type is 'int star', which is a pointer to an int". You read it like "declare variable 'i' whose type is such that taking 'star i' (i.e. doing a dereference) would give you an int". The type in this case is a pointer to an int.

This is always why function pointer syntax is so totally bizarre in C.

"Declaration reflects use" was a neat idea, but I think it practice it ended up causing more confusion than it solved. At the time, maybe they thought users would be tripped up by compound type expressions and thought it would help if they focused on the operations performed on the variable being declared.

In practice, it turns out that composed types don't seem to be that hard.

Wow this is really interesting, I did not know that, and it explains their choices. And C's function pointer types are indeed written in a bizarre way.

I definitely think of (int * i) as (i :: Ptr Integer) and (* i) in an expression like 42 + * i as (* :: Ptr Integer -> Integer).

Yeah, as long as we’re mixing notations, it’s really:

    *i :: Integer

From which you can conclude i :: Ptr Integer.

And the dereference operator does have the type you specified, but not in an lvalue—there the operator is really a mixfix one:

    (*_ = _) :: Ptr a -> a -> a

This isn’t specified directly by the standard, but follows from the rules about how an assignment operator must examine the structure of its first operand.

> In practice, it turns out that composed types don't seem to be that hard.

Depends on what you mean by hard. Hard to read or hard to reason about?

* -> * and * -> * -> * are easy to read and reason about, i.e. Int -> Char -> Int. But what about types of types?

(* -> * ) -> * is confusing to reason about IMO. i.e. Applicative Functors:

(<$>) :: Functor f => (a -> b) -> f a -> f b

Not really intuitive at all, the only reason I can understand it is that I know what functors and Monads are.

I'm not talking about higher-kinded types, just type annotations that are more than just a single bare identifier. Stuff like:

    List<int>
    (Some, Tuple, Type)
    Matrix[4][4]
    (Para, Meter) -> ReturnType

I'm probably misunderstanding you, but can I rephrase your comment as saying 'int i is the natural way of declaring a pointer to an int, and not int i'? Because if so, I don't recall that from the K&R (and I've read it front to back several times, not that that means much - I can't even remember if they use int* i or int *i, and I don't have my copy at hand here).

Alas, HN mangled your asterisks.

> I don't recall that from the K&R

I don't recall either, but this Wikipedia mention of "declaration reflects use" cites K&R:

https://en.wikipedia.org/wiki/C_%28programming_language%29#C...

Uh sorry, the first one had the asterisk next to the variable name, the other next to the type.

Yes I agree about the 'declaration reflects use'; what I meant was: does that imply that the declaration should consider the asterisk (the 'make this a pointer' part) to be 'part of', and thus right next to, the variable name or the type?

I'm strongly in the 'type' camp myself, and therefore I think that int *p; is nonsense; only to be used out of necessity when declaring multiple pointer variables on one line. So I'm wondering if 'declaration reflects use' reaffirms that, or contradicts it.

Reply on news.ycombinator.com