On Fri, 18 Oct 2013 15:12:36 +1100, Chris Angelico wrote: > On Fri, Oct 18, 2013 at 2:14 PM, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: >> One thing he missed is that there are untyped languages where >> everything is the same type. If everything is the same type, that's >> equivalent to there being no types at all. Examples include TCL and >> Hypertalk, where everything are strings, and Forth, where everything >> are two-byte words. >> >> But I digress. Apart from those couple of little criticisms, I think it >> is a very useful article to read. > > Continuing the digression slightly: If everything's a string, how do you > handle aggregate types like arrays? Are they outside the type system > altogether (like in C, where an array-of-int isn't something you can > pass around, though pointer-to-int is)?
I don't know about TCL, but in Hypertalk, when I said everything is a string, I meant it. If you want a list of strings, you create one big string using some delimiter (usually spaces, commas or newlines). So I might say something like: # it's been a few years, I may have some of the syntax wrong put field "list of stuff" into text for i = 1 to the number of lines of text: get line i of text if word 3 of item 6 of it is "stop" then do_stop() else do_start(word 1 of item 2 of it) Hypertalk uses (almost) natural language chunking: lines are chunks of text separated by newlines, items are separated by commas, and words are separated by spaces. So you can easily implement up to three dimensional arrays: a b,c d,e f g h,i j,k l m n,o p,q r is a list of three lines, each line having three items, each item having two words. (Oh, and there's one more layer of chunking: the character or char. Guess what that does?) Actually, perhaps it's not quite true that everything is a string. Hypertalk also has fields, which are text fields in the GUI environment. Fields have properties such as the textsize and the font, as well as contents, which are strings. There are also buttons, which don't have contents, although some of them can have state like On or Off. There are cards, which contain fields and buttons, and backgrounds, which contain cards, and stacks, which contain backgrounds. So it actually was rather object-oriented in a way, but the objects were completely tied to the GUI environment. You couldn't directly create an abstract field object, instead you treated it like a macro playback and did things like this: choose menu item "New Field" from "Tools" menu set the name of field "New Field" to "foo" set the rect of field "foo" to 25,25,100,200 or if you were really keen, or perhaps foolish: select field tool drag from 25,25 to 100,200 set the name of field (the number of fields) to "foo" Despite its flaws, it was great fun to program in, and the best integrated GUI programming environment I've every seen by far. -- Steven -- https://mail.python.org/mailman/listinfo/python-list