Authoring in Scala

[AttilaMihaly]

Making in possible to write Morphir models in Scala has been an active topic of conversation in our community but we haven't publicly discussed the specifics yet. The goal of this post is to kick-start that process.

I think one of the first things we should decide is whether we want the Scala code that represents the business logic to be used as the logic that will be executed at runtime or just as a model that is still generated into executable Scala code. Maybe the former sounds like the trivial thing to do but it does affect what the mapping would look like.

The next thing would be how each language feature maps between Scala and Morphir. I took a stab at that and came up with the below. I looked at it from the Morphir feature perspective since that's the smaller language so it's easier to list out those features:

• Types
  • Type definitions
    • Types in the SDK
      • Basics.Bool - Bool
      • Basics.Float - Double
      • Basics.Int - BigInt
      • Basics.Never - Nothing
      • Basics.Order - ?
      • Char.Char - Char
      • Decimal.Decimal - BigDecimal
      • Dict.Dict - Map
      • List.List - List
      • LocalDate.LocalDate - Localdate
      • LocalTime.LocalTime - LocalTime
      • Maybe.Maybe a - Option[a]
      • Month.Month - ?
      • Regex.Regex - ?
      • Result.Result - ?
      • Set.Set a - Set[a]
      • String.String - String
    • User-defined types
      • Type aliases - supported
      • Named records - case classes
      • Tagged-unions - sealed trait hierarchy
  • Type expressions
    • Variable - generic types - supported
    • Reference - reference to other types - supported
    • Tuple - tuple - supported (22 element limit)
    • Record - case class instance or structural type
    • ExtensibleRecord - structural type
    • Function - function -supported (22 arg limit)
    • Unit - Unit - supported
• Functions
  • Function definitions
    • Functions in the SDK
      • There are too many of these to list out here but we'll need a mapping for each
    • User-defined functions
      • The differences here is that Scala supports multiple parameter lists but doesn't do currying out-of-the-box. We need to figure out a sensible mapping between the two.
  • Value expressions
    • Literal - supported
    • Constructor - supported (case class/object constructor)
    • Tuple - supported (22 element limit)
    • List - supported
    • Record - supported (case class or structural value)
    • Variable - supported
    • Reference - supported
    • Field - supported foo.bar
    • Field Function - supported _.foo
    • Apply - supported (currying and multiple argument support are differences here)
    • Lambda - supported (Scala requires type annotations for arguments in many cases)
    • Let definition - supported (val or def within function body)
    • Let recursion - supported (recursive def within function body)
    • Destructure - supported
    • If-then-else - supported (Scala supports if without else)
    • Pattern-match - supported (Scala has more features)
    • Update Record - supported foo.copy(bar = 1) (only on case classes)
    • Unit - supported {}

This is what I have so far. What do you think?

@DamianReeves, @deusaquilus

[psmulovics]

@granicz FYI, this can be useful for the F# work too

[granicz]

How and where semantic errors in these models surface is an important aspect to consider. Morphir models in Scala or F# can only be directly executed if you can fail at compile time on all model code that doesn't map to MIR (it would be nasty to let things fail at runtime - and conversely, for all code ABC that compiles, runMIR(toMIR(ABC)) has the same semantics as ABC). This is not impossible (say, in F#, you can use type providers to generate code on the fly to include in the compilation), but not terribly easy nor practical to implement.

So the most likely scenario would be to use these Scala/F# models to generate MIR (as JSON) and pass it along the pipeline for further processing/execution (or else fail during MIR generation). This can be done either by making the Scala/F# code result in MIR (through an SDK of source helpers that construct MIR - possibly at the expense of a slightly awkward syntax) - this always compiles, or by applying some heavy metaprogramming to construct MIR from the actual source code (traversing the reified source AST, doing semantic checks, using the mappings you identified to resolve/map types and functions, etc.) - which would be roughly similar to attempting to do the same at compile time using type providers, etc.

[BerryBomarB14]

The level of detail that you've gone into in terms of mapping Scala features to Morphir features is impressive, and I can't wait to see how this project progresses.

[DamianReeves]

Concerning these:

Month.Month - ?
Regex.Regex - ?
Result.Result - ?

I'd suggest adding modules that map to the Morphir.SDK API as we've done for others. We can use type aliasing to point the actual type to the corresponding native types (i.e. java.time.Month for Scala).

[AttilaMihaly]

Makes sense

[DamianReeves]

Concerning this:

Record - supported (case class or structural value)

Where possible we should emit case classes and not rely on structural values as structural values have a heavy reflection based cost. Scala 3 does open the door for having something more performant under the covers for structural types, but I'd view this as a stretch goal.

[AttilaMihaly]

Completely agree. In the Morphir -> Scala path we already try to generate case classes where possible. Anywhere where we map to a structural type we consider it a temporary solution until we figure out how to do a concrete type.