Sectioning a chain of operators and dot as reverse application

I have a meager syntax proposal and am curious if anyone has explored this design, knows of a language that uses it, or can think of a problem with it. It's comprised of two aspects that work together to support certain idioms in a neighborhood of Haskell syntax.

The first aspect is to generalize sectioning of binary operators to chains of binary operators where the first and/or last operand in the chain is missing. Here's a GHCi interaction:

Prelude> (1 + 2*)

    The operator `*' [infixl 7] of a section
        must have lower precedence than that of the operand,
          namely `+' [infixl 6]
        in the section: `1 + 2 *'

So Haskell doesn't like the expression (1 + 2*). The proposal is that this would instead be a section of an operator chain, equivalent to (λx. 1 + 2*x). Similarly for (*2 + 1).

The second aspect is to use dot for reverse application (rather than composition). That is,

x.f = f x

Dot and juxtaposition would have equal precedence allowing an OOP-like style (after modifying map and filter to take the list first):

[1, 2, 3].map (+1).filter (>2)  ===  filter (map [1, 2, 3] (+1)) (>2) 

In combination with the first aspect, we can recover composition as:

f `compose` g = (.g.f)

And in general we can capture the tails of OOP-like expressions like this:

frob = (.map (+1).filter (>2))

Has anyone used or seen this approach or does anyone see problems with it?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

x.foo(y) = foo(x,y)

I've seen several languages with a feature of the form `x.foo(y)` is syntactic sugar for `foo(x,y)`. I'm pretty sure most of them were multimethod languages. Unfortunately, I'm blanking on which languages these were. None were languages I've much used, only studied in passing. I just know there are several of them. And users/authors seemed pretty happy/smug about it. :)

Personally, I think it's a good idea for making OO classes more openly extensible, and certainly more pleasant and generic than Haskell's awkward backquote form (where x `f` y = f x y, but x `f 2` y is badly formed).

I've seen several languages

I've seen several languages with a feature of the form `x.foo(y)` is syntactic sugar for `foo(x,y)`. I'm pretty sure most of them were multimethod languages. Unfortunately, I'm blanking on which languages these were.

Ada2005 supports it.

Python works that way:class

Python works that way:

class myClass:
 def myFunc(self, name):
  self.name = name

(new myClass()).myFunc("Joe") == myFunc(new myClass(), "Joe")

Unfortunately, I'm blanking

Unfortunately, I'm blanking on which languages these were.

It's present in the D language, where it is named UFCS (Universal Function Call Syntax). It allows you to write code like:

[1, 2, 3].map!q{a + 1}.filter!q{a > 2}

I was thinking D might have

I was thinking D might have been one of them, but I couldn't find the documentation for it when I looked. (I didn't think to look for "UFCS".) Thanks.

That's nearly what scala has

That's nearly what scala has with its underscore variable. (1+2*_) and _.map(_+1).filter(_>2)

Dot as reverse function application (in Haskell)

See https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix

Note that any proposal to change the behaviour of dot will meet stiff opposition. (That wiki page has a link to a thread.)

Thanks

That link looks 100% on point.

Linguistics

The missing operand proposal lends itself to ambiguities, e.g. when there are more than one missing operands.

One area to look for a solution might be natural language syntax, e.g. https://en.wikipedia.org/wiki/Theta_role

Can you give an example?

The missing operand proposal lends itself to ambiguities, e.g. when there are more than one missing operands.

What's an example?

Superficial notational observation

The dot normally is used to select a method relative to an object which is an instance of a class. In PL terminology, I prefer to use the definition for a class as a "reinstantiable module declaration."

You can introduce dots but what's the point if you don't have any OO semantics to accompany it?

This reads like trivialized bickering that if OO has dots then an FP language should have them too without regard for what the semantics of method selection in an OO language is. Yeah, FP can have a dot notation too, so what?

Not so superficial

Marco, ahem, dot suffix notation long predates OO or indeed computer languages. (For example Russell & Whitehead's Principia Mathematica 1910.) Did anybody complain about consistent semantics when Codd and others introduced dot notation into query languages? Perhaps OO should stop using it because OO doesn't follow SQL's semantics?

If you'd followed around some of those Haskell links before making a superficial response you would have found:

A practical reason that many text editors are tuned for dot suffixes to prompt for valid names to follow. In the case of OO that goes Object --> prompt for method. In FP it could go argument --> function; record --> field; etc.

A mental image reason (call it semantics if you will) that some software design 'flows' better from focus to action (or noun to verb). Compare GUIs where you point at the screen and right-click for the action, as opposed to a typical green-screen flow of first choose the action from a menu then hunt for a record in a list.

If you don't like dot as reverse function application, nothing's forcing you to use it. Personally, I strongly dislike Haskell's use of dot as function composition -- even though I've programmed in Haskell for years.

Just sharpening the conversation

Historical fallacious argument. I can pull any observation out of history to make any argument seem correct.

UI's are geared towards OO is actually completely in line with my observation that people want OO but won't get it. As is the second argument. There probably already is an operator which allows you to write "x ^ f" instead of "f x", so whatever noun-verb-order argument is moot.

People wanted imperative programming and got it in a broken form in terms of monadic programming in Haskell too, so my guess is they'll go ahead and implement this. But all you get is a reverse application/field selector and that just isn't that useful in a pure functional language.

(If you'll bite you'll show me how to do pure functional OO with a dot and type classes. Yeez. Shouldn't you bite now?)

.

.