At 2:56 PM -0600 on 6/17/99, Scott Raney wrote:
>This topic came up before, and I think the concensus was that we were
>going to allow it in a couple of other places too:
>local somevar = "some value"
>constan someconstant = "some value"
And my proposal would be the same. Also, the 'delimiter=' comes out of a
natural simplification of the 'delimiter is' syntax.
>> Same here. This looks like someone using the "or" operator to assign a
>> boolean expression as the delimiter. With a command like "answer" this is
>> tolerable, as there it occurs only in a very limited scope, but with nested
>> chunks and all that, code becomes unreadable if one intermingles boolean
>> expressions and chunks. Please, don't do it.
>
>Agreed. Though something like this would be nice to have.
I look forward to an example where this does become confusing. However,
this uses or just like we do in everyday languages. And unless we want to
do something stupid like forcing everyone to learn mathematical set
notation, there is not much alternative.
>This syntax is fine and works in MetaCard too. I am intrigued by the
>regex proposal, but I think as long as you're doing regex, using the
>matchText() function with parenthesized subexpressions should do the
>trick.
It's there mainly to show extensibility. But it would make some things
easier. For example, finding sections of HTML documents. Let's say you want
to check links in HTML:
put item x (delim=regexp "<a href=(.+?)� .*?>.*?</a>") of HTML...
where � (option-R, borrowed from MPW) comes after the subexpression
which is the item.
Of course, regexp's would be slow in long lists...
