[Zope-dev] Re: TALES idea: tuple unpacking

[Jim Penny]

On Wed, 30 Jul 2003 15:59:47 -0500
Evan Simpson <evan@4-am.com> wrote:


> Several of your objections/suggestions involve the distinction between
> a string and a name, as in:
> 
> > x/index:'foo'  -->  x['foo']
> > x/index:span_of_int  ->x[span_of_int]
> > x/index:foo    --> x[foo]
> 
> I'd rather not introduce additional punctuation (quotes or parens)

But you've already crossed the Rubicon, :, ',', and % have been
introduced as punctuation (yes, not matched, which does make a
difference)!  I am not opposed to this idea, per se, I am worried about
the fact that it is so slippery slopish, and that it is so non-standard
notationally.

As a add-on product, I would say, go for it!  As core functionality, it
worries me.

Further, this is an engineering trade-off.  You are trading parsing
simplicity by requiring extra programmer awareness - things which a
python programmer is often not consciously aware of.  I am trying to
strongly point this out, so that you are prepared for the inevitable
confusion later.

> if I can help it -- TAL and TALES both have a tradition of
> minimalist syntax, and it keeps parsing simple.  Also, as soon as you
> add delimiters, you add quoting issues, and TALES has enough of those
> already.
> 
> > call: well, you have said that arguments are allowed, and must be
> > only variable names.  What is the reason for this?
> 
> To keep things simple.  There's a clearly visible slippery slope here,
> 

Yes, but named parameters can be very nice, especially working with
databases, they let you match between form names, which are often very
specific and database column names which are often more generic.

And permitting constants keeps the programmer from an artificial
requirement to define bind a constant to a name just to use it in a
conditional section.

I do understand the parsing issues, and can accept them, although I
really would prefer named parameters be available, even if I have to
give up constants.

I strongly would urge you to use parentheses to denote functional
application.  Yes, I know there are alternative traditions, but they are
much less common in practice.  And the strongest one, RPN, was widely
hated by 'the masses'.

> > Does using call: explicitly erase all magic name bindings  (I hope
> > so)?
> 
> I don't know what you mean, here.
> 

Well, grabbing missing parameters from request, and possibly (zope2)
other places.

> > fmt: is most irregular.  First, it reverses the pattern of all the
> > others and makes the stuff to the left the parameter.  This may be
> > OK for your intended audience.  It may also confuse them totally. 
> > Why x/fmt:%.2f and not x/fmt:'%.2f'?   As it stands, it takes either
> > expression fragments starting with % or function names.  Can I
> > define my own functions, if so, how/where?
> 
> 'fmt' is a quick-and-dirty implementation, and most likely to change. 
> It was almost certainly a mistake to conflate the standard formatting 
> functions with Python string formatting.  I don't agree that it
> reverses the pattern, though -- to me, it's "apply *this* formatting
> operation to the current object", much like 'key' is "fetch *this* key
> from the current object".

well, even if you persist in the mistaken ;-) notion that it is
written key:
x/key:y  --> x[y]
x/call:y --> x(y)
x/fmt:y  --> y(x)

'one of these things is not like the others...'

> > Finally, can we come up with a better term than prefix.  In
> > conventional terminology, most of these are infix operations, except
> > call, which may be a purely postfix.
> 
> 'prefix' refers to the syntax, not the operations.  In my source code 
> comments, I refer to "prefixed path elements".  A better name would be
> welcome :-)

Hmm, maybe 'decorated path'.  I am worried that prefix, postfix, and
infix already have meaning, and this is more an infix language than a
prefix language.

But, I lost on 'snake thingy', so I will lose here to  :-(

Jim Penny