Re: [Haskell-cafe] I'm afraid of OverloadedLabels.
On Mon Jul 10 00:16:02 UTC 2017, Richard A. O'Keefe wrote:
... As a native speaker of an SVO language (English) in a country where one of the official languages is VSO (Māori), I sometimes find the OVS structure of "mainstream OO languages" a little uncomfortable... "Backward ran sentences until reeled the mind."
lol. That's a cute comparison. I don't think "mainstream OO" is OVS. In:
... button.colour <- red
Gloss: 'button's colour goes red'. `button's colour` is the grammatical Subject. (Yes it represents an OOP 'Object.method', but that's because everything in OOP is an 'Object'; and the only way to access is by methods.)
... button.reset
Again `button` is the grammatical Subject. (It must be, because there's no grammatical Object.) Then `reset` must be the verb, used intransitively. (In French you'd use a reflexive: `the button resets itself`.) This dot-suffixing is already in Haskell: Data.ByteString.Lazy.Builder.Extras 'Data's ByteString's Lazy's Builder's Extras'. To me it seemed natural to carry on ....Extras.untrimmedStrategy.buffSize That is, a field is just a component that might have (sub-)sub-component(s). The field 'belongs to' the structure, so dot represents English possessive. And that's just how lenses look, deliberately. (But that's a mystifying pun on use of the dot: the dot changes from compound name separator to function composition.) But the outcry against TDNR's proposal for dot really was voiciferous. (And nobody paid so much attention to the semantics. So the flaw in TDNR wasn't discovered for a long time.) AntC
On 10/07/17 3:19 PM, Anthony Clayden wrote:
As a native speaker of an SVO language (English) in a country where one of the official languages is VSO (Māori), I sometimes find the OVS structure of "mainstream OO languages" a little uncomfortable... "Backward ran sentences until reeled the mind."
lol. That's a cute comparison.
I don't think "mainstream OO" is OVS. In:
... button.colour <- red
This is normally written button.setColour(red) object verb something Maybe it's OV without a subject, object vp[+imperative]
Gloss: 'button's colour goes red'.
`button's colour` is the grammatical Subject. (Yes it represents an OOP 'Object.method', but that's because everything in OOP is an 'Object'; and the only way to access is by methods.)
Yes, but there is no law in OOP that the object has to be first. In Ada, I could perfectly well write Set_Colour(Red, Some_Object); and have it dispatch on the 2nd argument. In Common Lisp, I could perfectly well write (set-colour 'red some-object) and have it dispatch on the 2nd argument (or indeed, have it dispatch on more than one argument). The object.selector(arguments) syntax is a generalisation of record.field syntax, and there's no law requiring that either. Algol 68 used field OF object. OOP really isn't about the *syntax*, any more than FP is. That's only a human usability issue. (Only. Heh.)
This dot-suffixing is already in Haskell: Data.ByteString.Lazy.Builder.Extras 'Data's ByteString's Lazy's Builder's Extras'.
That is "path" syntax, which again older languages would have written Extras in Builder in Lazy in ByteString in Data and none of the components resembles a verb, in the way that method selectors do.
But the outcry against TDNR's proposal for dot really was vociferous.
Because the dot already has too many uses. There are at least three forms of overloading: - ad hoc, as found in PL/I, Fortran, Algol 68, Ada, and Java. - parametric, as found in ML, Clean, F#, Haskell, and others. - type-based, as found in Eiffel and Haskell, say. Fitting all three together is tricky.
New language features need to make their way into IDE to be fully usable. Name resolution happens with common user activities: goto, find usages, rename. Would any of the new forms of overloading be easy to implement in e.g. http://hackage.haskell.org/package/haskell-names ? Syntax-free name resolution in non-haskell AST parser (of Haskell files) may be tricky to implement. It would likely require more data to be stored, extra lookups and checks. This may slow IDEs down. This is not to advocate a particular TDNR proposal. Rather, a reminder that new language features need to be implemented and may break working applications.
participants (3)
-
Anthony Clayden -
Imants Cekusins -
Richard A. O'Keefe