Pythonic syntax

[rolyp]

Finalisation tasks for merge:

• @jacobpake to approve final merge!

See also:

• Pythonic syntax wish-list #1410

Done/dropped:

• Finalisation tasks for RSECon presentation:
  • Comments
  • Doc comments
  • Paragraph
• Migrate article website to new syntax
• Integrate new specific syntax tests with main test suite dropped after discussion with @jacobpake
• article/non-renewables broken: only one point in scatterplot, dependencies borked
• Improvements to error reporting ✅ enough on this for now
• Highlightable instances in new prettyprinter
• Migrate remaining websites
  • Merge misc examples into article
• Migrate all test cases to new syntax
  • incomplete patterns error in dtw cases
• Restore comments in prelude.fld
• Restore indentation strictness? see Remaining indentation fixes #1440
• Remove migration tests and infrastructure
  • Delete spurious files in fluid (e.g. test.fld, pi.fld)
• Incorporate parenthesis improvements from old prettyprinter
• @rolyp to review and finalise
  • Restore comments to graphics.fld
  • Parse/Constants
    • Where are these used?
    • Some redundancy with Parse/Parser.purs/keywords
  • Pretty.Constants -- thought we decided not to use the constand definitions after all?
  • Pretty.Helpers -> Util
  • prettyParseError probably doesn't need its own module
  • Pretty.Config may not need its own module?
  • Bump patch version again
  • Delete our version of Array.transpose

---

One idea to make Fluid an easier target for generative AI would be to make the syntax resemble a pure dialect of Python.

I think there is only so far you could push this, partly because of the purity, and also because the Python version of pattern matching is pretty clunky:

def describe_shape(shape):
    match shape:
        case Circle(radius):
            return f"A circle with radius {radius}"
        case Rectangle(width, height):
            return f"A rectangle with width {width} and height {height}"
        case _:
            return "Unknown shape"

But one could imagine allowing something like the following:

def describe_shape(Circle(radius)):
    return f"A circle with radius {radius}"

def describe_shape(Rectangle(width, height)):
    return f"A rectangle with width {width} and height {height}"

def describe_shape(_):
    return "Unknown shape"

A secondary (and potentially significant) advantage would be that Python folk would find Fluid an easy language to switch to. I would be tempted to do this sooner rather than later, but unfortunately this would be a non-trivial amount of work, not least because Python is indentation-sensitive.

[rolyp]

@dorchard Mock-up of Python-esque Fluid (moving-average example):

def nthPad (n, xs):
   return nth(min(max(n, 0), length(xs) - 1), xs)

def movingAvg (ys, window):
   return
      [ sum([ nthPad(n, ys) for n in range(i - window, i + window) ]) / (1 + 2 * window)
        for i in range(len(ys))
      ]

# support curried functions?
def movingAvg_(rs, window):
   return zipWith(
      lambda x, y: {x: x, y: y},
      map(lambda r: r.x, rs),
      movingAvg(map(lambda r: r.y, rs), window)
   )

# generalise `def` to variables
def points:
   [ { x: r.year, y: r.emissions } for r in methane if r.type == "Agriculture" ]

# support for a single top-level expression?
LineChart(
   tickLabels = { x: Orientation.ROTATED, y: Orientation.DEFAULT },
   size = { width: 330, height: 285 },
   caption = "SSP5-8.5 projected methane emissions (Agriculture)",
   plots =
      [ LinePlot(name = "Moving average", points = movingAvg_(points, 1))
      , LinePlot(name = "Original curve", points = points)
      ]
)

Since def in Python (I think) requires a parenthesised argument list (even for a nullary function), that leaves room to appropriate def for variable definitions too (since there won’t be any syntactic ambiguity).

[rolyp]

The lambda syntax is the only bit of Python syntax that seems completely gratuitous, so I propose we support two notations for anonymous functions:

(x, y): {x: x, y: y}
# or perhaps
fun (x, y): {x: x, y: y}
# equivalent to
lambda x, y: {x: x, y: y}

I don’t think this will present any ambiguity problems. The advantages of the alternative notations are:

• Lose obfuscating lambda keyword
• Same use of parentheses as in def
• def f (x, y): {x: x, y: y} can now be read literally as “define f to be the function (x, y): {x: x, y: y}”

Note that under the proposal to extend def to variables, def f: (x, y): {x: x, y: y} would be equivalent syntax (note the extra colon), which is a bit odd, but not much more odd than def f: lambda x, y: {x: x, y: y}.

[rolyp]

An additional issue to consider is the meaning of return, which in Python allows for (local) transfers of control, i.e. returning from the containing function. To have return in the syntax of functions and if statements but to rule out this use case would potentially be a bit contrived, so we might want to think about extending the semantics with return as well. This would still keep the language effectively pure modulo runtime errors (a function which failed to return would be a runtime error).

[rolyp]

For for loops, as @JosephBond pointed out we can support the for x in notation of Python (in addition to the for in comprehensions as sketched out above), without adding mutable variables, by desugaring to an application of map (although not sure if that would allow for return within the loop, so this might not be straightforward without non-local control operators).

[rolyp]

A relatively easy first step here would be to replace let x = e1; let y = e2; .. in e by def x = e1; def y = e2; e (omitting in). We could probably do a bunch of small changes like this before biting off indentation-sensitivity.

As Tia discovered, using : a la Python instead of = is not straightforward because : is also a list constructor and the “binder” in a let can be an arbitrary pattern.

[jacobpake]

Does it make sense if function definition, function calls look like Python but given

def add(x,y): 
    return x + y

these are all OK and just alternate syntax around App?

# Let z (App (App add x) y)
z = add(x, y)

# Let z (App (App add x) y)
z = add(x)(y)

# Let addx (App add x)
addx = add(x)

# Let z (App addx y)
z = addx(y)