Python was designed (was Re: Multi-threading in Python vs Java)

Steven D'Aprano steve+comp.lang.python at pearwood.info
Fri Oct 18 00:45:48 EDT 2013


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.python at 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



More information about the Python-list mailing list