Language Syntax Suggestion

[Jeremy Dunn]

Matthew Tuck Wrote:

> {A.3.4} (where A is the subtraction operator), this represents both
the
> expressions {A,3,4} and {A,4,3}. The result of the expression {A.3.4}
> would then be a set of all possible results obtained by permuting the
> arguments, or a set {,-1,1} in this case.
>>In a permutation wouldn't you have to permute the A as well?

I suppose in a strict sense you would, except that the function name
must remain firmly rooted at the beginning of the function set otherwise
there is no unambiguous way to identify it as a function name. If we
wrote {,A,3,4} then the "A" becomes merely an element in the set with no
way for us to know that it is a function. In the function set the
function name is always assumed to be immobile while only its arguments
have the option of being ordered or unordered.

>I'm not convinced that unordered and dupeless literals are useless, but
>I would not think it was a good idea to allow implicit permutation like
>this.  It's similar to implicit conversion, in that you might not want
>it (wrote . instead of ,) and could get the wrong result.  Plus I don't
>remember ever having to need to take the permutation of a set into all
>possible lists.  A "permute" function would be nicer than trying to
>embed this implicit behaviour into the language.

Yes, it can also be done this way. I suppose that I like the aesthetic
sense of being able to explicitly indicate the essential character of a
set and its ordering. Not knowing the ins and outs of how the computer
must actually calculate these things I can believe that it might
actually slow things down rather than having a "permute" function do the
job.

> cannot cannot write something like (nth (+ 2 3 4) 1) to extract one
of
> the arguments to the expression. Being able to do this would
eliminate
> the need for many math functions that are necessary in other
languages.
> I will come back to this point later.
>>So the result of your expression would be +?

If we take the indexing of the set to begin at 0 then the element 2
would be returned, but this raises a good point. It would be nice to
write something like
(nth (+ 2 3) 0) and extract + as you mention. We may wish to loop
through a list of expressions and filter out only the ones that have a +
in them and this would be a good way to do a comparison. This would be
kind of like having the functions CAR and CDR in LISP or the functions
HEAD and TAIL in Prolog. If we did a (nth {,3,4},0) with a complex
number this would be the same as having a Re[] function. Similarly the
function Im[] would be (nth {,3,4},1). Mathematica has Numerator and
Denominator functions that could similarly be replaced by extracting
arguments of a function as merely elements of a set.

> We do
> have to add some extra punctuation if we have any unordered elements
> however. For instance, if we write (,book.k.e,eper) we have to add
the
> two commas to indicate that the two parts of the string on either
side
> of the "ke" are ordered while only "ke" is unordered.
>>I would have interpreted this as {,{,b,o,o,k,.,k,.,e},{,e,p,e,r}}.

That is certainly a reasonable interpretation, the explicit form of
(,book.k.e,eper) is actually (,b,o,o.k.e,e,p,e,r) which can also be
written as (,boo.ke,eper) to cut down the verbiage with the assumption
that the ordering is assumed for all elements until modified by a
different ordering symbol. In the case of an integer, an integer such as
384 can be written {,384} if we want to explicitly show its relationship
as a unary single dimension matrix. If we wrote {,3,8,4} we now have not
an integer but a set of three integers. If we wrote {3,8,4} we have a
function set with a function named 3 that operates upon the arguments 8
and 4 (the difference is the lack of comma preceding the 3). If I
followed this syntax rigidly for strings then the expression
(,boo.ke,eper) would be an ordered element "boo" followed by an
unordered element "ke" followed by an ordered element "eper". But that
was not our intent. In the case of integers we MUST assume that groups
of separated elements are single units otherwise we get ambiguous
results. If we interpreted {,345.35.34} like we did for "bookkeeper"
then this would be the same as {,3,4,5.3.5.3.4} when the first
expression is what I intended. My simplifying assumption seems to work
fine for strings if we grant that we can usually treat a string as 
collection of separate letters that we have no reason to want to break
into units like "boo" or "ke". If this is not true then we would be
forced to place puntuation preceding every letter of the string to be
absolutely clear. I didn't think most programmers would want to be this
clear ergo the exceptional case for strings.

>Why ambiguous for numbers.  Even though I admit it might be very
>decimal
>system oriented, 5.0 still make sense to match 510, 520 etc.   Sure it
>might clash with the number 5 point 0, but the "." symbol is arbitrary
>anyway.

In my proposed notation the integer 5 is written as 5, the real number
5.0 is written as {r,5,1} where this is the same as (0.5 * 10^1). 5.0
does not match 510, 520 etcetera because you would not order the
individual digits of an integer that way. This raises a good point, how
do we act upon the individual digits of an integer? I cannot write 123
as {,1,2,3} because this means something entirely else. We need an
intger function "i" that takes digits as arguments and returns a single
integer as a result. We need to write 123 as {i,1,2,3}, now it is clear
what we are talking about, now we can apply functions to individual
digits. Why do this? I don't know, but number theoreticians are always
doing things like this. We can now write {i,1.2.3} to represent the
numbers 123 and 132. We would also need a counterpart function {I,x}
that would take a multidigit intger as argument and return a set of the
digits split up. I think you were using the period as a substitution
operator but that is not its meaning as I have been applying it. It
means that the element which follows it is unordered.

>                         a,A addition/subtraction
>                         b,B multiplication/division
>                         c,C power/root
>                         d,D log/antilog
> 
> The function names are short because they are common operations.
Upper
> case function names help designate operations that are inverses of
the
> lower case ones and the letter progression is coincident with the
> heirarchy of how one operation is an expansion of the preceding one.
>>How is log an expansion of power?  Binary operations have TWO inverses,
>>it just so happens + and / are commutative so the inverses are the
>>same.  Both root and log are the inverses of exponentation.

Strictly speaking, you are correct. I viewed it like this:
multiplication is repeated addition therefore it is higher order than
addition, powering is repeated multiplication therefore higher order
than multiplication. The Log function is not repeated multiplication but
it is defined from the power function and is in that sense a higher
level of abstraction, people started from powers and then invented
logarithms. I view this group of functions as being a related group that
pretty much form an ordered group such as the trig functions might form
with each other.

> Any
> of these operations may have multiple inputs i.e. {c,2,3,4} is the
same
> as {c,{c,{c,2},3},4} and so on. A notion that I would like to
introduce
> is the use of default arguments to these functions if certain
arguments
> are missing. For instance:
>>Wouldn't you mean {c,{c,2,3},4}?

Yes, my typo.

>I don't really see that setting defaults on everything is a good idea. 
>Default parameters are there to save space where there is a very common
>default, and although your defaults are not uncommon and probably more
>used than most, they're still often not used.  Hence defaults are not
>really worth a programmer having to read an expression and think 'what
>was that default again?'

Not often used? I looked through my CRC math tables and found tons of
expressions that have doubling and halving in them, I found many that
have increments by 1 and decrements by 1. One also commonly increments
and decrements counters in loops. I chose my defaults with great care,
certain values of arguments occur far more frequently in mathematics
than other values, why not acknowledge that and make use of it. I
disagree that these defaults would be hard to remember. Most every
language I have used takes advantage of defaults and I'm glad they do.
The addition of defaults causes no extra overhead for the user because
even if they can't remember the default they can still explicitly put
the value in and type the extra symbols out of ignorance. But defaults
are useful for the more experienced programmer who gradually adds them
to their vocabulary. It is easier to add defaults and not use them then
it is to desire the default and not have it available. The Exp()
function is nothing more than powering with a particular base, isn't it
more elegant to use a default in the powering function to do this rather
than have another separate function? Why have a special square root
function when it is natural to have the general root function take care
of it?

> Matthew questions the utility of writing a real number in the form
> {r,x,y}, is there any advantage? Perhaps only in having a completely
> rigid format, doing it this way enables us to use any operation which
> can operate upon a set operate upon a real number that way too if we
> wish.
>>What functions would be useful on r's?

Well, a number-theoretician might wish to use my "i" function and write
something like {r,{i,*,*,*},y} and use the separate digits of the real
number to search for patterns of digits that are interesting. I grant
that the majority of programmers in everyday tasks would probably never
need to do anything like this. We can have it both ways, Mathematica
allows the user to use +, - etc. but allows the user to write Plus[a,b]
or Minus[a,b] if they desire, Mathematica was also consistent about
carrying their syntax throughout all functions. Mathematica does have a
function which takes a real number and returns a two element set of
digits and exponent, if it has no use why would they be doing it?

> Another reason would be that we are using the period to denote
> unordered elements in collections and wish to avoid using the same
> symbol for another purpose, ideally, one function name or symbol
should
> be used only once. By writing all operations in this way the user is
> never bothered with learning rules of precedence or of context.

>>How does this improve on "5"?  If you try to make everything fit into
>>{}
>>you're essentially removing programmers' readability cues as to what
>>that thing is.
>>Different things should look different, and that means using different
>>symbols.  If you have things in the language that have different
>>semantics, that would usually translate into different syntax.
>>If there is benefit in fitting numbers into sets, OK, but is there?

If I understand you question corectly, you are asking how is {,5} better
than 5? Note that I do allow the user to type either one and I also
allow him to type {,{i,5}} if it suits his fancy. It all depends on what
degree of clarity we need, if the user can solve his problem with 5 then
use 5, if he has greater need of specificity about what he is doing then
use {,{i,5}} when appropriate. You say that different things should look
different and I am merely saying that like things should look like. It
IS a difference of semantics. You feel that integers, reals, complex
numbers and matrices are different types of entity and should look
different. I say these are all LIKE entities because they are all
subcategories of a general matrix ergo the {} notation. An integer looks
like 5, a real number like {r,3,4}, a complex number like {,2,3}. From
complex number up to a general matrix my notation is no different really
than normal representations, it is really only my real number notation
that looks funky - but then it starts with an "r", it looks different.
Fine, allow the user to write a real number as 32.33, but also allow him
to write it as {r,3233,2} when and if needed. We would have to change my
period to a semicolon to avoid confusion of course, or eliminate notion
of ordering completely.

jeremydunn@ibm.net