4 ms·

>Maybe some structure has a "char * " name field, and null indicates "anonymous/has no name". It's an ISO C conformance bug to try to print that with %s, but th

by rtpg 11y ago

>Maybe some structure has a "char * " name field, and null indicates "anonymous/has no name". It's an ISO C conformance bug to try to print that with %s, but that's a portability issue. If that's the only problem in the program (everywhere else it checks for null), there is no real issue. I'll take 'uses of Option/Maybe' for 200 Alex Some might say it's overkill, but if you can have a char* be null, then for most intents and purposes you have two states to deal with on any usage of that value. Just because such a design can exist doesn't mean we should hobble our tools to support it.

kazinator 11y ago
It could simplify things elsewhere. In Lisp, CAR and CDR accessors take a cons cell or NIL, which isn't a cons cell, and has no such fields. It wasn't always like that; according to the HOPL paper on evolution of Lisp, InterLisp introduced this nicety and it was copied by others. These functions are complicated with that extra state, but programs are simplified. A null "char *" indicating "this object has no name" is better than some special string value doing the same, because it's different from every possible string value.
- rtpg 11y ago
  I'm not saying a special string value, but a wrapper object with an "existence" bit. You can then assume, if the existence bit is flipped right, that the char* "exists". This is functionally equivalent, but forces existence checks when they're needed. And by removing "null" from your vocabulary, an entire class of errors disappears. With C this is a bit trickier to ensure. But I think the design pattern can still be useful. And it doesn't make code more complicated, but rather it makes the complicated aspects explicit . Instead of testing that name == null, you test that name.exists is False, and if not you use name.value. And you make null a banned word in your codebase. The result is that you _never_ have to ask "is this char* possibly null?". The answer is always "no". So you remove superfluous checks I think this pattern works much better when you have stronger type checking, though...
dllthomas 11y ago
A nullable char pointer is a perfectly sensible implementation of "Maybe String". At least, presuming a non-nullable char pointer is a perfectly sensible implementation of String.
- rtpg 11y ago
  I kind of cover it in my other comment, but the issue is that now all char pointers are nullable, so you _have_ to assume that all "char* " are Maybe'd. But it could just as well be that only some of your strings are nullable, and so you could get rid of certain code paths.
  - dllthomas 11y ago
    It's a matter of types vs representation. A compiler could represent (with or without promising to do so) optional strings as a nullable pointer to a char array. Without additional help from the compiler to distinguish between Maybe String and String, then things are as you say. Incidentally, while Maybe String can be a nullable char pointer, Maybe (Maybe String) needs a different representation. This is where "nullable" in C# breaks down compared to a real option type - but only because they conflate type and representation.

by rtpg 11y ago

kazinator 11y ago

It could simplify things elsewhere. In Lisp, CAR and CDR accessors take a cons cell or NIL, which isn't a cons cell, and has no such fields. It wasn't always like that; according to the HOPL paper on evolution of Lisp, InterLisp introduced this nicety and it was copied by others. These functions are complicated with that extra state, but programs are simplified. A null "char *" indicating "this object has no name" is better than some special string value doing the same, because it's different from every possible string value.

rtpg 11y ago
I'm not saying a special string value, but a wrapper object with an "existence" bit. You can then assume, if the existence bit is flipped right, that the char* "exists". This is functionally equivalent, but forces existence checks when they're needed. And by removing "null" from your vocabulary, an entire class of errors disappears. With C this is a bit trickier to ensure. But I think the design pattern can still be useful. And it doesn't make code more complicated, but rather it makes the complicated aspects explicit . Instead of testing that name == null, you test that name.exists is False, and if not you use name.value. And you make null a banned word in your codebase. The result is that you _never_ have to ask "is this char* possibly null?". The answer is always "no". So you remove superfluous checks I think this pattern works much better when you have stronger type checking, though...

dllthomas 11y ago

A nullable char pointer is a perfectly sensible implementation of "Maybe String". At least, presuming a non-nullable char pointer is a perfectly sensible implementation of String.

rtpg 11y ago
I kind of cover it in my other comment, but the issue is that now all char pointers are nullable, so you _have_ to assume that all "char* " are Maybe'd. But it could just as well be that only some of your strings are nullable, and so you could get rid of certain code paths.
- dllthomas 11y ago
  It's a matter of types vs representation. A compiler could represent (with or without promising to do so) optional strings as a nullable pointer to a char array. Without additional help from the compiler to distinguish between Maybe String and String, then things are as you say. Incidentally, while Maybe String can be a nullable char pointer, Maybe (Maybe String) needs a different representation. This is where "nullable" in C# breaks down compared to a real option type - but only because they conflate type and representation.