TUNES digest, Vol 1 #356 - 8 msgs

[Lynn H. Maxson]

Before C we had only strong typing, in fact in many cases 
overly strong in that without explicit programmer intervention 
we could have mixed arithmetic expressions, e.g. fixed and 
floating point values.  PL/I addressed this intelligently, 
maintaining strong typing while at the same type applying 
default conversion rules if the programmer did not want to 
explicitly do so.  In fact PL/I allowed character, i.e. string, 
numeric values to also occur within the expression.

The argument of strong versus weak typing deals with the 
matching of the operator and operands: numerical operators 
should have numerical operands; logical operators, logical 
operands; string operators, string operands; etc..  This says for 
strong typing to occur for a set of operators available in the 
language that we should have the corresponding operands 
(data types) available also.  C does not with its limited 
support of data types.  Thus it must use normally mismatched 
combinations of operators and operands.  Thus C engages in 
weak typing, e.g. allowing an "int" variable to play in either 
arithmetic or logical operations.  It works because every 
known machine allows a single "register" value to function 
with either form.

Much the same argument occurs between the "artistic" and 
the "engineering" approach.   We should remember that when 
developing software or maintaining it that in the interval, in 
the transition, from initiation to completion its "natural" state 
is "incomplete".  To a compiler incomplete is not a natural 
state, while it is to an interpreter.  Thus it makes sense to 
program in an interpretive mode while in the incomplete state 
and then compile mode on reaching the complete state.  As 
everything preceding interpretive or compile code generation 
is the same for both, why would you have to have two 
separate products with two different modes of operation 
when you could have them both in one product?

Thus you have with each operator an implicit type declaration 
for its operands.  Within each type you have different modes: 
binary and decimal, fixed- and variable-point precision, fixed 
and floating point data.  Which type is best depends only upon 
when all the votes are in: when it has or is about to reach the 
state of completion.  In short while it is in the incomplete state 
the software can resolve the issue of typing, awaiting final 
resolution by the programmer.  It just keeps a list of such 
unresolved issues which the programmer can resolve in any 
order until it is as completely resolved as everything else.

What we also forget when discussing the need for knowledge 
of Lisp is that what sets it apart is a "list aggregate" as a 
data type as well as a set of list operators.  It would seem 
reasonable in any programming language, which supports 
aggregate (array or structure) operands, to upgrade it to 
support list aggregates as well along with the addition of list 
operators.

Ultimately you get down to a defining issue.  Can you 
implement a language entirely using that language?  If you 
cannot, then you need at least two languages.  Chances are 
that's assembly language.  Then if you access the Intel 
Pentium Language Reference manual, you will note that each 
instruction is given in three different forms: actual, symbolic 
assembly, and HLL.  As any language under consideration here 
is an HLL, you have to ask why doesn't it include assembly 
language?  If it does, then you can implement it entirely using 
it.

As every programming language is also a specification 
language can your HLL not only implement itself entirely 
within the language, but can it specify itself entirely using it 
as well?  Is it self-defining and thus self-extensible using only 
its language?  I mention this only because it seems a 
"weakness" in all the languages mentioned or proposed thus 
far under Tunes.

It makes little sense to me to talk about declarative languages 
based on logic programming if it does not contain the ability to 
have both processing statement types, the assertion and the 
assignment.  The proof process may differ for both, though 
one (assignment) is a proper subset of the other (assertion).  
Nevertheless all machine architectures, i.e. instructions, use an 
imperative form.  Thus any "complete" declarative language 
should include this form as well.