Specify date rounding mode in scope declaration

[denismerigoux]

The problem

Until now, Catala uses the calendar OCaml library for its dates computations. However, the level of precision offered by this library is insufficient to handle the ambiguities of dates arithmetic in the Gregorian calendar. For instance : what is March 31 st + 1 month ? Is is May 1st or April 30th ?

To give a precise semantics to this kind of dates conundrum, we've developped our own dates computation library : https://github.com/CatalaLang/dates-calc. This library aims to offer a correctness-focused, minimal backend for Catala's dates computation that can be ported in other languages.

During the development of the library, it quickly appeared that date arithmetic is not exact and has to incorporate a kind of rounding for it to work. For instance, March 31 st + 1 month is rounded up May 1st and rounded down April 30th. By default, ambiguous computations that need rounding yield a runtime exception. But the law might set different meta-rule for dates computation. So, we need
a way to specify the preferred rounding modes of dates in Catala.

Proposed solution

The naïve solution would be to set the dates rounding mode via an imperative flag, or a CLI option globally for the whole program. However, this is not functional enough for us, and might pose problem when two programs modelling two different portions of the law interact while having two different date rounding conventions.

So what we propose, is to attach the date rounding mode as a declaration belonging to a scope. All operations on dates that belong to this scope will inherit the declared date rounding mode. Here's a proposal for the syntax:

declaration scope Foo:
  input x content integer
  ...
  output y content boolean

# Later, attached to some article of law
scope Foo:
  declaration date rounding mode decreasing # or "increasing"

This syntax reuses part of the MetaAssertion surface syntax that's currently unsused and should be cleaned/refactored.

[rmonat]

@denismerigoux do you have strong opinions on what should be done regarding MetaAssertion's refactoring?

[denismerigoux]

I think we can scrap MetaAssertion altogether and remove any code that still uses it.

[rmonat]

There seem to be a shift/reduce conflict if I try to add something starting by declaration in the scope_item of the parser. @denismerigoux @AltGr I don't know if there is a way to change a bit the grammar to avoid the conflict, or if we should change the proposed syntax?

[denismerigoux]

Ah yes indeed. So two solutions.

1. either we drop our attempt to have the rounding mode indication close to the article of the law that specifies it. In this case We would go with:

declaration scope Foo:
  input x content integer
  ...
  output y content boolean
  date rounding mode decreasing # or "increasing" # for justification see article XYZ

2. either we keep the rounding indication mode in scope Foo and not declaration scope Foo so to avoid the syntax conflict we go with

declaration scope Foo:
  input x content integer
  ...
  output y content boolean

# Later, attached to some article of law
scope Foo:
  date rounding mode decreasing # or "increasing"

[denismerigoux]

I personally slightly prefer 1) since for me the date rounding is more a declaration than a definition thing. With 2) you would need a check for duplicate rounding mode definitions anyway.

[rmonat]

Thanks, I'll try 1) then.

[AltGr]

About the possible localisation issue, it might be worth thinking about it in a more general perspective: it's not pushed yet, but while updating the parser error messages I had a similar issue. I found it's often very helpful to print examples of the expected syntax, but at the moment those are in English only, with no easy way to "internationalise" them

[rmonat]

@AltGr I'm not sure I understand which localisation issue you're mentioning.

[AltGr]

Ah, sorry, that was lacking context! I meant localisation in the sense of internationalisation, i.e. being able to work with different natural languages (this is generally only concerned with translations of the program output, but in Catala we do have internationalisation of the input)