Re: [office-comment] Conceptual Problem: Ambiguity for Names usedin Formulas

[Leonard Mada <discoleo@gmx.net>]

Hello David, dear list-members,


David A. Wheeler wrote:
> Leonard Mada:
>   
>> Thanks for the clarification.
>> Though, a small nitpick if I am allowed: 
>> Cell references are marked/surrounded by: [...]
>> I wonder IF a proper tag wouldn't be more future oriented.
>> Something like:
>> <ref>....</ref>
>> and
>> <name>...</name>
>> (or something similar)
>>     
>
> We don't want to do that SPECIFIC thing.  These are contained as
> attributes inside an XML file, so using XML markings would probably
> be confusing.  In any case, it's not needed.
>   

Well, references are currently saved as '[...]', but I would like to see 
more vector-capabilities in spreadsheets.

Now, unfortunately square brackets ('[...]') make an excellent way to 
access vectors (or series, arrays and all the fun stuff). So, there 
might come a time, when even spreadsheets will want to have such an 
operator. Of course, then it becomes necessary to store references 
differently [storing is necessary, because otherwise it might conflict 
with named ranges & expressions].

Also, I already proposed some time ago to implement strong typing in 
spreadsheets and a lengthy discussion did ensue. Strong typing will come 
at some point.

This creates the requirement to store the unit, so any value will have 
some tags associated with it. Arguably, named ranges/expressions could 
be evaluated at run-time, but it would be more efficient to store the 
unit. While this does NOT directly support my request, IF you already 
have to store a specific tag, why NOT have tags even for the named 
ranges/expressions in the first part?

And then, why use a hybrid store-mechanism, and why not store everything 
as pure xml?
[I do not understand much of xml, I'll let the experts work this out.]

My main concern is however a different one. Named ranges/expressions are 
just 2 possible objects. Arguably, spreadsheets did NOT implement 
anything more advanced up to date, but professional programs do exist 
that permit defining more complex objects. And spreadsheets will follow 
at some time, too. [see the S+ language as implemented e.g. in R, 
http://www.R-project.org, and other mathematical and science languages]

I would strongly oppose adding a new identifier (like '[', '{', what 
else? ) for every new type of object.

Sincerely,

Leonard Mada


P.S. I am subscribed to this list, so there is NO need to cc me a copy ;-)

>> Of course, implementations will vary in how they display it on screen, 
>> but ODF should remove any ambiguity and remain open for any future changes.
>>     
>
> There's NEVER any ambiguity in the exchange format:
> * If it's a cell reference, it is ALWAYS surrounded by [...].
> * If it's a named expression, it is NEVER surrounded by [..].
> Most named expressions are simply referred to by name,
> but if you want to begin the name itself with
> '[' or include other "odd" characters, you have to start the name
> with the special escape format "$$" that ALWAYS introduced
> the name of a named expression.
>
> So you just need to look at the first character, and that determines
> whether it is a cell reference or name of a named expression.
> There's no need for special disambiguation rules.
>
> Here's an example, perhaps that will make it clear:
>  A1 is a named expression, whose name is A1
>  [.A1] is a reference to the cell A1
>
>   
>> My 2nd complain is about the default handling of names/ranges:
>>  - IF a named range/expression is defined, then
>>    the user most likely wants to use this named range/expression
>>  - not the reference the string 'points' to
>>
>> Therefore, I would prefer that whenever there is an ambiguity between a 
>> named range and an actual cell/range, the named range/expression be 
>> used. The user wouldn't have named it like that, IF he needs to point to 
>> that particular column.
>>     
>
> Again, there's no ambiguity in the exchange format, so there's
> no need for a rule to disambiguate it.  So if you want to create
> a named expression named "A1", you can exchange it.
> (It's not a good idea, because it could confuse people, but you CAN express it.)
>
> Now for the user interface, the rule you give is
> usually a good idea, and I believe it's what most apps do already.
> But the user interface is out-of-scope for the
> formula spec.  People can (and do) change the user interface.
> In fact, in at least one spreadsheet application
> (Word Perfect's Quattro Pro), the user interface
> is a run-time setting you can change while running the app.
> Function names tend to change based on the locale, too.
> Which is why we've concentrated on the _exchange_ format, and
> not the user interface - there's lots of variance in the user interface.
>
> --- David A. Wheeler
>
>