Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EOF is not a character

ruslanspivak.com

Post reply on HN
Print view View original

111–120 of 136 posts

Re: EOF is not a character

#111

Post by wyldfire »

enriquto wrote: post #80
rectang wrote: post #79

Earlier quoted context omitted.

I strongly disagree. The existing getchar() API is not simple at all! All the possible error conditions are still there, they're just obscured by an overstreamlined API which fuses them inappropriately into a single return type. That makes it harder to handle all cases well, because you have to do all the work manually.

The man page for getchar is a single, easy to read paragraph. To understand algebraic types you need a couple of textbooks.

You can amortize that cost over all of the problems in the language's domain, not just getchar.

Re: EOF is not a character

#112

Post by jfdhvdybc »

nixpulvis wrote: post #7
reidacdc wrote: post #5

Seems like the confusion arises because getchar() (or its equivalent in langauges other than c) can produce an out-of-band result, EOF, which is not a character. Procedural programmers don't generally have a problem with this -- getchar() returns an int, after all, so of course it can return non-characters, and did you know that IEEE-754 floating point can represent a "negative zero" that you can use for an error cod…

What does "Procedural" vs "Functional" have to do with this? It's a choice in data type. If by procedural you mean, nonsense, then sure... I agree that a function named `getchar` returning an `int` is procedural. :P

The simple answer to this is that these days "functional programming" doesn't just mean the absence of side effects. It means strong type systems, algebraic data types, list comprehensions, etc. It is a distinct cultural stream in the development of programming languages. Of course "functional" has an original narrow meaning, but so do "Republican" and "Democrat".

When Rust introduced ADTs they were recognizably a concept from functional programming. It's a place or community of practice, not a purely descriptive adjective.

Re: EOF is not a character

#113

Post by jwilk »

Um, no, you can't use Python to infer that "EOF (as seen in C programs) is not a character".

The exception even tells you that "chr() arg not in range(0x110000)" which has nothing to do with range of C's character types.

Re: EOF is not a character

#114

Post by teddyh »

juped wrote: post #107
teddyh wrote: post #103

Earlier quoted context omitted.

> We can already return structs AFAIK, no? You can return a pointer to a struct, and you can pass whole structs as arguments , but not, IIRC, return them from functions. EDIT: Apparently you can , sort of, but not portably; how exactly it is defined to work depends on the compiler, and each compiler might define it differently. This means that if you’re using a library which returns a struct and your program use a di…

Structs are values and you can return them like any value (or use them as parameters). I'm not sure what you mean about compilers.

See, for instance, here:

https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Incompatibiliti...

https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Code-Gen-Option...

https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Warning-Options...

Re: EOF is not a character

#115

Post by bloomer »

dmit wrote: post #82
enriquto wrote: post #80

Earlier quoted context omitted.

The man page for getchar is a single, easy to read paragraph. To understand algebraic types you need a couple of textbooks.

No, encoding additional information in unused bits of an int that you return is stupid over-engineering that needs multiple textbooks to grok. Option , on the other hand, is the simplest possible solution for this problem.

I would also like to not that encoding the the Option using the unused bits of the return value is a perfectly valid implementation. But that is exactly what it is, an implementation detail. It could work exactly the same way as today but the programmer wouldn’t have to care about how it was implemented, just whether they got a char or None.

Re: EOF is not a character

#116

Post by JdeBP »

juped wrote: post #107
teddyh wrote: post #103

Earlier quoted context omitted.

> We can already return structs AFAIK, no? You can return a pointer to a struct, and you can pass whole structs as arguments , but not, IIRC, return them from functions. EDIT: Apparently you can , sort of, but not portably; how exactly it is defined to work depends on the compiler, and each compiler might define it differently. This means that if you’re using a library which returns a struct and your program use a di…

Structs are values and you can return them like any value (or use them as parameters). I'm not sure what you mean about compilers.

Xe is conflating compilers and calling conventions a bit. The way that structure types are returned varies by calling convention, as indeed do a lot of other things. Mismatched calling conventions leads to problems.

But structure type return values are well specified for most calling conventions, and quite a number of compilers support explicitly specifying the calling convention for mixed-language or mixed-compiler situations.

* http://jdebp.uk./FGA/function-calling-conventions.html

Re: EOF is not a character

#117

Post by chrisseaton »

nixpulvis wrote: post #110
chrisseaton wrote: post #85

Earlier quoted context omitted.

> the madness of a function called `getchar` returning anything but a `char` It’s effectively returning a Maybe(char).

But it's not . A `Maybe ` has exactly one `None` variant. While an `int` has many, many negative values. Also, just calling it `None` (or similar) makes clear what is meant, while `-1` is some magic value.

> while `-1` is some magic value

It's a documented return value. Nothing magic about it.

Re: EOF is not a character

#118

Post by JdeBP »

combatentropy wrote: post #49

The kernel returns EOF "if k is the current file position and m is the size of a file, performing a read() when k >= m..." So, is the length of each file stored as an integer, along with the other metadata? This reminds me of how in JavaScript the length of an array is a property, instead of a function that counts it right then, like say in PHP. Apparently it works. I've never heard of a situation where the file size…

You are not thinking about it clearly. Ask yourself this: Filesystem formats use blocking and deblocking. How would a filesystem know the file size without having metadata for it?

Re: EOF is not a character

#119

Post by epolanski »

enriquto wrote: post #97
empath75 wrote: post #93

Earlier quoted context omitted.

I’m a community college drop out and have never taken a CS class and I use options in my code all the time. It’s just a wrapper around some value that is either Some(value) or None and you need to unwrap it and handle both possibilities for your code to compile. You don’t need to know anything about monads or ADT’s to understand it.

But do you understand that some values of a 32 bit int can be used to encode meta-data about a 8 bit char? If you understand both, which one is conceptually easier to you?

option obviously.

I just do not understand what the problem with Option is.

It's either Some(1) or None. If it's some you have the value, otherwise you handle the fact you don't have it.

It's so simple and basically every modern language uses it to handle nullable types.

Re: EOF is not a character

#120

Post by apta »

juped wrote: post #106
nothrabannosir wrote: post #84

Earlier quoted context omitted.

What always annoyed me about C is that it has all the tools to simulate something approaching this, save for some purely syntactical last-mile shortcomings. We can already return structs; if only there were a way to neatly define a function returning an anonymous struct, and immediately destructure on the receiving end. Something like: #include struct { int err; char c; } myfunc() { return { 0, 'a' }; } int main(int…

Sounds like you'd like Go, which works this way.

Which is a strictly inferior and botched way to go about it, especially since golang was designed from scratch.
Post reply on HN