tenaglia@mis.mcw.edu (Chris Tenaglia - 257-8765) (03/22/90)
I've noticed in the Icon Newsletter discussion of an object oriented version
of Icon (IDOL?). It makes use of the $ character. Somehow I can never quite
seem to comprehend this 'object oriented' stuff. It looks like kloojed
terminology.
But back to the $.
I wonder about the use of the $ to create user define operators. For example:
operation("$+",lst)
case *lst of
{
1 : return &null # unary form not defined
2 : return lst[1] || " " || lst[2] # binary form ok
}
end
Later ...
a := b $+ c # 'a' is 'b' appended with a space and then 'c'
d := $+e # unary form should fail or be &null
x $+:= z # augmented form appends blank and 'z' to 'x'
Is this a desirable 'feature' for Icon 8.2 or 9.0? Or would it be impractical?
Chris Tenaglia (System Manager)
Medical College of Wisconsin
8701 W. Watertown Plank Rd.
Milwaukee, WI 53226
(414)257-8765
tenaglia@mis.mcw.edutenaglia@mis.mcw.edu (Chris Tenaglia - 257-8765) (03/27/90)
In response to a response to my posting,.... > > But back to the $. > > > > I wonder about the use of the $ to create user define operators. For example: > > > > operation("$+",lst) > > case *lst of > > { > > 1 : return &null # unary form not defined > > 2 : return lst[1] || " " || lst[2] # binary form ok > > } > > end > > > > Later ... > > > > a := b $+ c # 'a' is 'b' appended with a space and then 'c' > > d := $+e # unary form should fail or be &null > > x $+:= z # augmented form appends blank and 'z' to 'x' > > > > Is this a desirable 'feature' for Icon 8.2 or 9.0? Or would it be impractical? > > Wouldn't general operator overloading in Icon be better? Yes, I gave some thought to overloading some of the existing Icon operators. I had had some classes in ADA language which permits this. However, as a group of programmers (40 of us) discussed it. The thought that + could be * or - made us nervous. A language such as ADA is very strict about DATA TYPES, and for it NOT to be strict with the OPERATORS seemed sort of inconsistent. My icon background gives me the philosophy of typed operators as well as (loosely) typed data/procedures. It seems more natural to keep the user defined objects (operators, procedures, variables) separated from the built in ones. This is only my opinion, and it may not line up with the goals of the Icon project in the long run. Chris Tenaglia (System Manager) Medical College of Wisconsin 8701 W. Watertown Plank Rd. Milwaukee, WI 53226 (414)257-8765 tenaglia@mis.mcw.edu
nowlin@iwtqg.att.COM (03/27/90)
> In response to a response to my posting,.... > > > > But back to the $. > > > > > > I wonder about the use of the $ to create user define operators. > > > > Wouldn't general operator overloading in Icon be better? > > Yes, I gave some thought to overloading some of the existing Icon operators. > > ... > > My icon background gives me the philosophy of typed operators as well as > (loosely) typed data/procedures. It seems more natural to keep the user > defined objects (operators, procedures, variables) separated from the built > in ones. This is only my opinion, and it may not line up with the goals > of the Icon project in the long run. > > Chris Tenaglia (System Manager) I can't remember if Bill's object oriented Icon has operator and function overloading or not. This is my two cents worth and if I've got it all wrong I trust someone will let me know. The language that has overloaded operators that I'm most familiar with is C++. It discriminates between overloaded operators (functions) by enforcing strict typing of operands (arguments). This is how the compiler determines which operation to perform on the operands. Operators can appear to take on almost any type for the programmer working with well defined C++ classes. Icon, on the other hand, has operands or variables that can be any type. To discriminate between different types of operands Icon uses fairly strongly typed operators (and functions). There are exceptions (assignment) but for the most part the operators in Icon are type specific. I know this because of all the run time errors I generate. You get a great deal of automatic type conversion in Icon but it's driven by the operators more than the types of the operands. You can add two strings of digits in Icon with the "+" operator but you get a numeric result, not a longer string of digits. You can also concatenate two numbers into a string of digits with the "||" operator. To allow overloaded operators would violate this scheme. How would Icon know whether to do automatic type conversion or try for another version of the operator that was a better fit to the given operands? Someone with experience in the implementation could shed more light on this. User defined operators that are distinguished from built-in operators by an explicit syntax are the best compromise but there are an awful lot of operators in Icon already. Procedure names can be very descriptive. (hint) Jerry Nowlin (...!att!iwtqg!nowlin)
kwalker@CS.ARIZONA.EDU ("Kenneth Walker") (03/28/90)
> Date: Mon, 26 Mar 90 23:15 CST > From: nowlin@iwtqg.att.COM > > You can add two strings of digits in Icon with the "+" operator but you get > a numeric result, not a longer string of digits. You can also concatenate > two numbers into a string of digits with the "||" operator. To allow > overloaded operators would violate this scheme. How would Icon know > whether to do automatic type conversion or try for another version of the > operator that was a better fit to the given operands? Someone with > experience in the implementation could shed more light on this. "+" does give a numeric result, but numeric is either integer or real. The decision about whether to do integer arithmetic or real arithmetic is made at run-time. If you could replace "+" with with your own operation and somehow invoke the old "+" within your operation, you could get the effect of overloading. Assuming the function old_op() gets you the built-in version, the following operation would enhance "+" to do pair wise addition of lists. operator +(a,b) if type(a) == type(b) == "list" then { r := [] every i := 1 to *a do put(r, old_op(a[i], b[i])) return r } else return old_op(a,b) end I don't necessarily think being able to arbitrarily redefine operators is a good idea. It leaves you with too few features in the language whose meaning you can "trust" while reading a program. The idea of being able to add new operators does not have this problem. However, no one has brought up the problems of precedence and associtivity. Does a $- b - c mean (a $- b) - c or a $- (b - c)? You need something in your definition of an operator to deal with this. Currently, the organization of icont does not allow you to add new operators. With the tools we use to make icont, it is possible to organize a translator so that adding new operators can be done, but you must decide on a fixed set of precedences. If you decide "+" is at precedence 12 and "*" is at precedence 13, you will not be able to add operators with intermediate precedences. If you fix them at 12 and 15, you are limited to 2 levels of precedence between them. To get around these problems (which are not particularly serious), you would need a different kind of parser within icont. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker
gudeman@CS.ARIZONA.EDU ("David Gudeman") (03/28/90)
Date: Tue, 27 Mar 90 09:45:16 MST From: "Kenneth Walker" <kwalker> ]I don't necessarily think being able to arbitrarily redefine operators ]is a good idea. It leaves you with too few features in the language ]whose meaning you can "trust" while reading a program. Ken is doing research that involves optimization of Icon programs by doing static analysis of the programs. Obviously this gets harder as more things become dependent on run-time conditions. Perhaps this is slightly effecting his opinion? ;-) There is an important advantage to overloading operators, though. Suppose you write a calculator program. Of course, inside this program you use mathematical operators. Now suppose you decide to upgrade the program to use complex numbers. You can't just define a new type and write functions to operate on complex numbers, you have to go through the entire program and replace every arithmetic expression such as ``a + b'' with ``add(a,b)'' (if it is in a position to take complex values for ``a'' and/or ``b''). Ick. If you could overload Icon's built-in operators, all you would have to do is overload the arithmetic operators so that they understood complex numbers. I can think of similar examples for non-numeric applications. Someone objected that this lets you do strange things like define + to do subtraction. True enough. But honestly, if a programmer is that determined to make write an unreadable program, he can do it just as easily without operator overloading. There is nothing the language designer can do about obtuseness of programmers, and it seems pointless to try.
poser@csli.Stanford.EDU (Bill Poser) (03/28/90)
In article <9003271919.AA00259@megaron.cs.arizona.edu> gudeman@CS.ARIZONA.EDU ("David Gudeman") writes: > >If you could overload Icon's built-in operators, all you would have to >do is overload the arithmetic operators so that they understood >complex numbers. I can think of similar examples for non-numeric >applications. > >Someone objected that this lets you do strange things like define + to >do subtraction. There is an intermediate approach available in object-oriented languages as well as in languages like ML that provide disjunctive procedure definitions. Implement operator overloading as ADDITION of methods for new data types, but don't allow pre-defined methods (i.e. the built-in operators) to be removed. This guarantees that an operator will have the expected semantics when applied to built-in data types and reduces the uncertainty to derived types.