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

91–100 of 136 posts

Re: EOF is not a character

#91

Post by sfifs »

rectang wrote: post #19

Like NULL, confusion over EOF is a problem which can be eliminated via algebraic types. What if instead of a char, getchar() returned an Option ? Then you can pattern match, something like this Rust/C mashup: match getchar() { Some(c) => putchar(c), None => break, } Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's dra…

Or allow multiple return values like Go. EOF gets returned as an explicit error value and the io.Reader interface is standardized and widely used.

Re: EOF is not a character

#92

Post by enriquto »

wk_end wrote: post #86
enriquto wrote: post #83

Earlier quoted context omitted.

> 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. What kind of wicked education you had for this to be the case? My dad taught me about bits and bytes and words when I was a kid, and by 16 I had a quite solid grasp of it (without any textbook).…

Surely if you have a PhD in applied math you've seen that Wikipedia will often foreground dense theoretical issues, even for topics with straightforward practical applications. You do not need to understand theoretical type theory to understand options. It's just like a pointer that can be NULL except the compiler makes sure you can't accidentally dereference it if it is. Algebraic data types in general are basically…

> Are they actually just smarter than you?

Sure they are. Or at least they do not hold an irrational, primary hatred of over-abstraction like I do. In math there's also people like this, who work in stuff like category theory, logic and whatnot. Fortunately, they are a mostly controlled minority.

Re: EOF is not a character

#93

Post by empath75 »

enriquto wrote: post #83
dmit wrote: post #82

Earlier quoted context omitted.

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.

> 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. What kind of wicked education you had for this to be the case? My dad taught me about bits and bytes and words when I was a kid, and by 16 I had a quite solid grasp of it (without any textbook).…

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.

Re: EOF is not a character

#94

Post by ajnin »

sfifs wrote: post #91
rectang wrote: post #19

Like NULL, confusion over EOF is a problem which can be eliminated via algebraic types. What if instead of a char, getchar() returned an Option ? Then you can pattern match, something like this Rust/C mashup: match getchar() { Some(c) => putchar(c), None => break, } Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's dra…

Or allow multiple return values like Go. EOF gets returned as an explicit error value and the io.Reader interface is standardized and widely used.

It seems weird that Go considers EOF to be an error condition. Reaching the end of a file is a normal, expected outcome of reading files.

Re: EOF is not a character

#95

Post by unnouinceput »

For me EOF is a boolean state. Either I am at the end of file (stream / memory mapped etc) or not. That's how I was taught when I started programming. Never occurred to me to think of it like a character.

Re: EOF is not a character

#96

Post by barrkel »

ajnin wrote: post #94
sfifs wrote: post #91

Earlier quoted context omitted.

Or allow multiple return values like Go. EOF gets returned as an explicit error value and the io.Reader interface is standardized and widely used.

It seems weird that Go considers EOF to be an error condition. Reaching the end of a file is a normal, expected outcome of reading files.

By making error values explicit and handling them necessary, Go makes all error conditions expected outcomes.

Whether this is an advantage is heavily domain dependent.

Re: EOF is not a character

#97

Post by enriquto »

empath75 wrote: post #93
enriquto wrote: post #83

Earlier quoted context omitted.

> 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. What kind of wicked education you had for this to be the case? My dad taught me about bits and bytes and words when I was a kid, and by 16 I had a quite solid grasp of it (without any textbook).…

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?

Re: EOF is not a character

#98

Post by TheCoelacanth »

matheusmoreira wrote: post #64
rectang wrote: post #19

Like NULL, confusion over EOF is a problem which can be eliminated via algebraic types. What if instead of a char, getchar() returned an Option ? Then you can pattern match, something like this Rust/C mashup: match getchar() { Some(c) => putchar(c), None => break, } Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's dra…

> Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's drawbacks. They're part of the C standard library. The POSIX I/O APIs don't have these problems. The Linux I/O system calls are even better because they don't have errno. Honestly, the C standard library just isn't that good. Freestanding C is a better language precis…

I think that's being too kind. The C standard library is terrible.

Re: EOF is not a character

#99

Post by cesarb »

unilynx wrote: post #74
pwdisswordfish2 wrote: post #59

Earlier quoted context omitted.

That is a common misconception. http://jdebp.info/FGA/dos-character-26-is-not-special.html

I'm pretty sure the DOS TYPE command (its version of cat) would stop at the first ^Z it encountered, even if the file was longer. It was sometimes used to have TYPE print something human readable and stop before the remaining (binary) file data would scroll everything away

> It was sometimes used to have TYPE print something human readable and stop before the remaining (binary) file data would scroll everything away

Notably, in the PNG file format (created back when MS-DOS was still very relevant):

"The first eight bytes of a PNG file always contain the following values: [...] The control-Z character stops file display under MS-DOS. [...]" (http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R....)

Re: EOF is not a character

#100

Post by matheusmoreira »

TheCoelacanth wrote: post #98
matheusmoreira wrote: post #64

Earlier quoted context omitted.

> Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's drawbacks. They're part of the C standard library. The POSIX I/O APIs don't have these problems. The Linux I/O system calls are even better because they don't have errno. Honestly, the C standard library just isn't that good. Freestanding C is a better language precis…

I think that's being too kind. The C standard library is terrible.

To be fair, the libraries found in other languages aren't much better. Ruby's standard library was the most comfortable in my experience but it still has glaring flaws.
Post reply on HN