Hacker News Reader

Comment by billfruit | Hacker News Reader

But why does it have to be that way though, can't the compiler scan the rest of the code/files and see if a defenition/declaration is present somewhere?

There is no such requirement of a declaration before first call in Java for example?

View on HN

It's because the C compiler was designed to be single pass, so as to be speedy and require less memory on the systems of it's time.

I suppose you could just create a ".d" file standard that doesn't have that requirement but processes into a ".c" file that has the necessary prototypes. You could probably also auto-insert all the #if'n'def nonsense automatically and skip it in the ".d" files.

Kind of like how the JavaScript dudes all use this ".ts" stuff now for convenience that processes into ".js"

Just to be a little picky, but if you want “convenient” then just stick with pure JS - it’s overly forgiving and simple. TypeScript is lovely and I much prefer it over JS, but having to type _everything_ is far from convenient imo

Isn't Typescript gradually typed?

It is! I’ve been working in an environment that essentially requires us to type as we code (rules against using the “any” and “unknown” types) that in just used to them being enforced now lol. So I suppose my point is moot, as the tediousness isn’t forced by the language necessarily.

It's also considered by many to be an antipattern to add a type that is otherwise inferred. For a trivial example,

let x: number = 6;

You should instead allow the compiler to infer where it can and do

let x = 6;

Inference doesn't work across function calls like it does (did?) in Flow, which is a good thing, so those always need to be typed.

If you wanted the type of x to be 6 instead of number, you would use

let x = 6 as const;

The Arduino build system does this (preprocesses your source code to pull out prototypes and put them at the top). To make things easier for beginners.

Like early Pascal compilers, or maybe all of them. Don't know about the latter case (all).

Is that a requirement that is relevant presently? I would say not so much. Do modern C compilers also make only a single pass?

Yes. Gcc throws errors like hell with c files which have the definitions after functions.

Modern compilers still have to follow the rules of the language.

Yes, but is the constraint that compiler shall make only a single pass, a rule of the language?

Prior to C99 (i.e., in C90), there was a rule that any undeclared identifier id that was followed by a function call parenthesis would be treated as though there were an implicit declaration in the scope in which it was used like this:

  extern int id();

The empty parentheses meant it could take any number of arguments, since it was declared in the traditional style, where the argument types weren't specified first.

This implicit declaration meant that if it was later defined in the same file as returning a type other than int, the compiler wasn't permitted to go back up in the file and treat the function call as though it returned a type other than int.

This requirement was removed in C99, but in practice, compilers kept doing it for backwards compatibility, even when not invoked in C90 mode.

What I understand is the preprocessor causes issues where you could do that maybe 99.9% of the time, especially with well written code. But it'd fail that 0.1% of the time.

You do have analyses like ctags. In theory the compiler could use ctags to find definitions in source code. My experience is ctags can get confused. It's possible in a set of files to have multiple implementations of a function and ctags can't tell which one is used. And I see cases where it can't find definitions.

Personally I'd be happy if the compiler tried to find a missing definition using ctags and issued a warning.

I have wondered if adding funct, public, private keywords to the language might allow the compiler to reliably find function and stuct definitions in source files.

Good question.

Reply on news.ycombinator.com