[swift-evolution] API Guidelines Update

Thu Feb 18 02:19:08 CST 2016

> On 18 Feb 2016, at 08:37, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Wed Feb 17 2016, Taras Zakharko <taras.zakharko-AT-uzh.ch <http://taras.zakharko-at-uzh.ch/>> wrote:
> 
>>> On 18 Feb 2016, at 06:44, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> 
>>>> Also, you could infer "x.expanding..." alone to mean "x, *by*
>>>> expanding..." or "*whether *x *is* expanding...", 
>>> 
>>> Only by adding words that aren't there.
>> 
>> I think what Jacob is trying to say is that an ‘-ing’ form does not
>> have a clearly defined semantics in English. Depending on the
>> construction, the meaning can differ. This creates potential
>> confusion, as many people have pointed out earlier. Taking
>> x.expanding() again, 
> 
> It's a bad example, because the guidelines say to prefer “ed” unless it
> would be ungrammatical.  In this case,
> 
>      x.expanded()
> 
> is clearly grammatical, so you never end up here in the first place

I agree, the -ed forms are much more clear than the -ing forms. 

> 
>> it is clear that guidelines intend an irrealis reading ‘if x were
>> expanded, it would be’ or a resultative reading ‘x,after it has been
>> expanded’. However, this is NOT a very typical reading associated with
>> -ing forms.  In particular, other, more conventional readings include:
>> 
>> - converb construction (x is standing there, expanding)
>> - atelic action/focus on a subprocess (x is expanding)
>> - statement about a quality (x is expanding = x is of a quality that it is an expanding one)
>> - question, by modifying prosody: (is x ) expanding?
>> etc.
>> 
>> I believe that it is somewhat unfortunate that the guidelines
>> (correctly, IMO) promote verbosity over luck of clarity and then at
>> the same time introduce semantically obscure or outright weird notions
>> based on the ‘-ing’ forms. Something like ‘x.havingAdded(e)’
>> communicates the intent much better than ‘x.adding(e)’ (which reads
>> like a notification), and yet more clear is ‘concatenate(x, e)’.
> 
> The problem is that if you use x.add/x.havingAdded as a standard
> convention, you end up with gobs of methods that start with “having,”
> which tends to break up the association between the mutating and
> non-mutating forms.  We think that association is important.

I understand the predicament. But how far would you go to keep it? See the SetAlgebra thread. 

> 
>> So going back to ‘adding words that aren’t there’ — by promoting this
>> guideline rule, you are already doing this. 
> 
> Doing what?
> 
> (“this” without an antecedent; tsk, tsk --- yes, I'm well aware that
> correcting a linguist's writing is very likely to backfire, but I
> couldn't resist)

Yeah, linguists are often misunderstood :) Just so that you know — most linguists don’t care that much for the arbitrary prescriptive school grammar rules (btw., the antecedent is “adding words that aren’t there”). 

> 
>> But I digress. As a linguist, I am not very fond of this aspect of the
>> guidelines, but if they are applied consistently, people will get used
>> to them. Just don’t make a mistake and believe they are ‘grammatical’
>> — they are not, 
> 
> That's quite a claim.  I previously understood you to be saying that the
> forms weren't typical usage, but are you really saying that “Give me the
> list of all students, removing those who got As” is ungrammatical?

Thats why I put “grammatical” in quotes. Grammar is the case of extreme conventionalisation/optimisation of message encoding, but its the actual use is what is important here. Of course, these forms are perfectly grammatical in the narrow sense in that they follow the conventional rules of morphology/syntax of English. What I was trying to say that they do not necessarily follow “grammar” in the broad sense, which includes semantics and maybe even pragmatics. So sure, if one accepts that conventional association between form and meaning is part of the grammar, one could claim that the -ing rule is ‘inventing new grammar”, albeit of course not under the common understanding of grammaticality.  In the end, language is defined by its use, and arguing that something is grammatical when it can’t be reliably interpreted by the recipient  catapults us into the realm of obscure academics (which is very interesting in itself, but probably not relevant to the discussion at hand). 

(And yes, I know that a run-of-the mill Chomskian linguist would lash at me at this point, but unfortunately, I am not a Chomsky believer)

I think, the ultimate question boils down to whether its possible to find a better solution. This is of course conditional on your goals, which are ultimately subjective. For instance, you state that it is important for you not to break the association between mutating and non-mutating methods. Then the solution you propose is certainly quite logical and understandable, even if its a bit unfortunate from the language use point of view. I feel like it can lead to quite awkward solutions at times (see the SetAlgebra thread). 

Personally, I would have preferred either relaxing the connection between mutating and non-mutating methods (but its a non-go according to your goals) or implement non-mutating methods as class methods (effectively constructors), e.g. string.sort vs String.sort(string), array.add vs Array.add(array, element) etc. But this of course results in a lot of repetition, so its not optimal either. 

In the end, its important to pick something and stick to it. We can discuss this back and forth without end (and btw, its very encouraging that you are willing to discuss these things to begin with), but its not much use if the discussion does not result in anything constructive. You’ve made your decision, people in general seem ok with it, and now the question is about applying it in a sensible way. Which for me at least implies thinking twice before using an -ing form. 

Best, 

 Taras 

> 
>> they are creating new conventional readings which are fairly untypical
>> under normal language use.
> 
> Take out the "creating new" part and that is a completely separate issue
> from grammaticality.  I would be very surprised if we were actually
> inventing new grammar here, especially because these guidelines were
> checked by a (different) linguist.  If you really mean that, I'll try to
> put the two of you in touch so you can duke it out and we'll get a
> determination.
> 
>> — Taras
>> 
>>> 
>>>> so there might be some cases where it's easy to confuse Bool
>>>> properties with non-Bools.
>>> 
>>> I don't get it; sorry...
>>> 
>>> -- 
>>> -Dave
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution> <https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>>
> 
> -- 
> -Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160218/93e58d7d/attachment.html>