mandatory newbie musings

[Quinn Dunkan]

Cool... glad there's someone here!  Whenever I start on a new language, OS, or
whatever, I post big old "why are things this way" messages.  I haven't been
flamed too hard yet, and it helps me get to know how the minds of the people
who designed the OS / language work, and maybe even gives them some momentary
amusement :)

These are stdlib questions, so if the stdlib is undergoing a redesign, perhaps
they're out of date.  Still, I hope maybe my questions bear some relevance.
Since there appears to be no stdlib documentation, I've just been reading the
source.  I must say that it is very clear and well-commented (looks like it's
supposed to be used with a semi-literate document-generation system).  I have
respect for a language who I can learn by reading the source after skimming
the tutorial once :)  The primary hairball is the whole type-safe overloaded
methods thing, which I hopefully won't have to deal with since I don't plan on
using many overloaded methods.

I also like the use of inlined C... hopefully the new compiler and library
will make that even easier and more transparent :)

So here's the newbie musings:

I'm new to sather, and I have a few questions.  Also, the closest language I
know to sather is probably python, so these questions may reflect my
background.  My pre-python background is haskell, so when I came to python I
had trouble getting out of FP mode, but I think I've worked most of that out
by now :)

Firstly, I had a bit of trouble compiling 'sacomp'.  First of all, the
documentation is a bit inaccurate (it says the default make rule makes
optionals, which it doesn't, and it seems to want to bootstrap even if you
already have Boot/sacomp.code/), although it does warn about "outdated" :)

The real problem is that the bootstrap compiler segfaults during the "Type
check, generate, inline, optimize, and make C..." phase.  Editing
Boot/sacomp.code/Makefile to use -O instead of -O2, but then it went ahead and
compiled a broken Bin/sacomp with -O2, so I just copied over Boot/sacomp.
sabrowse was segfaulting before, but now it's not, weird.  Could it be a gcc
problem?  It's 2.95.1 under 'i586-pc-linux-gnu' which is the latest stable
version from cygnus.  libgc.a is 4.14.  I read on the deja c.l.sather archives
that this is a known problem with gcc, so I guess I should have looked at deja
first :)



The FILE class has open_for_this, open_for_that, etc. which are just wrappers
around various fopen modes.  I'm curious as to why it doesn't simply provide a
open(fname:STR, mode:STR):SAME or create method.  I see the mode string in
fopen as being a "little language", like printf format strings, that becomes a
large set of unwieldy methods when moved to another language.

mode string pros:
compact
easy to read
easy to write

cons:
must be learned for "easy to read" and "easy to write" to be true

sather method wrapper pros:
easy to read without learning them

cons:
wordy
hard to write
hard to learn (is it open_for_reading?  or open_for_write_truncating?  do we
               really need BFILE which is almost exact copy of FILE?)

In the case of a mode string, the "must be learned" con isn't even a con if
the user knows the posix interface (which many languages, including C, use).

Since it would have been actually easier to provide a single FILE::open
method, the reason it wasn't must be cultural.  The sather tutorial and faq
make no mention of what 'sather culture' is I have to ask here :) Perhaps it's
like 'smalltalk culture' which has a reputation for a NIH streak :)  Do we
really need FILE::current_loc when 'tell' is shorter, perfectly reasonable,
and already standard?  Who on earth wants to type 'create_directory' when
'mkdir' is already standard?  And what's with this 'size' vs. 'length'
schizophrenia?

I also have a disagreement with #FMT... it makes up it's own formatting
language, which doesn't appear to have any advantage of printf-style, but
fortunately, it also supports printf-style.  Unfortunately, it loses *all*
points by trying to *guess* between the two.  Aaaarrrggghhh!!  And provides
no way to say "no really, I *do* know what kind of formatting I'm using,
please believe me".  Simple text formatting like this is so essential to so
many kinds of programs we really shouldn't have a brain-dead design here (no
offense to the guy who wrote it! :).  python overloads '%' to format a string,
and while I generally disapprove of overloading unrelated operators for random
things, it turns out to be incredibly handy.  It's an idea that's begging to
be stolen (ruby already has) :)

That said, mini-languages, while frequently quite nice, are often a trap of
their own.  I believe the continual upgrading of regexp capabilities in perl
is such a trap.  If they aren't already, perl regexps will soon be turing
complete and people will write web servers in them.  I'd prefer a standard set
of backtracking parsing combinators (but that, also, is a sort of
mini-language).  sather appears to have no call/cc (except implicitly in
iters), but it looks like laziness and thus backtracking could be implemented
using bound methods and an iterator.



Another question is exception usage.  Again, from the FILE class, it seems
sather convention is to not use exceptions, but provide error methods.  This
means that every single file open must be explicitly checked for error, or
else you get a segfault.  This is not much better than C!  One of the nice
things about python is you don't have to deal with stuff like that, thanks to
exceptions.  The tutorial mentions that this convention is because exceptions
are inefficient in sather.  If this is the only reason, *how* inefficient are
they?  Do you pay the penalty only if the exception is actually thrown, or do
you pay for the mere possibility that an exception *might* be thrown?  And is
it really worth sacrificing the safety and error reporting exceptions provide
for a little efficiency?  And in the case of FILE, does it really even give
you any efficiency benefit?  If you have performance-critical code that
depends on being able to open files as quickly as possible, I'd really like to
know what you're writing :)

This corresponds with a seeming general lack of use of exceptions in sather.
For example, I can find no standard exception classes, generally STRs or INTs
are used.  This means you catch by STR or INT instead of by type of error,
which hardly seems desirable.

Once again, this seems to be a cultural thing, since there is nothing about
sather (except efficiency, perhaps) that prevents there being a standard
exception hierarchy that is used by the standard library.  Even python, with
its lack of emphasis on performance, provides 'raising' and 'non-raising'
versions of certain methods that tend to need to be fast (e.g.
"string".index(s) throws an exception when s is not in "string", while
"string".find(s) returns -1).  Of course, in python, you don't pay for
exceptions if they don't get thrown.

If exception use is generally deprecated in sather, why not take it out?
If it isn't, why not use it?  And if efficiency is the main problem, shouldn't
the compiler be fixed to make them more efficient (easy for me to say)?


One last thing: is there any convention about 'self modifying' methods versus
'create new object' methods?  '!' is already taken, but a *consistent*
convention would be nice (it's these sort of things that make or break
stdlibs, I think... and a quality stdlib is *so* important).  sather can
overload based on whether there's a return value...  perhaps this should be
used?  It seems like a simple naming scheme would be a better approach, to me.

    append(a:T):SAME is
        -- A new array conisting of self followed by `a'...
        ...
    end;
    append_d(a:T) is
        -- Append `a' to self...
        eee
    end;