RE: Language design values (Re: message primitive)

["Daschbach, John L" <John dot Daschbach at pnl dot gov>]

	----------
	From: 	Telford Tendys

	> My own list would include:
	> 
	> * Consistency
	> * Orthogonality
	> * Simplicity
	> * Convenience

	Consistency and simplicity always go together, it is usually harder to
get
	something to act in an unusual way than a usual way. Simplicity states
that
	less code is better, smaller API is better, smaller binary is better and
	so on. I like this -- it is easy to understand and easy to measure.

I don't agree with your first statement but I don't think it's worth discussing.
There are many examples of highly complex consistent systems.  Consistent can
even mean different things in the present domain (computer languages).  Are we
discussing consistent syntax, semantics, function names, functional
transformations, variable names, ...?

	Orthogonality is already defined in mathematics as stating that the
	dot product of two vectors is zero. I hate to see the word applied in
	a hazy way to computer languages since no one can give it a solid
	definition. If you are suggesting that any given computer behaviour
	should only be achievable by exactly one program (or none at all)
	then that seems like an impossible thing, and not even desirable.

You have used an incomplete description of mathematical orthogonality and then
applied the correct but limited definition incorrectly.  Would you describe this
as hazy?  Many words in English are used in different problem domains with an
accepted definition within the appropriate community.   In a complete system a
set of orthogonal basis functions are any distinct set of functions which span
the space and whose inner product is zero for any two distinct functions.
Applied to computer languages this would be more casually interpreted, but still
imply that no two functions, used alone, would transform the same input to the
same output for all input cases.  It is hard to define in  a pure way
orthogonality for a high level computer language (Knuth essentially uses
orthogonal functions in his texts with RISC like architectures) but we can
probably accept it to mean that there are not multiple ways in the core language
to accomplish agreed upon core functionality.  However this is easily seen to be
unworkable in a high level language.  R5RS scheme is highly orthogonal, yet even
it includes highly unorthogonal syntax.  A classic example is 'if' and 'cond',
the latter being a derived type which is arguably easy to code in 'if' syntax
without even introducing much more code.   It is however true that R5RS would
encourage implementations to have only the core 'if' form in the evaluator and
use the syntax system to transform 'cond' to 'if'.  In this way, R5RS does
implement an orthogonal set of functions.

	Convenience is the one where everything comes undone. What is convenient
	for one person is useless for the next. How many guile users need
complex
	numbers? This is such a subjective area but it almost always trades
	off against simplicity. 

Mostly I agree with you, but I do sometimes need complex numbers.   However a
highly complex system can be convenient for different users *if* their portal
into the system (in a generic sense) is defined clearly for their problem
domain.  For instance if your using guile for web scripting complex numbers are
probably unnecessary and certainly add complexity to the interpreter.
Conversely if your using guile for optical transmission calculations complex
numbers are very important but sockets, regular expressions, and strings are
probably unimportant and add complexity to the interpreter.   However if the
first person learns guile from an introduction to web scripting in guile
tutorial and the second from a physics calculations in guile tutorial each may
see the system as simple for their problem domain.  The unique functions the
other one uses are orthogonal to their needs and thus need not be learned or
used.

Convenience for a computer language in the realm of this discussion is provided
by a language in which one can express their problem with the fewest number of
basis functions.  Thus it is in general true that the resulting code for a
convenient language is simple, at least in a token counting sense.  One can
argue, as I did above, that if each user is only exposed to those functions
pertinent to their problem then from the user perspective the language is
simple.

Scheme as a language seems to clearly satisfy the first three conditions above.
Guile is hoping to add to this and satisfy #4.  It might be a useful discussion
to collect the functionality that people want to address #4 and then see if some
of this may be described by a new set of orthogonal basis functions.  I would
argue that these should be in a second library, not in the core.  As a first
step, I think that a general formatted output routine would be desirable.

-John