Re: fn:slice()

On Fri, Dec 4, 2020 at 4:35 PM Michael Kay <mike@saxonica.com> wrote:

>
> This is the most confusing explanation so far. In the call above  there
> are 4 parameters, but none of them counts as a parameter, and they are not
> provided in the function definition signature...
>
>
> Calls don't have parameters, they have arguments. Declarations have
> parameters. In languages that allow keyword arguments, the mapping from
> arguments to parameters is no longer one-to-one.
>
>
>
> So, one will call the function with any map as parameter and this would be
> statically OK?
>
>
> This is closely aligned with the ability to define options parameters
> using a record type rather than a generic map. If the parameter is declared
> with a record type, then we get the potential for much stronger static type
> checking of function calls than we have had before.
>
>
> Is it just me finding this to be a huge disappointment and a huge step
> backwards.
>
>


> It seems to me that you have never enjoyed the benefits of working with a
> language that allows keyword arguments. We found a need in 3.0 and 3.1 to
> introduce functions such as fn:transform() and fn:serialize() that have
> highly variable parameter sets; now we're finishing the job by introducing
> a decent way of calling these functions, with better usabilitty and better
> type-checking.
>
> Michael Kay
> Saxonica
>


I have been enjoying keyword arguments for most of my professional career,
but these have always been strongly typed.

If keyword arguments are defined off a record, without '*' as the last
member, then this will allow static typing and is the right way to go.

*I also strongly support Liam Quin's proposal *to add support for
specifying within a function definition that an argument is optional and
its default value. Done this way, no record / tuple type is needed, and
this is a better solution, because it doesn't involve any new data type. It
also tells the people correctly that the function has 10 different
arguments and not just one. The fact that this may be implemented using a
record is completely implementation-dependent and the developer doesn't
need to be aware of such implementation detail.

Throwing at the people a bunch of arguments and telling them that this is a
single argument is counter-intuitive and confusing.


Thanks,
Dimitre