Re: Things that make you go Hmmmm!

Apologies if the example with cURL is not apposite enough but I am
guillotining the time I am devoting to the discussion so not going to
provide an alternative.

You "lazily" evaluate the "parameters" supplied with the variant of
the language construct you are invoking. xsl:copy - right I am only
going to look at the  subset of parameters relevant to that. In
essence the language construct you choose sets a construct for how the
parameters supplied are interpreted and whether they are considered at
all.

You return a result consistent with the relevant subset.

Up to the language designer whether they want to issue a warning about
parameters are ignored. Up to the programmer to investigate if he
doesn't get back what he expected - that is an inherent part of the
discipline of programming.

On Sat, Mar 29, 2014 at 3:05 PM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> wrote:
>
> On 29-3-2014 15:39, Ihe Onwuka wrote:
>> On Sat, Mar 29, 2014 at 2:05 PM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> wrote:
>>
>>> 2) the use-attribute-sets attribute
>> One answer suffices to illustrate my point which has got nothing to do
>> with undestanding or not understanding the semantics of copy and
>> copy-of.
>
> Good. But I think understanding the semantics is vital in any discussion
> of language design. Syntax and semantics are hard to be seen in isolation...
>
>
>>> This one is on xsl:copy, because xsl:copy allows the children to be
>>> modified. The addition of use-attribute-sets serves the use-cases where
>>> you want to replace or augment the attributes on a certain element.
>>>
>>> It is not available on xsl:copy-of because the semantics of xsl:copy-of
>>> are different: it makes an unchangeable deep-copy of the selected node.
>>> Allowing use-attribute-sets would change that semantics, which is a bad
>>> idea. If you want to change the children, use xsl:copy, not xsl:copy-of.
>>>
>> You have an option use-attribute-sets makes no sense in the context of
>> xsl:copy-of. So if it appears you just ignore it, perhaps with a
>> warning perhaps not.
>
> That is exactly what happens now, exact that you do not get a warning,
> but an error, which is a stronger signal that you are trying to do
> something (adding attribute sets) that cannot be done (because of the
> semantics of xsl:copy-of).
>
> You seem to argue that orthogonality means that you should add the same
> properties to different instructions or functions, even if the effect is
> zero, because the other attributes do not make sense. I think this is an
> excellent situation where too much orthogonality would create a host of
> surprises and unclarities.
>
> Instead, orthogonality also means that if two instructions have similar
> semantics, that properties for these similar semantics are available to
> both, but properties that are different are not, to be able to
> distinguish between the different operations and to follow that other
> principle, the principle of least surprise.
>
> And we may agree to disagree here, but I think adding a property to an
> instruction that has the only effect of raising a warning or doing
> nothing, is a bad idea and should, by all extend possible, be prevented.
> It will only raise eyebrows and many questions on this list like "why
> did you include this attribute if it only ever raises an error?". I
> wouldn't have an answer ;).
>
> (In OOP, perhaps you are referring to that, there is a design principle
> where through inheritance you also inherit properties that you may not
> be interested in, which you can then re-implement by raising an error.
> But OOP is not applicable to a declarative language, so we don't have to
> live with that problem (instead, for packages and overrides, we have
> chosen a different method, you can opt in to which functions etc you are
> interested in and which not)).
>
> There is in XSLT, however, a set of attributes that really applies every
> single instruction, LRE and declaration, such as xsl:use-when,
> xsl:default-collation and xsl:version. These have merit, because they
> actually mean something on each and every place where they can be applied.
>
>
>> You leave the content models the same and you only ever apply the
>> options that make sense for the variant you have chosen and you only
>> step in if what is specified would lead to an unresolvable ambiguity.
>>
>> This is not an alien concept.
>
> True, but I beg to differ that it has no use in this particular area of
> language design, and no use in general unless it means something.
>
>> Take as an example the utility cURL. If I don't want the body of my
>> http request I specify HEAD instead of GET.
>>
>> curl -v --request HEAD "http://www.guardian.com"
>>
>> If I specify the content-type of the body with the --header  option
>>
>> curl -v --request HEAD "http://www.guardian.com" --header
>> "Content-Type:text/xml"
>>
>> There is no need to burden the user with a bazillion different
>> signatures or to officiously refuse to cooperate  until the parameters
>> supplied are  are in perfect semantic harmony.
>>
>> cURL can still figure out what I want, it's still a HEAD request and
>> it  still works.
>
> I'm sorry, I fail to see how commandline arguments, which have their own
> limitations, have anything to do with language design. The only thing
> shown from this example is that using two different ways to achieve the
> same thing (--header vs --request HEAD). In XSLT, we do not allow you to
> use both @select on an instruction _and_ a sequence constructor, for the
> reason that behavior cannot be clearly defined if both are present and
> do different things (as in your example, what would happen with --header
> and --request PUT at the same time)
>
> (and while I find the comparison with cURL odd, it is one of those tools
> that I can only use with looking up examples on the internet, I find it
> a very ill-documented and ill-defined tool, like most commandline tools,
> but this is getting very OT, it is not even a language).
>
> Cheers,
>
> Abel Braaksma
> Exselt XSLT 3.0 processor
> http://exselt.net