Chunk order must be small to large

Richard Gaskin ambassador at fourthworld.com
Fri Mar 13 11:58:03 EDT 2009


Ben Rubinstein wrote:

 > Richard Gaskin wrote:
 >> I went to the mat with him over this one years ago when I was
 >> porting an HC project.  He said, "If you need a custom behavior,
 >> use a custom name."  I said, "But I *need* to override the
 >> built-in function!" and he asked simply, "'Need'? Why?"  I
 >> couldn't think of a truly necessary case.
 >
 > "Truly necessary" is never going to be a really objective measure,
 > and hence is not an easy threshold to meet.

True, and it may actually be impossible to meet, at least in a purely 
logical sense.  In law, civil cases have the lower threshold of 
"preponderance of evidence", while criminal cases use "beyond a 
reasonable doubt".  But even criminal cases don't require absolute 
proof.  The closer a logical threshold approaches an absolute, the less 
likely it is that it can be satisfied.

While he was fond of terse phrases like that, in practice my discussions 
with Raney about languages features were guided by a more pragmatic 
principle:  "Is it worth it?"

Most things in computing involve trade-offs, often of memory vs. speed, 
and in the case of supporting all of HypeTalk's options it's more of 
flexibility vs. speed.

Rebecca Bettencourt recently shared this valid HyperTalk example on the 
HC list:

   put empty into a
   put "a b c" into item
   put 1 into char
   put 2 into word
   if true then repeat with word char of item = char char to word of word
   char of char to word char to char of char char of word
   answer a&&"HyperTalk is a bitch to parse
   end repeat else beep

She also included this note with it:

   [The fifth line (if true then repeat with...) is really long and
   may need to be unwrapped. The sixth line (answer a...) has no
   ending quote, but have no fear.]

No ending quote?  Hmmm....seems odd to me, but I trust her judgment here 
as she has far more experience finding the boundaries of HyperCard's 
interpreter than I do.

To fully support HyperTalk would require allowing syntax like that to 
compile and execute.  For myself, and perhaps Dr. Raney, I don't see 
that as a desirable goal at all, even without taking into account the 
impact it has on execution speed.

But once we consider how much faster an engine can be once the parser is 
pruned down to expressions that are more valuable, it seems an even 
simpler choice to just say no, moving the gun so that it no longer 
points at the programmer's foot to a more useful target.

With overriding built-in functions, I agree with his edict that "if you 
need a custom behavior, give it a custom name".  It just makes the code 
more transparent; I've hated doing maintenance on someone else's code 
where they overrode built-in behaviors in ways that were concealed from 
the reader.  Using custom names for custom behaviors makes it 
self-evident that it's custom, right in the context where it's called, 
without having to do a search across the code base to see if an 
overriding handler may exist.

With using built-in tokens as variables, Ms. Bettencourt's exaample 
illustrates everything we might want to say. :)

With chunk order, requiring parentheses not only allows Rev to handle 
many of the expressions we might enjoy in HyperTalk, but also helps 
guide the eye when skimming code.

I'll admit I'm a bit fond of parens and use them where they aren't even 
necessary, in things like:

  if ("dev" is in the environment) AND (the optionKey is "down") then

Parens can aid skimming.  Code is far more frequently skimmed than read, 
so anything that helps the eye move quickly to what it's looking for is 
valuable two years later when you need to go back to enhance a feature.

Sure, these are all limitations, restrictions over what was originally 
implemented in HyperTalk.

But when we ask, "Is it worth it?", just benchmark compatible scripts in 
both HC and Rev:  Aside from a very few specific actions (HC's patented 
search algorithm is hard for anyone to beat), Rev's performance is often 
faster.  And not just two times or three times faster, but in some cases 
by orders of magnitude.


 > ... a simple statement, legal in the syntax, which crashed Rev
 > with 100% reliability shouldn't be marked "critical"  because
 > it could only affect the programmer, who should know better.

What statement is that, and has it been fixed?


 > So I'm not suggesting any of the following would have got you off
 > the mat.  However, here's a couple of cases:
 >
 > * Relating to a recent discussion: I'd quite like my IDE extensions
 > to override "answer" with a version that always had a special
 >'emergency exit' control, which would cause it to exit to top in
 > the thread that invoked answer.

Agreed on it's usefulness, but overriding the answer command seems a 
workaround to a deeper issue:  "exit to top" isn't honored when called 
from within any modal dialog.
<http://quality.runrev.com/qacenter/show_bug.cgi?id=294>

If we address that root issue and added support for Cmd-. to invoke it 
in that dialog (at least within the IDE), the "answer" command itself 
would be fine.


 > * RevBrowser responds to a javascript alert in the hosted page by
 > invoking 'answer'.  I'd really like to trap this - currently I can't
 > see any way to do so.  If I could override "answer", I'd have a
 > method.

Custom-handling the JS alert sounds very valuable indeed, and while I 
haven't done much with RevBrowser thus far I will be later this year and 
may need that myself.

I wonder if this might be handled well with a property, maybe something 
like "the JSAlert", which would let you assign any command in your 
stacks to handle JavaScript alerts.  If left empty, the current behavior 
would remain.

Do you have a RQCC request for this?


 > ...but really I'm playing devil's advocate: I'm very happy with the
 > trade-offs Scott Raney made that give us blazing speed.

Amen, brother.  I loved it when C++ Journal wrote a review of my 
Rev-build WebMerge app in which they mistakenly said it was written in 
C. :)  I wish I could take credit for that, but its performance has more 
to do with Raney pruning the token table than my scripts.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com



More information about the use-livecode mailing list