Feature Proposal: Add missing operators to query search and %IF

Motivation

There are a number of things that are difficult to do in queries because of missing operators. For example, finding all topics where a form field has one of a range of values.

Description and Documentation

This proposal is informed by the operators that exist in SQL. It is a design decision that no operators will be created that cannot be mapped 1:1 to standard SQL ops.

INT	Unary, truncate floating point to integer
div	Floating-point division
-	Subtraction (and unary minus)
+	Addition (and string concatenation if one or both arguments are not numbers)
*	Floating-point multiply
IN	Check whether a value is within a set of values (bracketed list)
,	The comma operator lets you build bracketed lists
NOW	Nonary, Reserved word representing the integer time (secs since 1970:00:00-00:00.00Z)
()	An empty list

Because I fouled up and used / for the REF operator, the standard interpretation of / is not available, so the XQuery div standard is adopted instead.

Examples

• %QUERY{"ElapsedDays > int((EndTime - now) div (60 * 60 mod 24))"}%
• %QUERY{"Sex in ('Male', 'Female', 'Hermaphrodite')"}%

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: CrawfordCurrie - 27 Jan 2009

Discussion

Gr8. I take it for granted that we also have bracketing of arithmetic terms. Why DIV? I'd expect int(float1 / float2) to do the job as well?

-- MichaelDaum - 27 Jan 2009

Why DIV? I was going to say "because SQL has no INT" but of course I was looking for it under the wrong name; it's called TRUNCATE in SQL. SQL also has ROUND. Both seem fairly widely supported.

-- CrawfordCurrie - 27 Jan 2009

Unfortunately I stupidly shot us in the foot by using / for the REF operator. So we have to pick something else for division.

-- CrawfordCurrie - 15 Sep 2010

Excellent. I assume you know what you're doing; that divide '/' won't be confused as ref '/', and vice-versa.

-- PaulHarvey - 17 Sep 2010

No, I don't know what I'm doing; that why I made the "Unfortunately I stupidly..." remark above. I don't want to have to resort to a DIV() operator. But right now, I can't think of an alternative. Context sensitivity (operator overloading) is not an option IMHO.

-- CrawfordCurrie - 18 Sep 2010

On IRC we discussed :-, \ and //. Given that \ conflicts with parser escape char, it's really a choice between // and :-. I think // is probably more intention revealing.

-- PaulHarvey - 18 Sep 2010

mmm, i fear that // is less intention revealing than resorting to DIV() - i'd suggest using DIV() until (or unless) a good choice appears.

-- SvenDowideit - 20 Sep 2010

I agree with Sven.

-- GilmarSantosJr - 23 Sep 2010

In retrospect I have to agree with agreeing with Sven

-- PaulHarvey - 23 Sep 2010

I really, really want to be able to write %QUERY{"100 / 33"}%, and the ':' or '@' characters are both more meaningful for REF anyway (I don't know why I selected '/', I think it was because that's what DBCachePlugin used. I'm starting to think we should re-task /. Sometime you just have to bite the bullet.

Alternative 1 would be to use some standard neutral prefix for arithmetic operators. For example, # so that:

#/	Floating-point division
#-	Subtraction and unary minus
#+	Addition
#*	Floating-point multiply
#%	Modulo

Any other strictly numeric operators we add would have # prepended as well.

Alternative 2 is to use DIV() for division, but I think that just avoids the issue and puts the problem off to a later date.

-- CrawfordCurrie - 21 Nov 2010

Changing / to meaning division will be rape on our users. I can already see myself a full working day hunting down all the uses and change it

But the #/, #+ etc is a nice proposal. Backwards compatible and the # prefix meaning numeric operator makes sense. I have often wanted addition and subtraction to search for time related properties.

-- KennethLavrsen - 21 Nov 2010

DBCachePlugin is not using /. It uses @ for REF. Most probably it became / here because of its association with xpath.

-- MichaelDaum - 21 Nov 2010

if you really want to do something with #, why not use it as a context 'hint' - ie #(someField / 12) (ug, and there's the reason perhaps not

as #('Web.Topic'/someField / 12) is a bit confused :/

I'm betting if you poke around on codev, you'll find that someone strongly objected to using the email symbol for dereferncing - personally, I'm sad to lean towards not breaking existing users topics too

could of course ask how hard it would be for the / parser to recognize the context its used in .... numeric divide if a topic name (both literal, and reference) is on the lefthandside doesn't feel like something that makes sense.... (is that the only context in which / is used atm??)

I'm presuming that I can actually say something as convoluted as 'SomeTopic'/somefield/anotherfield where anotherfield is extracted from the topig named in somefield....

-- SvenDowideit - 21 Nov 2010

Context-sensitive parsing would break for 'SomeTopic'/somefield/anotherfield. It could also mean somefield in SomeTopic divided by anotherfield in the current topic. Madness would ensue if the behaviour if the behaviour of /anotherfield depended on the value of 'SomeTopic'/somefield e.g. division if somefield contains a number and lookupafieldinatopic if somefield is a topic name.

So: assuming that / means lookupafieldinatopic, and taking QueryAcrossTopicRevisions into account, one could also have UNIQUE 'SomeTopic--*'/author/organisation/copyrightcontactaddress. Ok - so I tossed unique into there too

There may be some operators missing. How would I write a query like this? (I realise that this might be an issue with QueryAcrossTopicRevisions and not with AddOperatorsToQueries, but I am not sure where best to ask this question.)

• Return a list of the authors (i.e. the people who edited the topic) for all revisions of topics whose finishbydate field in the latest version of the topic is less than 10 days in the future.

-- MichaelTempest - 22 Nov 2010

Right. It's critical that queries can be parsed context-independently, because the expressions are inherently typeless. I considered the "operator modifier" idea that Sven suggests, but rejected it for the same reason he does - it's just too confusing.

'--*'/(finishbydate < (NOW + 10*24*60*60)).author

Note that while we may have the beginnings of a language to described queries over revisions, we still lack a language for reporting the results of such a search.

-- CrawfordCurrie - 22 Nov 2010

I can't decide. They are all equal beauties from hell. Any of them ultimately brands foswiki as a geek-tool for geeks-only. Instead, I'd prefer to bite the sour apple and deprecate / until foswiki-2.0. Up to then alternative 3 seems to match closest to the ideal, naming numerical ops the way the rest of the world does.

-- MichaelDaum - 01 Dec 2010

Yeah, it's a tricky one, no doubt. But unless someone screams, then I suggest we consider (3) to inherently mean "deprecate". I marked the affected rows above in red - please remove the colour after you have considered this change in the rules, and adjust your vote if you think it apt.

-- CrawfordCurrie - 01 Dec 2010

The key question here is first if we want to fuck our users or not. Deprecation after one year is sick. It is no time at all. Foswiki is already 2 years old. It feels like it was yesterday.

The vote you set up may end up with more votes against 3 then for it, but if there are more 3 than the other options it may look like it wins.

Name	Punishment for stealing a bread
Curt	1 week jail
Benny	2 weeks jail
Lottie	100$ fine
Mike	Death
Hans	Death
Tina	1 week jail
Ole	Death
Cindy	2 weeks jail
Chris	Death
Svetlana	1 week jail
Anna	2 weeks jail
Lars	100 $fine
Rune	100$ fine

Result:

• Death: 4
• 1 week jail: 3
• 2 weeks jail: 3
• 100$ fine: 3

Result. Punishment for the guy that stole a bread: DEATH

But in reality 9 were against death and wanted a mild punishment.

I only see a vote constructed to make the "deprecate in 1 year" win. You cannot setup a vote this way. This cote is bullshit!

Look at the consequences.

Every SEARCH in all our users Foswiki's will have to be reviewed for a specific syntax which is near impossible to do a search and replacement for. If it was a name of a macro that changed I could do a global search and replace but here we are changing the meaning of "/". Impossible to find in any other way than waiting for it to fail.

If this becomes the result then you have once and for all told the Foswiki users that you do not give a damm about their content and that you will in future change anything, and that nothing can be trusted. This will kill the reputation of the project.

Let me remind you all again. For the users of Foswiki

• Foswiki itself is worth a few 1000 dollars. If we sold Foswiki as a commercial product people may pay 1000 or 5000 dollars for it.
• The content people have added to Foswiki (which is often an upgraded TWiki) is worth millions of dollars in many companies.
• The value of 10 people spending 1 work week fixing the issues such a change causes is 10 x 40 x 70 $/hour = 28000 dollars. It could easily cost 28000 dollars to upgrade Foswiki from 1.1 to 2.0 to clean up the mess they get from your deprecation.

Now many times do you think we users feel like fixing things each time we upgrade. Last upgrade from 1.0.9 to 1.1.1 took us approx 50 hours and that was just incompatibilities that noone had intended but just happened.

THINK! Protect the value of the CONTENT. Never mind the beauty of the syntax. Protect our content please. Otherwise Foswiki becomes a geek project for the developers that noone wants.

-- KennethLavrsen - 01 Dec 2010

Kenneth is right, unfortunately The 4 is the most legible proposal (and similar to that what the users know from their Office applications). IMHO the / as operator for reference should be deprecated (@ is okay) in the long term anyway. I guess that a combination of 4 and 3 (with 3 becoming default once / as REF is deprecated) is too much of an overhead, right? As user 4 might be okay, hey think about the SSP mess we're used to.

---

Hm, what about the ÷ sign, couldn't we use that instead of / ? But how to type that in a text form? ÷ (copied from html)

Alternative 5:

The proposed operators are:

INT	Unary (function)
÷	Floating-point division
-	Subtraction and unary minus
+	Addition
*	Floating-point multiply
%	Modulo
IN	Check whether a value is within a set of values (bracketed list)
NOW	Nonary, Reserved word representing the integer time (epoch secs)

Example: %QUERY{"ElapsedDays > EndTime - NOW ÷ 60 * 60 * 24"}%

Looks nice.

We could also use × or · instead of *, resp. ⁄ or ̸ instead of / but that's Unicode thinking.

-- FranzJosefGigler - 01 Dec 2010

Kenneth, the deprecation of '/-as-ref' would HAVE to be done in a way that never kills the user's content. In the same way we 'deprecate' ADDTOHEAD but never actually remove the functionality. In the same way we still support legacy ADDTOHEAD usage with the {MergeHeadAndScriptZones} knob, but may be years away from removing this feature.

I would say that this means yet-another-knob in configure to enable/disable '/-as-ref', where the deprecation action after 1 year (I suggested 2, actually) is to just change the default setting to 'off'.

If you want to vote against option 3, I'd say do it because you don't want yet-another-configure-knob. I never intended to break existing content with this suggestion.

This might seem painful in the short term, but I think would be worth it in the long run.

-- PaulHarvey - 02 Dec 2010

Franz's suggestion has intriguing possibilities...

The hard part of using non-7-bit-ASCII characters is dealing with different encodings. As Paul pointed out on IRC, ÷ is not representable in cp1251, so it would have to be represented as an entity when using that charset, and there is more than one form for that entity. Furthermore, it could be represented as an entity in charsets that do have a native representation of ÷, and there might be charsets that represent ÷ with a different code than 247.

I would hate to try and write a parser that has to deal with all of that, but I don't think it is necessary - there is at least one other way.

I suggest that the query parser should convert the query string to unicode characters in the native perl representation. That way, ÷ is always one character and it always has the same character code. After parsing the query, the parser should then convert things like field names, web names, topic names etc back to the site charset.

This idea (parsing the query string as native unicode characters) exchanges one form of complexity for another - I can hear the "encoding" screams already Even so, I think it is worth considering.

My keyboard doesn't have a ÷ key, but I don't think that is a problem. It would be easy enough to add a TMCE toolbar for the handful we use, and we could do something similar for the raw editor (rather like NatEditPlugin does).

Apart from not breaking existing users' content, this way of parsing queries gives us so many more different operator characters to choose from.

I have withdrawn my vote because I think further discussion is needed.

-- MichaelTempest - 02 Dec 2010

Deprecating features is a normal and healthy procedure for software. Imagine you'd never be able to get over former sins. We do have quite a lot of areas where code is in deprecation state for quite some time, e.g. some of the plugin handlers. We are still suffering from these old handlers as they take down performance.

There are other sins showing up their uggly face, basically all plugins that use commonTagsHandler(), lilke SSP and all table related plugins. In some cases we are able to overcome a blody deprecation process by coming up with clever technical solutions.

Now this time take the following under consideration:

• face it, all proposed alternative including (5) are butt uggly
• QUERY is young very young with people just getting aware of its potentials. on top i doubt many are making use of the REF operator as it is right now
• this time, there is no clever technical solution.

Finally, either you have got some sort of deprecation procedure for your software or not. If you have one, then you must be prepared to execute it. This means in the end, that you will have to remove features at some point, no matter if it is replaced by some other improved but slightly different feature or not.

And if you remove a feature - after a reasonable period of time warning the users that this is comming up - then you will have to stand the anger of those people that did not see the warning signs and have problems after upgrading to a release with deprecated features being removed.

This is normal.

This is normal for software.

This is normal for users to behave like that.

There's nothign geeky about deprecating features.

It is NOT normal to have NO deprecation process or just HALF of it and missing the guts to execute it.

This time I think we will have to queue this change into the deprecation pipeline.

Inventing cryptic signs instead of using WELL KNOWN math operators is geek.

So IF we have the choice to be (a) geeky because we deprecate / for REF or (b) geeky because we reinvent math ops replacing them with something total unusual, then I prefer to be called geek for going with (a). We are all geeks anyway.

-- MichaelDaum - 02 Dec 2010

This isn't really helping. IMHO we need to find the courage to perform this deprecation, and the ability to open out minds to different alternatives. If starting this vote does nothing else, at least it has drawn attention to the issue, which has been ignored for too long.

IMHO if it is done with enough of a fanfare, and support exists to make it as easy as possible for end users, I think deprecation is manageable. 1 year is too short? OK, let's make it 2. DIV is preferred to #/? OK, let's support both. But I agree with Michael this time; / for ref is a bad choice, and we should deprecate it ASAP whatever the decision here.

-- CrawfordCurrie - 02 Dec 2010

Crawford, when I agreed to fork you made a promise that you would also defend the compatibility with content. It is more vital to us corporate users with very large wikis with many webs and many topics and 1000s of SEARCHes all over the place.

The fact that this one cannot even be fixed by a search/replace makes it very very serious. We are not talking about some plugin API where a few plugins have to be changed. You are changing syntax.

Query search was introduced already in TWiki and it is at least 4 years old now. It is not a new feature we introduced yesterday. You cannot deprecate it without harming all us users. And no configure setting can prevent the harm. It is just a matter of delaying the pain. But pain there will be.

This whole issue is cosmetic. It is not a situation where an API is made in a way that prevents someone from making new features. It is just a matter of "/" vs "DIV".

And actually - how big is the problem.

Does the current use of / in references allow white space around the /? I do not see the syntax docu suggest this. So why not just define the / so when it is with something meaningful in front it means a reference. And when you have white space in front of / it means division. By specifying that all numeric operators must have white space around this may be the simple solution that will not confuse the users that have to deal with it. We also know from Perl and from regexes how ^ and | and * have different meanings in different contexts and we live fine with that.

If we can do it with the whitespace so the / ad ref never stops working, then I have no issue with introducing the @ and deprecate the /. The issue is deprecating and removing the function and breaking our content.

-- KennethLavrsen - 02 Dec 2010

The parser ignores any whitespace around operators. The only constraint is that operators cannot have internal whitespace, so # / is not equivalent to #/.

The question really comes down to: what is more likely to be a source of error for end users? If we deprecate / now in favour of @, we have as long as we need to eliminate usage. I have already written code that generates warnings when it is used. I suggest we take this in stages; agree that we should deprecate /-as-ref now, and gain a lead on whatever the eventual outcome of this discussion is. See DeprecateSlashAsRef.

-- CrawfordCurrie - 02 Dec 2010

That's exactly what I was about to write. If we deprecate it for a year, but real deprecation, meaning that every time this is used, it generates a warning somewhere (preferably directly on the wiki), then I do think it's fine. Users viewing the content can see some red text around their query, explaining them that / is deprecated in their QUERY, and should be replaced by @.

I do agree with Kenneth that we have to be very careful, but proper deprecation should solve it (meaning: obvious and enough time to fix).

I've put the table back at the bottom, otherwise it's a pain to vote, and I've put an anchor (called VotingTable) on it.

Also, to address Kenneth's point about giving the death penalty, we should use Wikipedia:Condorcet_method to decide, not a simple "4 has more votes".

Finally, to put more oil onto the fire, TIMTOWTDI, so I suggest we implement all these operators while deprecating / for REF.

-- OlivierRaginel - 02 Dec 2010

Please comment ABOVE the table

OK, I've rewritten the proposal to the #/ form and put it to community vote. Please vote - decision by 15 Dec. If there's a tie, I'll make an executive decision (implementers privilege)

• Alternative 1: DIV * - + %
• Alternative 2: #/ #* #- #+ #%
• Alternative 3: #/ * - + % with @ for REF and deprecation of / for as long as it takes -- See DeprecateSlashAsRef
• Alternative 4: DIV MUL SUB ADD MOD

Who	Preferred Alternatives, favourite first
CrawfordCurrie	3 > 2 > 1 > 4	edit
SvenDowideit	4 > 1 > 2 > 3	edit
OlivierRaginel	3 & 1 & 2 & 4	edit
MichaelDaum	3(div instead of #/) > 1	edit
KennethLavrsen	Anything except 3	edit
RafaelAlvarez	4 > 2	edit

-- CrawfordCurrie - 01 Dec 2010

You cannot use the Condorcet for the vote above. It requires that the options are balanced. They are not. By splitting the "I care about the user" options in many the vote is rigged to favour the geek-developers choice. Also note - not a single customer has reacted yet. I will make noise like hell in mailing lists, twitter... everywhere if you guys continue with this.

I do not think my question about the space was properly answered. How does the parser treat the whitespace today?

Even if we deprecate - it can be done in many ways. One could be to deprecate the syntax WITH whitespace. I doubt anyone is writing things like

Person / (ClothesForm[name='Headgear'].value or parent.name / (form.name='ExampleForm') (note the white space around the /). None of the documentation or examples shows whitespace and personally I would think it would not work if I added whitespace. All examples are with no whitespace.

It could be a simple matter of saying that math operators require white space and then deprecate the reference use of / WITH white space.

Having code that marks the deprecated use does not solve the problem with upgrading Foswiki. I still have to go through ALL searches in 100000+ topics and look for the error. And I cannot accept that I have to sit and take hellfire from my users who will put all the blame on me as the admin. You cannot treat us users this way. I may be a developer also but seen as number of hours I spend on Foswiki, it is the hours as admin, supporter and user that I spend most of the time. I wonder how Yahoo with their several 1000s of webs will react to this. Has Vicky seen this horror proposal yet?

-- KennethLavrsen - 02 Dec 2010

The parser ignores whitespace around operators. Not sure what else I can say. Today, people may have written "A / B" and "A/B". If you deprecate the former usage, you might as well replace the operator and be done with it, you have the same compatibility problem. I can't see any difference.

Please, do make a noise about this. I would really like to hear more opinions on this issue.

Also, as you say, deprecation can be supported in different ways. One is to provide some code that scans all SEARCH statements in a wiki and remarks those that use the / operator. Used once (when upgrading to the release where / is finally about to be removed) gives a simple way for people to find and fix any occurrences. Of course it's not 100% failsafe - TML makes that impossible - but it should work for 99.9% of cases.

-- CrawfordCurrie - 02 Dec 2010

I started writing a calm and non-geeky mail to the foswiki-discuss list. When I read it back to myself, I realised that the deprecation route is simply unworkable. Consider:

1. We add '@' for REF, and add '#/' for arithmetic divide, now.
2. We wait 2 years for people to get used to using '#/' for divide
3. After 2 years, we ask people to check for usage of '/' in their macros. Some of them shout for a while, then change their remaining '/' calls to '@' - after noting that older revisions of topics still contain '/' and will therefore always be broken.
4. At the same time, we tell all those people who have got used to using '#/' for divide that they can now use '/'. They stare at us blankly.
5. Shortly thereafter, the people who ignored us when we warned them about the deprecation and the death of /-as-ref start to scream as their users discover the change.

This is a lose-lose-lose AFAICT.

All the other alternatives above are frankly equally unpalatable. So, maybe it's time for some out-of-the-box thinking. Here's mine.

• FormField > 104 mul 2 div 356
• Formfield > $(104 * 2 / 356)
• Formfield > math(104 * 2 / 356)

-- CrawfordCurrie - 02 Dec 2010

Sorry Crawford, that's not out of the box, that's just re-bringing up the same thing that we already discarded as unworkable.

And this is why I voted for DIV, MUL etc - all the numeric operators are constent, and distinct from pre-existing choices. Also, I don't really consider maths as the most common usage in this context, though like everyone, wish upon a star (blah, blah, blah, blah )

• FormField > (104 mul 2 div 'System.MyAppSettings'/DaysInYear) - OK
• Formfield > $(104 * 2 /  'System.MyAppSettings'/DaysInYear) - FAIL
• Formfield > math(104 * 2 /  'System.MyAppSettings'/DaysInYear) - FAIL

tbh, the idea of using yet another special char $ is asking for more future trouble, whereas math() could be argued to be a clever parser converted way to access SSP functionality.

-- SvenDowideit - 03 Dec 2010

DIV, MUL etc can be used in more than one way. They are hard to use and read when used as functions (as they were in the example given for this alternative):
SUB(EndTime, DIV(NOW, MUL(60,MUL(60,24))))

I like their use as operators, like in Sven's use above:
EndTime sub NOW div (60 mul 60 mul 24)

Even so, that leaves me with a feeling of "ick". sub makes me think perl subroutine, or substring, or subscript. And the way I read operators, I would prefer plus and times. Better still, I would rather use + and *. Which brings me back to this, which is close to alternative 1, except that div is an operator and not a function:
EndTime - NOW div (60 * 60 * 24)

I could live with that. I think I could explain that to my users.

-- MichaelTempest - 03 Dec 2010

I am glad you finally realized the consequence of the deprecation.

I also think the normal math operations * + - are best with DIV. And in the docu we can write something

DIV	Divide (you cannot use '/' as it means reference)

and the users will immediately understand the reason without further explanation.

And looking at the normal use. Math will be used rather rarely but for sure will be used. I can already see some places I can use it. And when used the most normal operators will be + and -. I can see how CALC is used in many of our tables. We often use - for a diff. Sometimes +. If we calculate quantity * cost we use multiply. But / I have only seen when calculating exchange rate related things and that will be very rare in a query search context. I think I have seen have one CALC with a division. So the "damage" of DIV is more inside our geek heads than it is in the practical world I am sure because rare * rare = very rare.

I can however find places where the / is used in a SEARCH

I am all for "* - + DIV" where DIV is an operator and not a function. The function hell in CALC we should avoid.

-- KennethLavrsen - 03 Dec 2010

Quite a few programming languages already use DIV as an operator like this. On the other hand it's usually (maybe even always) integer divide, therefore the docu needs to make it clear that it's a floating point divide, it'll trip someone up otherwise.

DIV	Floating point divide (you cannot use '/' as it means reference)

-- JulianLevens - 03 Dec 2010

In light of the above discussion I'd like to revisit one rejected idea; % for div. So:

Op	Synonym	Means	Example
INT		Unary, truncate floating point to integer	int(1.5) -> 1
DIV	%	Floating-point division	1 DIV 2 or 1 % 2 both eval to 0.5
MINUS	-	Subtraction (and unary minus)	1 minus 2 and 1 - 2 eval to -1. minus 1 and -1 both eval to -1
PLUS	+	Addition	1 plus 2 and 1 + 2 eval to 3
TIMES	*	Floating-point multiply	2 times 2 and 2 * 2 eval to 4
MOD		Modulo	3 mod 2 evals to 1
IN		Check whether a value is within a set of values (bracketed list)	'fred' IN ('joe', 'fred', 'sam') evals to boolean true
NOW		Nonary, Reserved word representing the integer time (epoch secs)	now evals to epoch time (in secs)

-- CrawfordCurrie - 03 Dec 2010

You won't ever get deprecation without users being annoyed. Warning them 2 years in advance is all we can do. The above description of the deprecation process is quite accurate, still drawing the wrong conclusions, imho. Deprecating features that went belly up is an important tool for us trying to improve the coherence of Foswiki. True, the deprecation cludge must be used extremely rarely and only after an extra portion of consideration. Of course this is nothing you do twinkle-toed. Likewise you can't rule it out that easily if something is that of a problem as it is now with a lot of consequences for users how they write content in the future. Either we get this straight now - or never ever again. There is a chance to get this fixed now. But never again. The all Foswiki users will have to live with this.

-- MichaelDaum - 03 Dec 2010

Interesting that Python had a similar issue early in the decade. See http://www.python.org/dev/peps/pep-0238/

They resolved it using (1) deprecation and (2) a configuration setting.

-- CrawfordCurrie - 03 Dec 2010

And here's the list of xpath operators. They use a div. Changed my vote. Actually I'd still prefer to have / for division but use DIV instead of #/ in alternative 3, that is use DIV instead of #/ in a deprecation process.

-- MichaelDaum - 03 Dec 2010

I don't think compatibility with xpath is such a bad thing. I'd be happy with div instead of #/ as well. Note that because the parser is very simple, using any text string name for an op excludes that string from being a field name; so you can't have a field called "div" in you form (though I could always make the parser smarter, I suppose).

-- CrawfordCurrie - 03 Dec 2010

XQuery in addition provides the idiv operator for integer division. I'm all for compatibility with standards. Foswiki should use the intelligent borrowing method whenever possible. I'm now for div as operator too. Let's have a look at the naming of other standard operations too and reuse the conventions of XPath/XQuery if possible.

-- FranzJosefGigler - 03 Dec 2010

Not sure that idiv is necessary with div, mod and int available. Convince me.

I reset the proposal to reflect the abortive vote and discussion it inspired. I have an implementation of what is described. Kenneth, is your concern still alive?

-- CrawfordCurrie - 05 Dec 2010

We need to be careful about the spec for mod.

• Is the sign of the result taken from the divisor or the dividend? SQL takes the sign from the dividend. Perl's % operator takes the sign from the divisor.
• What does the operator do with floating-point operands? Perl only uses the integer portion of the operands. As far as I can tell, SQL will use the fractional parts, too.
• What does the operator do if the divisor is 0? Perl dies with "Illegal modulus zero", but (AFAICT) SQL returns the dividend.

For more gory details, see:

• http://perldoc.perl.org/perlop.html#Multiplicative-Operators
• http://en.wikipedia.org/wiki/Modulo_operator
• http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/functions088.htm
• http://techonthenet.com/oracle/functions/mod.php (NB: gives examples of behaviour with non-integer operands)

Caveat: I do not know SQL, so I could be wrong about SQL details - I am just reporting what I read on the web, and we all know how reliable that is

-- MichaelTempest - 06 Dec 2010

hmmm. Well, I naively thought the spec of mod was more common than that. My immediate reaction is "bugger it, not going to bother with it now". Too many other irons in the fire to worry about such a borderline operator. Removed mod from the list of operators.

Patch for the proposal attached to Tasks.Item10129

-- CrawfordCurrie - 06 Dec 2010

Perfect to me. Thanks all for the debate and for collaborating to a common understanding. Especially the external refs were useful seeing what other project have done in similar situation.

Concern removed. Proposal is accepted by consensus.

-- KennethLavrsen - 07 Dec 2010