[ANSI-Smalltalk] Smalltalk file streams

[Richard O'Keefe]

On 20 Oct 2008, at 2:24 pm, Steve Wart wrote:

> At the risk of getting dragged into a complicated discussion, I  
> think it would be productive to drop the complaints about the  
> unfortunate "PEBKAC" reference.
>
> I think it does make sense to have areas where the spec can leave  
> the desired behavior undefined (e.g. low memory conditions, etc.). I  
> interpreted the "problem exists elsewhere" to mean the spec doesn't  
> need to cover every eventuality.
>
> If I am mistaken you are welcome to ignore this suggestion :)

I guess it depends on where you are coming from
and how tolerable you find mysterious crashes in delivered code.

Let's take another example:  output failures.
Consider this bit of C code:

	FILE *f = fopen("foobar", "w");
	int   i;
	for (i = 0; i < 10; i++)
	    fprintf(f, "%d => %d\n", i, (~i) - (-1-i));
	fclose(f);

Compile this, run it, test it to your heart's content,
no worries.  Put it through lint, however, and lint
will complain that you are ignoring the result of fprintf
and of fclose.  And it's 100% right to do so.  If you are
writing to a disc, it may fill up, and if you ignore the
error results you get, your output will be truncated.
Thanks to buffering, the point at which the problem is
_reported_ may be some time after the limit is actually
reached.

As it happens, I once lost quite a lot of work because
someone else's program forgot to check for this.

C does not make it _easy_ to detect and respond to such
issues.  (There is a reason why my personal C library
includes efopen() and efprintf()...)  But it does at least
make it _possible_.

Now consider
	|f|
	f := FileStream write: 'foobar'.
	0 to: 9 do: [:i |
	    i printOn: f.
	    f nextPutAll: ' => '.
	    ((-1 bitXor: i) - (-1 - i)) printOn: f.
	    f cr].
	f close.

[Is anyone else annoyed that the ANSI Smalltalk standard
  doesn't include #bitInvert?]

I take it that we are all agreed that "disc space ran out"
is a global resource issue not entirely unlike "memory ran out".
I take it that we are all agreed that because disc space is
finite, this code fragment could encounter that limit.

But there is no standard way to detect that this has
happened.  And _that_ is a good way to lose other people's data
without warning them.

If you leave this undefined or implementation defined, there
is nothing a portable program can do about the issue.

I guess the basic question is "are we serious about Standard
Smalltalk being a language one could seriously use for anything?"