🚀 go-pugleaf

crowl@cs.rochester.edu (Lawrence Crowl) writes:
| In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
| >I suggest that a language intended for library development be approached by
| >the developers with the attitude that a machine cycle wasted is a personal
| >affront.  I think we will find that the resulting languages will be easier
| >to use and less artificial than the current ones.

What has become quite clear is the opposite:  Human time is *much*
more expensive than computer time.  If wasting cycles were a personal
affront, then we would still be editing programs by playing with decks
of punch cards.

There are certain library routines, OS schedulers, and the like that
will be executed enough to make spending human time for serious
optimization reasonable, but they probably are less than 1/10,000 of
all program lines written.

| >Implementing an arbitrary set of types is no more difficult for the user than
| >the 5 or 6 that the guru thinks of.

Really?  How about the coercions (automatic type conversions) that are
allowed?  How does, say, "add" decide to jiggle the types of the
arguments so that the arguments are addable?  If you think that this
is simple, read the beginning of the IBM PL/1 reference manual where
it discusses the datatypes and how they interact.  There is DECIMAL
FIXED and BINARY FIXED and DECIMAL FLOAT and BINARY FLOAT, and STRING
and BIT STRING, and they have lengths (in bits or digits) and scales
(for FIXED types) and there is a whole host of conversions.  In the
extreme, you must note that

	IF PI THEN ...

is perfectly meaningful in PL/1, and the conversion rules tell you
whether PI is true or false...  (I'm not saying that this is good,
just that there are a lot of strange implications of
reasonable-sounding typing systems.)

Implementing a type is simple, provided that no operation is affected
by its context and that you don't have to make previously-existing
operators work with the new datatype.  Otherwise there are a lot of
subtle problems that have to be thought through.

| >Allowing the user to put in his operations and specifying their syntax is not
| >much more difficult for the compiler than the present situation.
| 
| User modifiable syntax is a very difficult to define consistently and very
| difficult to parse.  The consensus so far appears to be that it is not worth
| the cost.

I agree with crowl.  Allowing the user to change the syntax of a
language is a monstrous problem.  Anyone who doesn't think so hasn't
put together a parser for a serious language.

Dale
-- 
Dale Worley    Cullinet Software      ARPA: culdev1!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw
If you get fed twice a day, how bad can life be?