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