Type system
EasyMorph's type system is rather primitive:- Dataset -- a set of columns that represents a table state before or after a transformation
- Transformation properties -- a group of various transformation properties like file name, expression, boolean flag, etc.
Immutable identifiers
As in any other functional language, EasyMorph doesn't have variables. Instead it binds values to immutable identifiers. In our case identifiers can only be bound to datesets and project parameters which substitute some transformation properties.Functions
Every transformation in EasyMorph is basically a function. It takes one or two datasets and/or a set of transformation properties as arguments, and returns one dataset. For instance:let A = Deduplicate B
Since an EasyMorph project can have parameters, that makes entire project a function as well, where the parameters are the function arguments. In this case, the returned value is a dataset. While in programming languages a returned value is usually the last expression, in EasyMorph project the resulting table is simply marked with a flag, and its final dataset is returned to the calling project.
Function pipelining
Functions (transformations) can be pipelined (chained):let A = ImportText fileName
|> Filter (fun x -> x.Year = 2015)
|> Deduplicate
|> Trim 10 topRows
Iterate, map and fold
Iterations in EasyMorph actually perform iterations, mapping and folding:When Iterate transformation is used in Iterate mode it's basically similar to Seq.iter or Seq.map in OCaml/F#
When Iterate transformation is run in Iterate & Append mode it's somewhat similar to Seq.map |> Seq.fold as it creates multiple datasets, and then concatenates them into one dataset.
Function values
In functional languages functions can be passed as parameters. In EasyMorph one project can run another project and name of that other project can be defined by a parameter, which basically allows passing functions (projects) as parameters to other functions (projects).Resume
Of course, this analogy is not very strict and it has many limitations. For instance there is no any equivalent of recursion which is a corner stone feature of functional languages. Nevertheless, it gives some interesting ideas on how a transformation process can be organized in EasyMorph. For instance, it should be convenient to compose transformation processes from smaller reusable projects (should we rather call them modules?). Also such functional approach makes developing and debugging easier, as it's possible to split the logic into small relatively isolated functions that don't have side effects.If you find this analogy interesting and would like to discuss it -- feel free to shoot me an email.
UPDATE (8/30/2015)
One more similarity appeared recently:
