🚀 go-pugleaf

In article <ROCKWELL.92Apr8151628@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> 'type' is a concept used when talking about, for instance, the domain
|> of a function.  For example, 'prime number' might be considered a
|> type.  Or, less arbitrarily, 'symetric matrix' might be a type.

Type is any static information which the user and/or the compiler can
use to double check program correctness and enhance optimization.  If
an attribute of an object (whether it be a function or data) is not
static, then that attribute is part of the _value_ of the object and
not part of its _type_.

|> [...]
|> 'storage class' is a concept used when talking about the machine
|> representation of data.  This might be considered a 'type', but only
|> when discussing low-level function, or partial functions, on that
|> machine.

Storage class is often (but not always) desired to be part of the
type of an object.  J appears not to permit objects to be declared
to be limited to a specific storage class.  In fact, it's still not
clear to me that there are _any_ attributes about an object that can
be statically declared.

|> [...]
|> Forcing the programmer to concentrate on machine specific types is not
|> a good way to encourage robust or portable code.  [...]

Nor does disallowing the user access to those attributes.  In fact, due
to the nature of floating-point, _not_ letting the user have control
over machine specific attributes may make robustness unattainable.

|> [...]
|> This is a complex issue.  I don't think it's a good idea to remove
|> responsibility for this complexity from the language implementor (who
|> concentrates on porting the language to a specific machine) just to
|> dump it on the programmer (who concentrates on whatever arbitrary
|> problem domain she's interested in).  Not if it means the language is
|> less expressive...

Expressiveness is just exactly the issue.  J does not let me express
clearly those constraints that I know when I write the code.  Fortran
forces me to express constraints that I may want to leave up to the
compiler or which I may want the code to handle generically.  Our 
proposal is to allow the _user_ to decide which things to express and 
which not to.  In any case, Fortran is generally closer to what is 
needed from a general purpose tool than J is.  That's why out proposal
is based upon Fortran.

By the way, why do you assume all programmers are female?

|> [..]
|> On the other hand, if your goal is verbosity for its own sake, forcing
|> special case solutions is, in general, a good way to achieve it.

My goal is not `verbosity' but clarity.  Your goal appears to be
terseness.

J. Giles