null references redux + Looney Tunes

[Andrei Alexandrescu]

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:hab3r2$2pgr$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> There's been discussion before (I can't find it now, or remember the name 
>>> for it) of type systems that allow for proper handling of things like m/s 
>>> vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a 
>>> feature or with complex/imaginary numbers in any actual code, so I can't 
>>> be sure, but I've been wondering if a type system like that would be an 
>>> appropriate (or even ideal) way to handle real/complex/imaginary numbers.
>> It better be. Complex numbers aren't that complicated of a notion. What's 
>> lost in pulling them out of the language is the ability to define 
>> literals. Now please name five remarkable complex literals.
>>
>> The feature you're referring to is called dimensional analysis.
>>
>>> (I've also been wondering if it might be a huge benefit for 
>>> distinguishing between strings that represent a filename vs file content 
>>> vs file-extention-only vs relative-path+filename, vs absolute-path-only, 
>>> etc. I've been really wanting a better way to handle that than just a 
>>> variable naming convention.)
>> I don't quite think so. In fact I don't think so at all. Pathnames of 
>> various flavors evolve quite a bit in many programs, and having to worry 
>> about tracking their type throughout is too much aggravation to be 
>> worthwhile. Last thing I'd want when manipulating pathnames would be a 
>> sticker of a library slapping my wrist anytime I misuse one of its six 
>> dedicated types.
>>
> 
> Last thing I'd want when dealing with paths and filenames would be making 
> one small mistake and getting *neither* a runtime nor a compile-time error, 
> and then have the program happily trounce about the filesystem with 
> corrupted names or paths (sort of like getting m/s and m/(s*s) mixed up). 
> Sure, it *might* error out with an "access denied" or "file not found" or 
> something like that before actually doing anything wrong, but that's far 
> from guaranteed. And even if it doesn't, it might not cause real harm, but 
> there are times when it could so why risk it?

I think it's a judgment call. I did see a few examples throughout the 
years that created special types for various pathname components. I 
think one early C++ book had such an example. None of those attempts 
survived, and perhaps that could mean something. What may be happening 
is that in applications, the same variable may be e.g. a filename or a 
dirname, and handling that with an algebraic type may be considered too 
much aggravation.

> I guess I just don't see why something like (fig. A) would be bad if (fig. 
> B) and (fig. C) are considered good (as I certainly consider them):
> 
> -- fig A -----------
> open(inFile ~ "out" ~ inFile.file ~ "log");
> // As many as 4 different errors that could be caught but currently aren't.
> // (But obviously all would be overridable, of course)
> // Without such checking, if inFile contained "/usr/home/joe/foo/bar.dat",
> // the result would be:
> //   "/usr/home/joe/foo/bar.datoutbar.datlog"
> 
> // Meant to do this:
> open(inFile.path ~ "out/" ~ inFile.name ~ ".log");
> // Result now: "/usr/home/joe/foo/out/bar.log"
> ---------------------
> 
> -- fig B -----------
> int add(int* a, int* b)
> {
>     return a + b; // Error currently caught
>     // Meant:
>     return *a + *b;
> }
> ---------------------
> 
> -- fig C -----------
> auto accel = velocity * time; // Error caught with that "dimensional 
> analysis"
> // Meant this:
> auto accel = velocity / time;
> ---------------------
> 
> Granted, I agree that as things currently are, it might not be possible to 
> write a library to handle such file/path manipulations without it being too 
> unweildy for the library's prospective users. But with a good "dimensional 
> analysis" system...maybe not?

Well it may be a good idea if you tried it and see how it feels. A 
little algebra of path components isn't difficult to define and implement.


Andrei