Paul_Abrahams%Wayne-MTS@UM.CC.UMICH.EDU (11/17/90)
As I mentioned in an earlier posting, I'm working on the design of SPLASH, a Systems Programming Language for Software Hackers. A question came up about how people use Icon's dynamic typing. In Icon the type of a variable isn't determined until you assign something to it, and even then it can change. That's in contrast with other languages of the Algol/Pascal/Ada/C sort, in which every variable has a declared type. My question is: how important is this flexibility for Icon programming, and how do people utilize it? There's one place where it clearly pays off: the possibility of writing a procedure that prints its argument no matter what the type of the argument. The fact that you can't write the C printf function in standard C shows why you want this. But aside from printing arguments and writing out their storage, I haven't been able to think of other operations that use the flexibility. Interestingly, sorting isn't one of those examples, since not all data types have a natural ordering relation and even for those that do, you use different operators in Icon (`<' for numbers, `<<' for strings.) Examples, anyone--particularly from programs that do something rather than just prove something? Paul Abrahams abrahams%wayne-mts@um.cc.umich.edu
gmt@CS.ARIZONA.EDU ("Gregg Townsend") (11/17/90)
I've used Icon's type flexibility a few times to implement traps in
subroutine packages. The paradigm works like this:
(1) call enable() passing an arbitrary procedure p and other object x
along with whatever is necessary to specify the trap conditions.
(2) when the trap condition occurs -- for example, on every 60th
call to an output routine -- p(x) is called using p and x
from the enable() call. Because x can be any type including
a list or record, any desired amount of data can be passed to p.
This is clumsier in C because instead of an arbitrary object x one must
pass a *pointer* to x, with an appropriate cast, and then access the data
indirectly.
To pick a nit, printf actually can be written in standard C, because the
format specifies the expected types of the remaining arguments and there
are standard routines for retrieving them. There are other problems such
as a danger that getc() has been replaced, but they're irrelevant to this
discussion.
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758mgudeman@CS.ARIZONA.EDU ("David Gudeman") (11/17/90)
One important use of dynamic typing is that the type itself gives some information. I write functions all the time where I _usually_ want a return value of a certain type, but on exceptional conditions I want something different. For example # factorial(i) return the factorial of i if i > = 0, # otherwise return &null. You can get much the same effect with exception handlers, but it has a different flavor. Another use is in program developement. The ability to assign different types to variables lets you try things out with fewer changes to a program. At least I think so. Two other features that help in this are polymorphism and automatic type conversions. Since Icon has all three, it is hard to say exactly which feature or set of features is most involved in this. Incidentally, there is no reason that run-time typing and static typing can't peacefully coexist in the same language. I can see two different ways of doing this: the first way is to say that all variables are untyped. This dynamically typed language also has type declarations that restrict the types that can be assigned to a given variable _at run time_. However, a given implementation _may_ give errors at compile time if a given path might lead to a type conflict. Furthermore, the implementation may optimize variables that always have a known type. The other way is to say that the language is statically typed, but that there are union types that carry type information around as a part of the union value. Also, all operators are overloaded so that they operate on the union types by checking the type at run time and doing the right operation. There is a specially named union type "any" that is a union of all other types. One might define that the default type of a variable is "any". Both of these paradigms allow the expressiveness of dynamic typing and the security and efficiency of static typing. In such a language, you can do developement with dynamic types and then "optimize" the program by declaring the types of most of the variables.
ralph@CS.ARIZONA.EDU ("Ralph Griswold") (11/17/90)
I disagree with your characterization of types and variables in Icon. It's not that a variable doesn't have a type until an assignment is made to it, but rather that variables are not typed, but values are. Note that every variable has the null value initially. I realize this distinction may seem a bit strange to persons who are used to languages like Pascal, but if you look at the implementation of Icon, you'll see that's exactly what's going on. A variable is simply a place to store a value, all variables are the same size, as are all values. All values carry an identifying type. As to the usefulness of non-types variables, in my experience, it's mostly in heterogeneous structures. The elements of a list, for example, are variables. They can have different types in the same list. Heterogeneous structures occur frequently in Icon programs. I believe the second edition of the Icon Programming Language points out examples. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@cs.arizona.edu uunet!arizona!ralph
nowlin@iwtqg.att.com (11/18/90)
> than just prove something?
I have three specific examples. The first is the use of the types "null"
and "file" in programs that can read input from files or from standard
input. The same expressions can be used for input if the variable used as
a file is set to &null when reading from standard input. I've used this
many times. The same kind of scheme can be used for output.
The second example is a set of procedures that does regular expression
matching. It uses a list of records. Each record contains a pair of
values; a procedure and an argument to be passed to the procedure.
Sometimes the argument is a string, sometimes it's a cset, and sometimes
it's &null. Icon doesn't care which I store as the second value in the
record.
The third use is a set of procedures I wrote for a friend. These
procedures allow a series of global variables to be dumped into a file. A
complementary set of procedures can read the dump file and reconstruct the
global variables with the same values as the program that dumped them.
These procedures are used to chain together a series of programs. This
would require a whole series of different variables if Icon didn't allow me
to use the same variable over and over with different types each time.
Very handy.
As a side note we've just recently achieved a breakthrough at work (AT&T)
and we're now allowed to use Icon for "real" projects. It's great. Our
methodology calls for code inspections and those of us who are familiar
with Icon initially thought Icon would be much easier to code inspect than
C++ or C. WRONGO! The tie in to this subject is that dynamic typing may
contribute to the problem. It just seems counter intuitive that Icon would
be harder to inspect but after our initial session that was definitely my
impression. I'll try to figure out why on my own but if anyone has any
ideas throw them out.
Jerry Nowlin (iwtqg!nowlin)wgg@CS.WASHINGTON.EDU (William Griswold) (11/18/90)
Re: Jerry Nowlin's message >As a side note we've just recently achieved a breakthrough at work (AT&T) >and we're now allowed to use Icon for "real" projects. It's great. Our >methodology calls for code inspections and those of us who are familiar >with Icon initially thought Icon would be much easier to code inspect than >C++ or C. WRONGO! The tie in to this subject is that dynamic typing may >contribute to the problem. It just seems counter intuitive that Icon would >be harder to inspect but after our initial session that was definitely my >impression. I'll try to figure out why on my own but if anyone has any >ideas throw them out. > To me this suggests that a language in which you could add typing information during later phases of a project would be valuable. Having a tool to infer the types and insert them for you would be great, and could be revealing in itself. In the presence of tools like Ken Walker's Icon compiler, this doesn't sound impractical. This type information serves as constructive comments in the code. Not only does it tell a new programmer what is going on, but type violations created by the programmer's changes to the code will signal that the changes are outside the intents of the original implementation. bill
TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) (11/18/90)
Regarding: Uses of dynamic typing > ... text ... > My question is: how important is this flexibility for Icon programming, and > how do people utilize it? > > ... text ... > > Examples, anyone--particularly from programs that do something rather than > just prove something? > > Paul Abrahams > abrahams%wayne-mts@um.cc.umich.edu Some things are implicitly utilized. Dynamic typing, in my opinion, causes some things. 1. Reduces lines of code, since many variable type declarations become un-necessary. 2. Reduces code clutter from having to cast this type to that in expressions. Although I still find it necessary for floating point calculations. 3. I suppose I'm just a lazy programmer, and when programming in Icon, I'm not fighting the datatypes. I just code away, much like I did when BASIC was my native computer language. 4. No need for separate sets of procedure libraries. Well, I suppose if well designed, C & Pascal can have smart procedures that adapt to the type of data passed. Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia