Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ll-xn!mit-eddie!uw-beaver!cornell!batcomputer!mab
From: mab@batcomputer.tn.cornell.edu (Mark Bodenstein)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: numeration problem
Message-ID: <3809@batcomputer.tn.cornell.edu>
Date: 22 Feb 88 00:36:02 GMT
References: <1372@runx.ips.oz> <7451@apple.UUCP>
Reply-To: mab@tcgould.tn.cornell.edu (Mark Bodenstein)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 33

In article <7451@apple.UUCP> winkler@apple.UUCP (Dan Winkler) writes:
> ...
>  go card one    -- will go to card number 1

But,
   go card "1"    -- will go to card number 1,
                  -- even if there is a card named "1"

This ambiguity is unfortunate and unnecessary.  The syntax could have been
   go card number <number>
or
   go card num <number>
for this variation on the go command, reserving
   go card <name>
for going to a card based on its name.

Was there a reason for this, or was it an oversight?

In general, I think HyperCard is a great idea, and that HyperTalk has some
good design ideas and design choices built into it.  I have found actually
working with it to be disappointing, though.  There are too many "gotchas",
and there are too many things that should be easy to do but aren't.  It gives
the impression of being a good draft of a language (and similarly HyperCard
as a product), but not there yet.

If I got a vote, I would vote for a future version of HyperCard fixing all of
these design problems, even if previously written stacks no longer worked.  I
think that this is necessary if HyperCard is to become the tool that it can
and should be.  I further think it is early enough in the product life to take
such a step, and will be for some time yet.
-- 
Mark Bodenstein                  {ihnp4,rochester}!cornell!batcomputer!mab
                                 mab@batcomputer.tn.cornell.edu