set rect of fld f1 of cd c1 of wd w1 to rect of fld f2 of cd c2 of wd w2

[Mark Waddingham]

> >   repeat while(x+1) < 10
> >   put word(x+1) of "This is a test"
> >
> >Although this is consistent, it still *looks* wrong to me... it looks like
> >"while" and "word" are functions in the example above. Is it just me, or is
> >this a bug that has been in the engine for a long time?
> 
> Well, it's been in the engine a long time. I'm not sure I'd 
> categorize it as a bug, per se... more of a "forgiveness" feature of 
> the parser. This kind of forgiveness appears in other areas too - for 
> example, you can write "firstVar&&secondVar" with no spaces, or "get 
> rect of field 1" (with no "the") and it will work.

Indeed, the engine is a little too forgiving in places but there are
actually two separate issues here - one related to tokenisation and one
related to parsing.

In regards to things such as "firstVar&&secondVar" and "word(x+1)" then
this is quite standard in the way the first step of parsing
(tokenisation) is performed. In any language's character-set a certain
set of characters will be defined as 'delimiters' that always terminate
a previous token and begin a new one. In transcript the delimiters are
(more or less):
  { | } ~ ^ [ \ ] ; : < = > / * ( ) & % # " ! <space> <tab> <cr> <lf>
  [ + plus a few high bit-set 'Mac' characters which I can't type in
Linux ]

All of these delimiter characters are considered tokens in their own
right except:
  - " which starts a string
  - # which starts a comment until the end of line
  - '--' which starts a comment until the end of line
  - /* which starts a comment until */

After splitting up by these delimiters the engine throws away all white-
space (<space>, <tab> and <cr>) and comments and is then left with a
sequence of tokens.

This means that a string such as:
  word(1+tVar[100])of("abc def ghi")
is split up as:
  'word' '(' '1' '+' 'tVar' '[' '100' ']' ')' 'of' '(' '"abc def ghi"')'


The 'the' issue is slightly different as this is do with a later stage
of processing - that of parsing (where the stream of tokens is built
into the actual commands and functions to be executed). This is a
particular case where the engine is a little lapse in making a noise
(historically this was to help enable porting SuperCard and HyperCard
stacks to Revolution).

Indeed, I am reliably informed that Scott Raney always used to
periodically remind people to always use 'the' as a prefix for property
accesses and I will continue this trend: please always use 'the'.
Indeed, caveat-those-that-do-not-use-the-the :o)

Just to clarify, 'the' should always be used when accessing properties
(it is already mandatory when using the property syntax form of engine
functions). So you should write:
  set the cCustomRect of me to the rect of me
*not*
  set cCustomRect of me to rect of me
And you should write:
  put the dontUseQT
*not*
  put dontUseQT


> I think the upside is that the syntax is a little looser, but the 
> downside is that someone may get used to an erroneous way of writing 
> code, only to get into trouble if it gets tightened up down the 
> line....

As Jeanne looks into her crystal ball ;o)

Overall, the engine at present is quite forgiving in what syntax you
give it and this is as much a curse as it is a blessing. My general
advice is to always follow the syntax as specified in the documentation
*including* making sure you use appropriate connecting keywords.

[ I'd also hope to convince people to stop using the shortened form of
control type keywords over time but I fear that if I am too vocal about
this I might run the risk of being pummeled with fruit ;o) ]

The motivation for giving this advice is a very pragmatic one: the
tighter the syntax of Transcript becomes, the more powerful it can be in
the future. The eventual result being a great reduction in the number of
lines of code you need to write to solve a particular problem.

Warmest Regards,

Mark.

------------------------------------------------------------------
 Mark Waddingham ~ 36degrees at runrev.com ~ http://www.runrev.com
       Runtime Revolution ~ User-Centric Development Tools