Re: Updated openformula spec posted!

["David A. Wheeler" <dwheeler@dwheeler.com>]

David A. Wheeler wrote:
> > Jody Goldberg said, "I like the $$ prefix for names, that's a nice disambiguator" -
> > that makes me happy!
> 
> Huh? I missed that, where did it come from?!?

The optional '$$' prefix was discussed recently
in earlier mailing list discussions on named expressions.
It was part of the discussion on ensuring that named expressions
can be attached to individual sheets, as well as globally, and subtables.
These were TODOs on the original syntax we never got around to handling.
Addressing them forced me to re-examine the named expression syntax,
and to make tweaks to resolve them.  I made my best shot at trying to resolve
these gracefully; there have been several emails on the topic.
It's a proposal; you can blame me for it :-).
I really want your feedback on it!

Check your spam box; several messages have been caught in my spam filters,
and they may have been caught in yours.
My guess is that's because OASIS' old approach to the public comments
section turned it into a spam sender. OASIS has since changed that, but
my learning filters take time to UNlearn things.

> I see that it might be
> good as a disambiguator, but such things will ensure that no current
> version of applications supporting ODF already will be able to read the
> new ODFF formulas.

No, there's no such problem, it's completely backwards-compatible.
The '$$' is not required for typical circumstances of id's in
current use.  If you don't follow it with "(",
and you use normal ID characters, then it's
still interpreted as a named expression id.  So this is fine:
   TestDB
as a named expression id.

Although we don't have any requirements on user interfaces, it
turns out to have very nice properties as a disambiguator for
most UIs too.  E.G., A1 is a cell, as is $A1, but $$A1 is a named expression.
At the end of the syntax section are some notes about user interfaces...
I tried to make sure that a "simple" user interface was ACTUALLY simple.

Applications may have to make at a change for openformula, anyway:
they'll need to accept formula attributes starting directly with "=",
instead of (say) oooc:.  I suspect many apps ALREADY do that,
but I'm not certain.  Has anyone tested?


> Also:
> 
> | If NamedExpressions are later extended to permit calling them like
> | functions, then the NamedExpression must be preceded by the $$ marker
> | in such cases  otherwise, it would be considered a traditional function
> | call.
> 
> I don't see that. A function call always implies some identifier/name
> followed by an opening parentheses. No parentheses => named expression.
> Or was there some discussion to later enhance named definitions to take
> parameters?

Yes.  Calls to named expressions are not
actually IN the syntax definition, but the notes discuss
that as a probable future extension.  I believe we've talked about that
before, as this is one way to get some macro capabilities SAFELY
included in the format.  I think it's worthwhile to make sure
that we CAN extend into future, without troubles. Also, I'm concerned that the
syntax itself should VERY flexible it what it can represent.  Without
an escape mechanism, we risk getting blindsided by some application
that allows all sorts of weird characters in named expression id's
and causes us trouble, intentional or not.

> > I intend to tell the TC next Monday "please take a look at the syntax".
> Well, TC can for sure take a look, the more eyes the better, but I don't
> think it's ready. Or at least it is that I haven finished playing
> catch-up ...

I agree, I don't think we SHOULD present it to the TC as "it's done".
In particular, I'm not convinced that the automatic intersection stuff has
really gotten a good scrub. We have a syntax for 3D inline arrays, but
I'm not sure that anyone's really clamoring for them; perhaps they should go away.

But I really want more eyes on it, so we CAN get to the point where
we can say "it's done".  Showing the current state to the TC seems
like a reasonable way to get there.  I _definitely_ want your eyes on
this... but you've been understandably very busy recently.

Speaking of backwards compatibility: so far there's been no
rule so far REQUIRING that all function names will be necessarily
identical with OOo.  In the VAST majority of times
they WILL be the same (SUM is SUM, MAX is MAX, ...), if for
no other reason than EVERYONE has the same name.
Which means for practically all spreadsheet docs, there's no difference.
But we CAN distinguish the case between oooc: and =, so we do
not HAVE to do that in all possible cases.  In particular, there
a few functions with "similar but not identical semantics" between
applications, where to support users we need BOTH functions.
So how do we choose the name for each?  We need to discuss
that.  We can do this in parallel; there's no problem in
defining what a function DOES and in parallel deciding its spec name.

--- David A. Wheeler