CRM114 script language question: divide operation in maillib

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).



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
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