Clear Semantics for '+' with mixed types

["Peter J. Wasilko, Esq." <address@hidden>]

Greetings All

> > Is it? What's wrong with 1 + "3" producing 4?
> 
> Wow... That just makes me cringe... And sets off my "perl proximity"
> alarm. By the same token, why not have 1 + "3" produce the string "13"?

Really we should add 1 to the Unicode character value of "0033" yielding "0034" in a numerical context and the glyph "4" in a textual one.

Numerically, you'd have an addition, and textually the '1 +' would give you the semantics of a successor function for well ordered character sets.

As for the alternative of "13", I think it illustrates that the same operator shouldn't be overloaded with both addition and string concatenation unless you add some prefix syntax to control the semantics of its subsequent uses within a given statement, this would have the effect of reducing + to a simple list constructor role internally and make the overall statement closer of a Scheme form.

If I decide to incorporate a facility like this in the Clear end user programming language that I am working on at The Institute for End User Computing, it might take shape along the following lines:

[Concrete Syntax Example * Desired Semantics -> Abstract Syntax of Parsed Example => Evaluation Results]

-----------------

1 + "3"

* Given no context and mixed types, build a list and  maybe raise an "observation" of possible programmer confusion, this would fall short of throwing an exception that would have to be explicitly addressed or ignored in the source code, and would instead flag the development environment to consult its user model and either ask for clarificiation or assume that the programmer knew what he was doing and wanted to use + as a shorthand list constructor. More importantly, + plays exactly that role in the more explicit cases.

-> (listof 1 "3")

=> 1 and "3"

-----------------

add 1 + [3/4 represented as the single Unicode character 00BE] + 2 squared [where the symbol squared is a post fix numerical operator] + five

*   If all parameters are numbers, functions returning numbers, or unquoted numerical glyphs  and cardinal numbers they should be evaluated to the numbers they represent. (ie. unquoted numerical glyphs, functional applications evaluating to numbers, and unquoted textual names of numbers *should be treated as numbers* in the context of add)

-> (add 1 (value-of(glyph(00BE))) (square 2))

=> 10 3/4

-----------------

add the number 1 + "3"

*   Given mixed types, treat them as character glyphs and add their values unless a number is explicitly identified as such; generate a type error if a quoted term can't be evaluated to a single character since this mode would be about iterating over character sets and performing simple substitution cyphers. We do this because it would be illogical for the programmer to have explicitly quoted the numerical glyph if all he or she wanted was to add the value it represented.

->  (add 1 (symbol "3"))
        
=>  34 

-----------------   
    
add the numbers 1 + "3"

*   Reduce numerical glyphs and applications to the values they represent; throw an error for other glyphs, handle fractions and math constants gracefully, ignore superfluous quotations of numbers and numerical glyphs (eg. "3" is 3).

->  (add (number 1) (number "3"))
        
=>  4
        
-----------------   
 
concatenate 1 + "3" + four (or more explicitly: concatenate the strings 1 + "3" + four)

*   Treat terms as strings an append them; accept any term that evaluates to a string.

->  (concatenate (string 1) "3" (string four))

=> "13four"

----------------- 

concatenate the numbers 1 + "3" + four

* Treat terms as numbers and append them; all terms must have numerical interpretations.

 => '134'
 
 -----------------
 
 Note that all of these variants follow a simple pattern:
 
 <Semantics of Plus (ie. Add or Concatenate)> <Term Inerpretation Semantics (ie. as numbers or characters)> <The List of '+' Delimited Terms (ie. individual numbers, glyphs, function applications, or strings)>

This is a slightly more verbose approach than Perl's, but the goal is to save the programmer from having to memorize implicit parsing semantics by by factoring out key concepts and surfacing them as an explicit part of the code.

So for Guy's latest example, there could be a "This code is written using German and Chinese Cardinal Numbers" directive at the start of the file. But localizing the parser is left as an exercise for the reader.

Regards,

Peter


_________________________________________________________________

Peter J. Wasilko, Esq.
     J.D., LL.M.               

Executive Director, The Institute for End User Computing, Inc.

Visit us on the web at: http://www.ieuc.org

_________________________________________________________________

Its time to abandon brittle architectures with poorly factored
interfaces, gratuitous complexity, and kludged designs dominated
by sacrifices on the altar of backwards compatibility.

Such artifacts are vulnerable to cyber-attack, weigh down the
economy costing trillions of dollars in lost productivity, and
suffer from an impoverished conceptual model that lacks the
integration and elegance needed to empower end users to
get the most from advanced applications in the future.

_________________________________________________________________
The Institute for End User Computing --- Pursuing Secure, Simple, 
   Supple, & Sophisticated Systems to Unlock Our Human Potential
_________________________________________________________________

* The Institute is incorporated under New York State's
   Not-For-Profit Corporation Law