[elm-discuss] Multiple "Middleware" pattern instead of single *.program

[Martin Janiczek]

Hello elm-discuss!

I've been thinking about the **.program* pattern. Currently one has to 
choose one of the many different *.program functions 
 and implement the rest 
of the functionality themselves, ie. they can't mix and match, say, 
*Navigation.program* and *TimeTravel.Html.program*.

A way to solve that would be to specify a list of "middlewares" that each 
do a specific task, and have a "clean" program they all augment:

main =
combineMiddleware
Navigation.middleware
TimeTravel.middleware
DropboxAuth.middleware
App.program

I have tried to implement such a pattern and want to share it and ask for 
opinions. *This could, after all, be a very bad idea!*



Some links:

   - GitHub  (I didn't want to 
   publish that as a package just yet, but if it helps somebody, tell me and I 
   can do that)
   - Tour of the code:
  - The *main* function 
  
  - The *program* (business logic) 
  
 
  (a counter)
  - A *middleware* "talking" to the program 
  

 (returns 
  it from update)
  - A *middleware* logging "all the Msgs under it" 
  
 
(this 
  + the Reset middleware could, with a bit of effort, become a Debugger 
  middleware)
  - A *middleware* using its own Subs 
  

 (the 
  middlewares can use Subs, Cmds, have their own model)
   


This allows people to combine multiple behaviours instead of being limited 
to just one.

*Questions I'm pondering are:*


   1. Is this a good idea at all?
   2. Comparison to the "fractal TEA" that we generally shun now. (Hiding 
   of behaviour; in fractal TEA one sees the extra functionality in the model, 
   here it's almost invisible; does one need to see it? This approach avoids 
   some boilerplate -- the only thing end user needs to supply is a Msg 
   constructor, similar to *.program)
   3. Does this encourage some bad practices, code smell, OOP in a FP 
   language, componentization? Good/bad? (If bad, is the *.program pattern we 
   currently somehow embrace OK then? I'd say it does things /hides behaviour/ 
   basically the same way.)



And, for the interested, some implementation details:

   - Each middleware knows about the next model in the chain (they're 
   nested), but can't inspect it. (If it used concrete type instead of a type 
   variable, it would limit what other middlewares/programs can be next to it.)
   - The Msgs are also nested: each middleware has to have one Msg for 
   wrapping the Msgs of the next middleware/program in the chain.
   - All middlewares can send messages *to the program* (but not to each 
   other):
  - the program exposes a record with Msg constructors it offers 
  alongside update, init, etc.
  - each middleware declares what Msg constructors it needs (through an 
  extensible record) -- very similar to how Navigation.program needs a 
  Msg constructor for the location changes 
  

  .
  - the compiler makes sure all middleware Msg needs are satisfied
  - middleware's update gets the record with the constructors as an 
  argument, and returns a Maybe Program.Msg
  - the Msg gets threaded through the Elm Runtime as any other, and the 
  user gets a nice clean Msg in their update.
   
And some API:

middleware : 
{ init : (innerModel, Cmd innerMsg) -> (ownModel, Cmd ownMsg)
, update : ownMsg -> ownModel -> programMsgs -> (ownModel, Cmd ownMsg, 
Maybe programMsg)
, subscriptions : ownModel -> Sub ownMsg
, view : ownModel -> innerHtml as Html ownMsg -> Html ownMsg
, wrapMsg : innerMsg -> ownMsg
, unwrapMsg : ownMsg -> Maybe innerMsg
}

where

ownModel = { ownFields | innerModel : innerModel }

program :
{ init : (model, Cmd msg)
, update : msg -> model -> (model, Cmd msg)
, subscriptions : model -> Sub msg
, view : model -> Html msg
, programMsgs : programMsgs
}

where

programMsgs = (eg.) { locationChanged : Location -> Msg }



-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: The NumPy for Elm

['Rupert Smith' via Elm Discuss]

On Tuesday, October 31, 2017 at 12:32:06 PM UTC, Francisco Ramos wrote:
>
> https://github.com/jscriptcoder/numelm
>
> Please, any feedback would be highly appreciated.
>

So, I have a project at work where we are using NumPy running on AWS. I 
have been looking into how to write AWS Lambda functions using Elm, and 
found this excellent project:

http://package.elm-lang.org/packages/ktonon/elm-serverless/latest
https://github.com/ktonon/elm-serverless

One cool thing about how it is implemented, is that it uses a wrapper 
around the Elm program to establish a new type of 'Program'. As such it 
doesn't have ports or hacked any kernel code - yet it is definitely 
stretching Elm well outside of it comfort zone as a client side only 
language. I think that is pretty neat, because my instincts would have been 
either to use ports or do some kernel hacking and ended up with code that I 
could not then share on package.elm-lang.org. I somehow automatically 
assume that doing anything with elm that is not TEA is going to involve 
native code in such a way that a non-shareable package is created and the 
back-door that is elm-github-install will be used.

My work project involves running an algorithm in NumPy against 10s or 100s 
of days of data points and doing some curve fitting to then make an 
estimate of when some equipment is going to exceeed its specified operating 
parameters (I'm being vague because I signed an NDA).

So once I get my Elm Lambda functions experiment working nicely, I can try 
out converting the NumPy algorithms into NumElm. All the NumPy algorithms I 
have are quite short, its fairly simple stuff we are doing. Even if NumElm 
turns out a bit slow, its only a few hundred data points at most so I think 
it will be ok. I also think fetching the data from the database (Athena) 
will tend to dominate rather than the CPU work.

How would I write a curve fitting alrogithm with this? So I have a 3rd 
order polynomial:

y = a + b.x + c.x^2 + d.x^3

and some linear algebra on 100 data points will yield values for a, b, c 
and d. I'll post up the python code tomorrow, it seems to use an in-built 
fit_curve() function.

Rupert

 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] What build system do you prefer for Elm?

[Zachary Kessin]

I generally just use GNU Make, I also use it to kick off other builds in
the project so that works well.

Zach
ᐧ

On Wed, Nov 1, 2017 at 12:53 AM, Dustin Farris 
wrote:

> I’ve been using broccoli for 8 months now and very happy.
>
> Here’s a plugin I made for elm: https://github.com/
> dustinfarris/broccoli-elm-make
>
> If you end up trying it I’d love your feedback!
>
>
> On Oct 31, 2017, at 10:18 AM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com> wrote:
>
> I've been using grunt up until now. Looking into webpack at the moment as
> a few github projects I've been looking at use it.
>
> Anyone got any thoughts on the advantages/disadvantages of the various
> possibility wrt Elm?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Zach Kessin
Reduce project risk with training in Elm For web teams
Skype: zachkessin
+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.