Re: CRM114 script language question: divide operation in maillib

   From: "Ger Hobbelt" <[email protected]>

   Hi, it's me again, the Central Scrutinizer.

   This time, Mary's on to crm114 script language appreciation.


   In maillib.crm it says @ ~ line 163:

	       eval /:@: :#:m_text: < (:*:decision_length: / 4) :/

      Shouldn't this read:

	       eval /:@: :#:m_text: < (:*:decision_length: \/ 4) :/

      (note the 'divide' being escaped in there)

   Vanilla BillY copes with both.

   GerH 196x reports a compiler error for sample #1.[1]


   Q: Is the first sample legal CRM114?

      Your Verdict, Your Graces?


   Hint: QUICKREF.txt is lawyer stuff here, at least for non-native
   English speaking curmudgeons like me. I quote:

    \      - '\' is the string-text escape character.  You only _need_ to
	      escape the literal representation of closing delimiters
	      inside var-expanded arguments.


   The debate:

   Of course, which arguments are var expanded is well documented (all of
   'em? or are there exceptions?), but I still have a gripe: it seems, at
   least from QUICKREF, that /.../ is always var-expanded. And how one
   should go about parsing delimiters that aren't when in a
   non-var-expanded, yet delimited, context...

   Which means, according to docs and _my_ interpretation of such, the
   former is incorrect and should not be accepted by CRM114.

   ... One bible, so many religions.

   However, the fact that a smart scanner might recognize that the '/'
   divide operation is located _within_ a :@:...: match expression, and
   assuming any :?:...: expressions are properly closed - as they should
   - the first version just _might_ make it legal. One can plead the
   advantages of 'Minimalistic Escape-ing' or some such.

   Nevertheless, IFF I'm right and it's illegal due to the lack of an '\'
   escape within the var-expanded // argument there, that means it's just
   another fluke that needs fixing?

   If I'm _not_ (50% chance there), that means I have some work to do on
   the new scanner/parser still... because it'll need some extra 'smart'
   for recognizing nested :?:...: elements inside //[]()<> delimiters.
   Bummer. :-(

   [1] Probably because the bloody bastard rewrote large sections of the
   scanner/parser, so he'd have some improved error checking and stricter
   language grammar adherence, and hopefully more readable and faster
   too. Forget the American Buffalo (bison).


You are correct, the first is not legal, and should get an error (and
it does get several), at least on my machine.

It's rules-lawyering, but the parser and compiler are "smart"
in that they remember what kind of delimiters a string is using
and require *that* delimiter to be used to close the string.

Thus, you're in a "/"-delimited string, and so embedded "/" needs
to be escaped.

(this is one of the few places I regret using / as a delimiter).

And yes, that would be a bug in maillib.crm.

And yes, it is now fixed in the WGET.  

      - Bill Yerazunis

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace