4 ms·
> Generators don't mirror the hardware. You mean like this? #include <stdio.h> #include <stdlib.h> struct generator_state { int next_valu
by tom_mellior 7y ago
> Generators don't mirror the hardware.
You mean like this?
#include <stdio.h>
#include <stdlib.h>
struct generator_state {
int next_value;
int limit;
};
struct generator_state *enum_from_to(int from, int to) {
struct generator_state *generator = malloc(sizeof *generator);
generator->next_value = from;
generator->limit = to;
return generator;
}
int has_next(struct generator_state *state) {
return state->next_value <= state->limit;
}
int next(struct generator_state *state) {
return state->next_value++;
}
int main(void) {
printf("try to enumerate from 1 to 10\n");
struct generator_state *generator = enum_from_to(1, 10);
while (has_next(generator)) {
printf("%d\n", next(generator));
}
return 0;
}
Oh no! Imperative programming doesn't mirror the hardware!
> Lazy evaluation is a convenience that is dangerous to think of as free
So your problem isn't really FP, it's Haskell?
> as is recursion
It's dangerous to think of any computation as free, so... OK.
> Code-as-data limits the kind of addressing that can be used in the chip itself.
I don't know what you mean here, but "code as data" isn't a universal feature of FP languages. Even in Lisp it's essentially a compile-time abstraction for macro expansion, you don't massage your function definitions at runtime. And once your code is compiled to machine code, what exactly is the problem with using all of the chip's addressing modes?
Maybe by "code as data" you mean "first-class functions", i.e., that you can have pointers to code that you can store in data structures? I'll spare you the C example of function pointers because we've established above that C is a terrible language that doesn't map nicely to the hardware ;-) Maybe it's Pascal you want!