[swift-evolution] API Guidelines Update

Thu Feb 18 09:16:33 CST 2016

on Thu Feb 18 2016, Taras Zakharko <taras.zakharko-AT-uzh.ch> wrote:

>> 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.

Not as far as that, personally.  IMO that should fall under the “Use
terminology well” clause.

>>> 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”).

What words did I add that weren'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)

This is all way beyond me.  I think most people understand how these
things are supposed to work from the examples.

> 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).

That mess is not the fault of the guidelines, which provide enough
leeway to make sensible and natural choices.

> 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.

I hope you'll think twice about all naming choices.

>
>> 
>>> 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
>

-- 
-Dave