Re: [elm-discuss] Embedding multiple elements into JS

[Matt Joiner]

I got help on Slack, thanks.

On Friday, 24 March 2017 09:01:34 UTC+11, Witold Szczerba wrote:
>
> OK, so what exactly is the problem in your case?
>
> 22.03.2017 3:36 PM "Matt Joiner"  
> napisał(a):
>
>> I'm looking to embed Elm in an existing web application gradually. I find 
>> it most appropriate in my projects to embed multiple elements, not a single 
>> parent element. For example I have some bootstrap:
>>
>> 
>>
>> I want to run Elm.Main.embed(document.getElementById('some-list')), and 
>> have that main return multiple  elements. Clearly I can't have Elm 
>> return a parent  because then I have . I also can't 
>> have Elm return the  because 
>> then there's no #some-list to embed it on in the first place.
>>
>> Look forward to suggestions, thanks.
>>
>> -- 
>> 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...@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.

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

[Yosuke Torii]

I have two real-world examples. Nothing is modified at all.


1. Update inner structure

canvasPosition : Model -> Position
canvasPosition model =
  let
pos =
  model.mousePosition
  in
{ pos | y = pos.y - headerHeight }



2. Add field to make extended record (cannot use update syntax)

type alias Note =
  { position : Int
  , note : Int
  , velocity : Int
  , length : Int
  }


type alias Detailed a =
  { a | track : Int, channel : Int }


addDetails : Int -> Int -> Note -> Detailed Note
addDetails track channel note =
  { position = note.position
  , note = note.note
  , velocity = note.velocity
  , length = note.length
  , channel = channel
  , track = track
  }



2017年3月3日金曜日 15時12分39秒 UTC+9 Richard Feldman:
>
> There have been various discussions of potential ways to improve Elm's 
> record update syntax. Evan commented that "(examples > design work) at this 
> point" - any potential designs for syntax improvements would need to be run 
> through a gauntlet of examples to see how well they'd work, so the first 
> step in the process is to gather those examples.
>
> So let's collect a ton of different real-world examples! That will help 
> guide the design process.
>
> If you've run into a record update that you felt was painful and could be 
> improved in some way, please post it here! (Also, *please keep this 
> thread for posting of examples* *only* - it'll be easier to link back 
> here during design discussions if we can reference a clean thread of 
> examples, as opposed to a mismash of examples interleaved with suggestions.)
>

-- 
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: 'Native' -> 'Kernel': a msgpack example

[Martin Bailey]

I suggested in elm-dev that adding a BitStream interface in Elm would make 
this kind of JS interop unnecessary. As it stands, one can't implement 
MsgPack in Elm since the only link to the outside world is JSON/String and 
binary data isn't valid UTF-16. I'd like to implement LZ-String in Elm for 
local storage compression but am not sure whether that'll be possible at 
some point. In the meantime, you can still write native/kernel code but 
just can't share it with the ecosystem.

-- 
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] Re: Elm events 2017

[Duane Johnson]

Hi Salas, since you had two nearly identical posts, I approved this one and
rejected the other (I'm assuming you didn't know we moderate first-time
posters).

-- Duane Johnson (elm-discuss moderator)

On Thu, Mar 23, 2017 at 4:47 PM, Salas Sanchez-Bennasar 
wrote:

> I'm trying to announce this conference as widely as possible, and given
> all the elm talks, I think it may be relevant here:
>
>
> http://lambdaconf.us/events/2017/lcusc.html
>
> LambdaConf is one of the largest functional programming conferences in the
> world, focused on foundational concepts (such as lambda calculus, type
> theory, category theory), functional programming languages (Haskell, Scala,
> PureScript, F#, Clojure, Elixir, and more), new languages and approaches in
> functional programming, functional programming libraries, and related areas
> such as dependent types, proof systems, parallel array programming,
> functional GPU processing, and more.
>
> Standard registration is now open at Eventbrite:
>
> https://www.eventbrite.com/e/lambdaconf-2017-registration-29839799644
>
> A complete list of sessions is online, including the following highlights:
>
>  * 6 keynotes, including one on using Haskell to model life on the
> blockchain, one on how programmers brains work, and one on the axes of
> abstraction;
>  * 8 leap workshops, including an in-depth workshop on category theory,
> one on optics, and one on building front-ends using PureScript Halogen;
>  * 12 hop workshops, including one introducing Coq, another diving into
> recursion schemes, and another teaching functional data processing;
>  * 9 de novo sessions, including on one formally specified digital logic,
> one on algebraic and monadic composability for distributed computing, and
> one on type-level REST programming;
>  * 21 educational sessions, including one on Free monads, one on
> high-performance Haskell, one on codata and corecursion, one on FP on
> Android using Frege, and another on dependently-typed programming in
> Haskell;
>  * 21 inspire sessions, including one on dependent-pairs, one on
> generative design, and one on type singletons.
>
> This is more than 110 hours of content, with enough variety and difficulty
> level for everyone. Speakers are book authors, contributors to open source
> libraries, researchers, and practicing functional programmers.
>
> The conference takes place in Boulder, Colorado, from May 25 - 27, at the
> University of Colorado Boulder in the foothills of the Rocky Mountains.
> Conference registration includes all sessions (including workshops),
> locally-catered breakfast and lunch on Thursday, Friday, and Saturday; a
> conference dinner on Friday night; a choice from a variety of networking
> activities on Sunday; free childcare and STEM workshops for children;
> all-gender restrooms and handicapped-accessible venues.
>
> Videos from some previous events can be found here:
> https://www.youtube.com/channel/UCEtohQeDqMSebi2yvLMUItg; and here:
> https://www.youtube.com/watch?v=JxC1ExlLjgw=PLE7t
> QUdRKcybh21_zOg8_y4f2oMKDHpUS
>
> The conference is preceded by commercial training opportunities on Monday
> - Tuesday, including:
>
>  * Up & Running with Elixir & Phoenix, by Brooklyn Zelenka
>  * Applied Haskell, by Michael Snoyman
>  * Advanced FP in Scala, by John A. De Goes
>  * Introduction to FP, by David Koontz
>  * Mastering Apache Spark, by Pawel Szulc
>  * Mastering Elm, by Isaac Shapira
>
> On Wednesday, several free mini-conferences are co-located with LambdaConf:
>
>  * PureScript Conf 2017
>  * Introduction to FP with Haskell
>
> For more information on LambdaConf, the commercial training workshops, or
> the mini-conferences, please visit the website:
>
> http://lambdaconf.us/events/2017/lcusc.html
>
> Regards,
>
> Salas Sanchez-Bennasar
>
>
>
>
> On Thursday, January 5, 2017 at 4:19:39 PM UTC-7, Rupert Smith wrote:
>
> Thinking of drawing up a list of events, dates and places where Elm will
> be on the menu in 2017. Would people be interested in contributing what
> they know to build up the list? Also, I have a feeling someone may already
> have done this, in which case point me to it.
>
> --
> 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.

[elm-discuss] Re: Elm events 2017

[Salas Sanchez-Bennasar]

I'm trying to announce this conference as widely as possible, and given all 
the elm talks, I think it may be relevant here:


http://lambdaconf.us/events/2017/lcusc.html

LambdaConf is one of the largest functional programming conferences in the 
world, focused on foundational concepts (such as lambda calculus, type 
theory, category theory), functional programming languages (Haskell, Scala, 
PureScript, F#, Clojure, Elixir, and more), new languages and approaches in 
functional programming, functional programming libraries, and related areas 
such as dependent types, proof systems, parallel array programming, 
functional GPU processing, and more.

Standard registration is now open at Eventbrite:

https://www.eventbrite.com/e/lambdaconf-2017-registration-29839799644

A complete list of sessions is online, including the following highlights:

 * 6 keynotes, including one on using Haskell to model life on the 
blockchain, one on how programmers brains work, and one on the axes of 
abstraction;
 * 8 leap workshops, including an in-depth workshop on category theory, one 
on optics, and one on building front-ends using PureScript Halogen;
 * 12 hop workshops, including one introducing Coq, another diving into 
recursion schemes, and another teaching functional data processing;
 * 9 de novo sessions, including on one formally specified digital logic, 
one on algebraic and monadic composability for distributed computing, and 
one on type-level REST programming;
 * 21 educational sessions, including one on Free monads, one on 
high-performance Haskell, one on codata and corecursion, one on FP on 
Android using Frege, and another on dependently-typed programming in 
Haskell;
 * 21 inspire sessions, including one on dependent-pairs, one on generative 
design, and one on type singletons.
 
This is more than 110 hours of content, with enough variety and difficulty 
level for everyone. Speakers are book authors, contributors to open source 
libraries, researchers, and practicing functional programmers.

The conference takes place in Boulder, Colorado, from May 25 - 27, at the 
University of Colorado Boulder in the foothills of the Rocky Mountains. 
Conference registration includes all sessions (including workshops), 
locally-catered breakfast and lunch on Thursday, Friday, and Saturday; a 
conference dinner on Friday night; a choice from a variety of networking 
activities on Sunday; free childcare and STEM workshops for children; 
all-gender restrooms and handicapped-accessible venues.

Videos from some previous events can be found here: 
https://www.youtube.com/channel/UCEtohQeDqMSebi2yvLMUItg; and here: 
https://www.youtube.com/watch?v=JxC1ExlLjgw=PLE7tQUdRKcybh21_zOg8_y4f2oMKDHpUS

The conference is preceded by commercial training opportunities on Monday - 
Tuesday, including:

 * Up & Running with Elixir & Phoenix, by Brooklyn Zelenka
 * Applied Haskell, by Michael Snoyman
 * Advanced FP in Scala, by John A. De Goes
 * Introduction to FP, by David Koontz
 * Mastering Apache Spark, by Pawel Szulc
 * Mastering Elm, by Isaac Shapira
 
On Wednesday, several free mini-conferences are co-located with LambdaConf:

 * PureScript Conf 2017
 * Introduction to FP with Haskell

For more information on LambdaConf, the commercial training workshops, or 
the mini-conferences, please visit the website:

http://lambdaconf.us/events/2017/lcusc.html

Regards,

Salas Sanchez-Bennasar




On Thursday, January 5, 2017 at 4:19:39 PM UTC-7, Rupert Smith wrote:

Thinking of drawing up a list of events, dates and places where Elm will be 
on the menu in 2017. Would people be interested in contributing what they 
know to build up the list? Also, I have a feeling someone may already have 
done this, in which case point me to it.

-- 
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] Kite, An Interactive Visualization Tool for Graph Theory

[Duane Johnson]

Very cool project!

I saw this today and was equally impressed: http://ncase.me/loopy/v1/

It might be a source of ideas for your own UI (I like the way a user can
just "draw" a node and then connect them in this Loopy app).

Thanks for highlighting the portions of your app that may be useful to
others!

Duane

On Thu, Mar 23, 2017 at 4:26 PM, Erkal Selman  wrote:

> I would like to announce that I open sourced my hobby project, which I
> named Kite. Here is the demo . Here is the
> source .
>
> I am interested in visualising mathematical ideas, in particular,
> constructions, algorithms and games from the areas mathematical logic,
> combinatorics and theoretical computer science.
>
> My journey with Elm started 2 years ago with this question in Elm Discuss
> .
>
> I am not a developer and I am sure that my code has many problems. I would
> be very happy if you would take a look over the code and point out the
> wrong practices.
>
> I try to keep the number of libraries that I depend on as small as
> possible. I try to write my own small libraries which serve my own
> purposes. Some of them may be useful for your projects, too. There are two
> modules in Kite, of which I think that they may be useful in other contexts:
>
>- FileSystem
>
>can be used with any file type, not only for graphs. Say, you want to
>implement something like the Atom text editor in Elm, you can use this
>module.
>- PanAndZoom
>
>can be used for panning and zooming on SVG elements. I think that my code
>organization for this module is bad. But I also couldn't find a better way.
>I certainly need help here.
>
> I am planning to add many functionalities to Kite. My gut feeling is that
> first I should simplify the basis infrastructure as much as possible before
> adding new features. Therefore, ideas about simplification are most
> welcome. But I would be happy for any kind comment or pull-request.
>
> --
> 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.

[elm-discuss] Kite, An Interactive Visualization Tool for Graph Theory

[Erkal Selman]

I would like to announce that I open sourced my hobby project, which I 
named Kite. Here is the demo . Here is the 
source .

I am interested in visualising mathematical ideas, in particular, 
constructions, algorithms and games from the areas mathematical logic, 
combinatorics and theoretical computer science. 

My journey with Elm started 2 years ago with this question in Elm Discuss 
.

I am not a developer and I am sure that my code has many problems. I would 
be very happy if you would take a look over the code and point out the 
wrong practices. 

I try to keep the number of libraries that I depend on as small as 
possible. I try to write my own small libraries which serve my own 
purposes. Some of them may be useful for your projects, too. There are two 
modules in Kite, of which I think that they may be useful in other contexts:

   - FileSystem 
    
   can be used with any file type, not only for graphs. Say, you want to 
   implement something like the Atom text editor in Elm, you can use this 
   module.
   - PanAndZoom 
    
   can be used for panning and zooming on SVG elements. I think that my code 
   organization for this module is bad. But I also couldn't find a better way. 
   I certainly need help here.

I am planning to add many functionalities to Kite. My gut feeling is that 
first I should simplify the basis infrastructure as much as possible before 
adding new features. Therefore, ideas about simplification are most 
welcome. But I would be happy for any kind comment or pull-request.

-- 
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] Embedding multiple elements into JS

[Witold Szczerba]

OK, so what exactly is the problem in your case?

22.03.2017 3:36 PM "Matt Joiner"  napisał(a):

> I'm looking to embed Elm in an existing web application gradually. I find
> it most appropriate in my projects to embed multiple elements, not a single
> parent element. For example I have some bootstrap:
>
> 
>
> I want to run Elm.Main.embed(document.getElementById('some-list')), and
> have that main return multiple  elements. Clearly I can't have Elm
> return a parent  because then I have . I also can't
> have Elm return the  because
> then there's no #some-list to embed it on in the first place.
>
> Look forward to suggestions, thanks.
>
> --
> 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.

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Robin Heggelund Hansen]

The barriers are already built, the recent discussion mostly revolves on 
how we talk about the current barriers to make things more clear for 
beginners. Nothing is going to prevent you from using native/kernel code in 
your own project. You just won't be able to share it on elm-packages (which 
is still the case today).

torsdag 23. mars 2017 21.15.51 UTC+1 skrev Simon følgende:
>
> On elm-dev I get the impression that bigger barriers are being built to 
> towards javascript interop.
>
> I think building the barriers before the webapi is provided in Elm is the 
> wrong way around, but that's not the only case where practical needs are at 
> risk.
>
> Consider msgpack - a sort of compressed json. It's well specified but 
> today not much used. No one has written a library for it in Elm, but there 
> is a well-tested JS one. The encoding is simply calculations, so in the 
> normal run of things this should be a synchronous operation. If ports 
> returned Tasks this would not be a huge issue, but they return Commands and 
> thus force you back around the update loop (and the creation of an extra 
> Msg, which makes code intent less transparent).
>
> The work around is a native file along the lines of (or see this NoRedInk 
> library 
> ):
>
> ```
> var _user$project$Native_Msgpack = function() {
>
> function encode(k) {
> return msgpack.encode(k.kwd);
> }
> }
> ```
>
> It's pretty clear that these practices are frowned upon, but the shift to 
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
> further. I hope that's not the case.
>
>

-- 
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] 'Native' -> 'Kernel': a msgpack example

[Aaron VonderHaar]

Thanks for sharing your impressions.  Is there a particular question you're
hoping to have answered or a proposed or attempted solution that you'd like
to discuss?



On Thu, Mar 23, 2017 at 1:15 PM, Simon  wrote:

> On elm-dev I get the impression that bigger barriers are being built to
> towards javascript interop.
>
> I think building the barriers before the webapi is provided in Elm is the
> wrong way around, but that's not the only case where practical needs are at
> risk.
>
> Consider msgpack - a sort of compressed json. It's well specified but
> today not much used. No one has written a library for it in Elm, but there
> is a well-tested JS one. The encoding is simply calculations, so in the
> normal run of things this should be a synchronous operation. If ports
> returned Tasks this would not be a huge issue, but they return Commands and
> thus force you back around the update loop (and the creation of an extra
> Msg, which makes code intent less transparent).
>
> The work around is a native file along the lines of (or see this NoRedInk
> library 
> ):
>
> ```
> var _user$project$Native_Msgpack = function() {
>
> function encode(k) {
> return msgpack.encode(k.kwd);
> }
> }
> ```
>
> It's pretty clear that these practices are frowned upon, but the shift to
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options
> further. I hope that's not the case.
>
> --
> 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.

[elm-discuss] 'Native' -> 'Kernel': a msgpack example

[Simon]

On elm-dev I get the impression that bigger barriers are being built to 
towards javascript interop.

I think building the barriers before the webapi is provided in Elm is the 
wrong way around, but that's not the only case where practical needs are at 
risk.

Consider msgpack - a sort of compressed json. It's well specified but today 
not much used. No one has written a library for it in Elm, but there is a 
well-tested JS one. The encoding is simply calculations, so in the normal 
run of things this should be a synchronous operation. If ports returned 
Tasks this would not be a huge issue, but they return Commands and thus 
force you back around the update loop (and the creation of an extra Msg, 
which makes code intent less transparent).

The work around is a native file along the lines of (or see this NoRedInk 
library ):

```
var _user$project$Native_Msgpack = function() {

function encode(k) {
return msgpack.encode(k.kwd);
}
}
```

It's pretty clear that these practices are frowned upon, but the shift to 
'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
further. I hope that's not the case.

-- 
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] Web components vs. Native

[Maxwell Gurewitz]

What room are you in in the elmlang slack peter?  Web components elements 
have lifecycle hooks, including hooks which will be fired when the 
component is attached/rendered.

https://www.webcomponents.org/community/articles/introduction-to-custom-elements

They can produce any number of effects in these hooks: throw exceptions, 
trigger alerts, utilize random numbers, make http requests etc.  To 
re-iterate, these effects can cause web components to break the replay 
functionality of elm-debugger, as the web components are repeatedly 
re-rendered.

On Thursday, March 23, 2017 at 4:15:20 AM UTC-7, Peter Damoc wrote:
>
> On Thu, Mar 23, 2017 at 9:33 AM, Maxwell Gurewitz  > wrote:
>
>>
>> > You will be able to use a web component ONLY in the view will be as 
>> pure as it is right now. 
>>
>> Unless I'm misunderstanding you, I'm pretty sure this isn't true.
>>
>
> Wonderful! Maybe you can help me with an exploration. 
> I'm aiming to create a proof of concept where a web-component could be 
> used in such a way that it behaves like a "mutation as service". (I'm 
> hoping to not be able to do it) 
> Please contact me on Slack if you are interested. 
>  
>  
>
>> Any violation of purity that is available to native code is also 
>> available to web components, given that web components can execute 
>> arbitrary js when they render.  That's why we have silly non-presentational 
>> web components like polymer's ajax component 
>> https://github.com/polymerelements/iron-ajax.  
>>
>>
> As per the above, I would love to see a proof of concept that shows this. 
> In JS you have an imperative way of programming and you can do certain 
> things that are just impossible in the Elm world. 
>  
>
>> > Again, I don't think that the use of web components is encouraged. 
>>
>> Why do you feel that way?  My impression is that writing native code is 
>> discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
>> native code etc.) while the use of web components is encouraged (thus 
>> Richard's section on web components in Elm in Action).  
>>
>  
> I have spoken with Richard and this is a very sensible topic as there are 
> potential nasty consequences that might not be obvious from the start. 
> Web components do have their role to play and I'm assuming that Richard 
> might touch on his book on this BUT the topic has not been fully fleshed 
> out. 
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
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] To wrap or not to wrap

[Mark Hamburg]

Should one wrap a model implemented as a record in a type to keep the
details private? In other words:

type alias Model = { foo : Foo, baz : Baz }

- or -

type Model = M { foo : Foo, baz : Baz }

The former is much easier to work with because one isn't constantly
unwrapping and rewrapping.

The latter keeps code better encapsulated.

I had this discussion with a fellow programmer and he asked whether
immutability makes the encapsulation irrelevant. I argued no because the
exposure of internals means that client code can adopt dependencies on
internal choices — "Just because I have a field named 'foo' doesn't mean I
want a client to know about it" — and more significantly it allows
arbitrary code to create values purporting to be valid Model values. If one
can achieve "make invalid states impossible", that's obviously great but in
practice we rely on limiting construction to impose further invariants.
(For example, if the structures implementing an AVL tree were exposed, the
type system would ensure that we had a DAG but it could do nothing to
ensure anything about ordering or the height values.)

The balance we were left with was that "we're all programmers of good
character and we will consider other modules Models to be opaque even if
they aren't." (I'd have said "we're all gentlemen" but that's sexist.)
This, of course, works until we hire a programmer whose character isn't
quite as good in this regard.

How do others choose in this regard?

Mark

P.S. What I would like — though it would break a lot of existing code — is
for the fields of a record to only be exposed on export if explicitly
exposed a la exposing constructors for types.

-- 
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] Re: Elm FP vs Elm FRP

[Mark Hamburg]

Elm's FRP was always somewhat weak in that it didn't allow for monadic
(i.e., flatMappable) signals the way something like Rx does. There were
mathematical reasons for this — e.g., if you can create a signal that
counts mouse clicks then it should arguably give you the same values no
matter when you create it which effectively means that all signals need to
be created at the beginning of your program — but this restriction cost Elm
one of the best reasons for using something like Rx. So, the FRP patterns
in Elm got distilled down over time  into the fold over messages
architecture at the heart of TEA and then FRP went away.

Or at least that's my impression of what happened.

Mark

On Thu, Mar 23, 2017 at 4:05 AM Robert Walter 
wrote:

> Hi Eveline,
>
> Then why is Elm not a FRP anymore?
>
>
> Good question, and I guess the answer could become academic rather
> quickly. Still, what helped me understand it were some answers by Conal
> Elliot where he addresses "What is FRP?":
> http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language
> or
> http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631
> Funnily enough, Conal Elliot is not a big fan of the term FRP and tries to
> convince people to call it "denotative, continuous-time programming".
> Also, Stepen Blackheath felt compelled to make a statement to Elm dropping
> FRP: http://sodium.nz/t/my-comment-on-elm-dropping-frp/69
>
> Now, my attempt to answer your question: one of the two integral parts of
> FRP is to be "temporal continuous". To achieve this, you need a notion of
> "values of time". Elm used to have Signals that denoted exactly that
> (before 0.17). Other FRP systems distinguish between "Cells" and "Streams",
> which where kind of merged together to Signals in Elm.
> Anyway, without having Signals/Streams, i.e. "values over time", you
> cannot say that Elm has FRP baked in anymore. TEA separates data and logic
> completely. You have a model, and the Elm runtime allows you to operate
> (update) and transform (view) it to a representation that can be rendered
> by a browser.
>
> Hope this helps,
> Robert
>
> On Thursday, March 23, 2017 at 10:26:42 AM UTC+1, Eveline van Hal wrote:
>
> Hi everyone,
>
> I'm doing my graduating internship and working on an Elm application. I
> have been trying to figure out what the difference is between Elm before
> 0.17 and after.
>
> I have only used Elm 0.18, so I have not had the FRP experience, but from
> what I have read - the experience seems very much the same but simpler. Is
> this true? Then why is Elm not a FRP anymore?
>
> Further does Evan say in the Farewell to FRP post that there could be
> argued that Elm was never a FRP, but why?
>
> Thanks.
>
>
>
>
>
>
>
>
>
> --
>
>
> 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.

Re: [elm-discuss] Web components vs. Native

[Peter Damoc]

On Thu, Mar 23, 2017 at 9:33 AM, Maxwell Gurewitz 
wrote:

>
> > You will be able to use a web component ONLY in the view will be as pure
> as it is right now.
>
> Unless I'm misunderstanding you, I'm pretty sure this isn't true.
>

Wonderful! Maybe you can help me with an exploration.
I'm aiming to create a proof of concept where a web-component could be used
in such a way that it behaves like a "mutation as service". (I'm hoping to
not be able to do it)
Please contact me on Slack if you are interested.



> Any violation of purity that is available to native code is also available
> to web components, given that web components can execute arbitrary js when
> they render.  That's why we have silly non-presentational web components
> like polymer's ajax component https://github.com/polymerelements/iron-ajax.
>
>
>
As per the above, I would love to see a proof of concept that shows this.
In JS you have an imperative way of programming and you can do certain
things that are just impossible in the Elm world.


> > Again, I don't think that the use of web components is encouraged.
>
> Why do you feel that way?  My impression is that writing native code is
> discouraged (thus the lack of documentation, and Evan's elm-dev posts on
> native code etc.) while the use of web components is encouraged (thus
> Richard's section on web components in Elm in Action).
>

I have spoken with Richard and this is a very sensible topic as there are
potential nasty consequences that might not be obvious from the start.
Web components do have their role to play and I'm assuming that Richard
might touch on his book on this BUT the topic has not been fully fleshed
out.



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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: Elm FP vs Elm FRP

[Robert Walter]

Hi Eveline,

Then why is Elm not a FRP anymore?


Good question, and I guess the answer could become academic rather quickly. 
Still, what helped me understand it were some answers by Conal Elliot where 
he addresses "What is 
FRP?": 
http://stackoverflow.com/questions/5875929/specification-for-a-functional-reactive-programming-language
 
or 
http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631
Funnily enough, Conal Elliot is not a big fan of the term FRP and tries to 
convince people to call it "denotative, continuous-time programming".
Also, Stepen Blackheath felt compelled to make a statement to Elm dropping 
FRP: http://sodium.nz/t/my-comment-on-elm-dropping-frp/69

Now, my attempt to answer your question: one of the two integral parts of 
FRP is to be "temporal continuous". To achieve this, you need a notion of 
"values of time". Elm used to have Signals that denoted exactly that 
(before 0.17). Other FRP systems distinguish between "Cells" and "Streams", 
which where kind of merged together to Signals in Elm.
Anyway, without having Signals/Streams, i.e. "values over time", you cannot 
say that Elm has FRP baked in anymore. TEA separates data and logic 
completely. You have a model, and the Elm runtime allows you to operate 
(update) and transform (view) it to a representation that can be rendered 
by a browser.

Hope this helps,
Robert

On Thursday, March 23, 2017 at 10:26:42 AM UTC+1, Eveline van Hal wrote:
>
> Hi everyone,
>
> I'm doing my graduating internship and working on an Elm application. I 
> have been trying to figure out what the difference is between Elm before 
> 0.17 and after.
>
> I have only used Elm 0.18, so I have not had the FRP experience, but from 
> what I have read - the experience seems very much the same but simpler. Is 
> this true? Then why is Elm not a FRP anymore?
>
> Further does Evan say in the Farewell to FRP post that there could be 
> argued that Elm was never a FRP, but why?
>
> Thanks.
>

-- 
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] Elm FP vs Elm FRP

[Eveline van Hal]

Hi everyone,

I'm doing my graduating internship and working on an Elm application. I 
have been trying to figure out what the difference is between Elm before 
0.17 and after.

I have only used Elm 0.18, so I have not had the FRP experience, but from 
what I have read - the experience seems very much the same but simpler. Is 
this true? Then why is Elm not a FRP anymore?

Further does Evan say in the Farewell to FRP post that there could be 
argued that Elm was never a FRP, but why?

Thanks.

-- 
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] Web components vs. Native

[Maxwell Gurewitz]

Hey Peter,

> You will be able to use a web component ONLY in the view will be as pure 
as it is right now. 

Unless I'm misunderstanding you, I'm pretty sure this isn't true.

Any violation of purity that is available to native code is also available 
to web components, given that web components can execute arbitrary js when 
they render.  That's why we have silly non-presentational web components 
like polymer's ajax component https://github.com/polymerelements/iron-ajax. 
 

> Again, I don't think that the use of web components is encouraged. 

Why do you feel that way?  My impression is that writing native code is 
discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
native code etc.) while the use of web components is encouraged (thus 
Richard's section on web components in Elm in Action).  




On Wednesday, March 22, 2017 at 10:35:18 PM UTC-7, Peter Damoc wrote:
>
> To my understanding there is no promotion of the web components as a 
> standard way of interacting with JS. 
> They are mentioned as a way of encapsulating complex JS that might fail. 
> In other words, one could use some complex widget (like google-maps) and 
> get some functionality into their elm app *fully aware* of the risks 
> involved. 
>
> 1. Type safety:
>
> There is none with web components BUT, you do get a nice border control 
> and black-box encapsulation from the perspective of Elm. 
> It very similar to using ports only that from my perspective, the 
> interaction is nicer. 
>
> 2) Purity guarantees
>
> You will be able to use a web component ONLY in the view will be as pure 
> as it is right now. 
> You will not be able to interrogate the web component, you will have to 
> subscribe to its events just like you subscribe to onClick on a button. 
> This is very different from Native that you can use all over the place.
>  
> 3) Versioning guarantees 
>
> web components are not part of the Elm ecosystem and so, they are not and 
> will never be covered by elm-package. Maybe after we get the ability to 
> describe web-components in pure Elm, you will be able to find 
> web-components in elm-package. 
>
> So if the main motivation for discouraging the use of native is to promote 
>> safety, why encourage the use of web components?
>
>
> Again, I don't think that the use of web components is encouraged. 
> They are only an escape hatch that is available to Elm programmers. 
>
> These being said, I do believe that the mechanism of web-components has a 
> lot to offer to Elm. 
>
> I have played with some prototypes and the experience of writing 
> web-components in Elm is quite lovely. 
> In an ideal world, we don't use  in Elm but rather 
>  becomes an Elm implemented web-component. 
> The web-component standard could be the official way to embed and interact 
> with Elm apps. 
>
>
>
>
>   
>
> On Thu, Mar 23, 2017 at 1:57 AM, Maxwell Gurewitz  > wrote:
>
>> Hi all.  I'm creating this thread to discuss the relative merits of web 
>> components and native code.
>>
>> It's my perception that web components are being promoted within the elm 
>> community as a standard means of javascript interop, while writing native 
>> code is discouraged.  In particular, Richard Feldman has recently added a 
>> section on web components to his book Elm in Action (great book btw, you 
>> should totally buy it!), and I'd love to get his feedback.
>>
>> I don't understand this preference for web components over native code.  
>> As far as I can tell web components and native code lack all of the same 
>> safety guarantees.
>>
>> 1) Type safety:
>>
>> Both native code, and js inside of custom web components have the 
>> potential to raise exceptions, or produce invalid results due to a lack of 
>> type safety.
>>
>> 2) Non-determinacy:
>>
>> Both native code and js inside of custom web components have the 
>> potential to introduce non-determinacy.  You can imagine that the google 
>> maps web component might receive a 500 status response from google during 
>> an outage, or the author of the component might simply include a 
>> Math.random.  This will violate the guarantees made by the elm-debugger 
>> which disables port code from running for exactly this reason, which could 
>> prevent you from being able to reliable replay UI interactions.
>>
>> 3) Versioning guarantees:
>>
>> Neither native code nor web components can be published in elm-package, 
>> and they both include javascript, so neither can benefit from elm's semver 
>> enforcement.
>>
>> Now I understand that web components may be more ergonomic than 
>> equivalent native code in certain situations e.g. in the google maps case, 
>> but they don't seem any more or less safe than native code.  Furthermore, 
>> they impose the cost of an additional build system (bower) and polyfills.
>>
>> So if the main motivation for discouraging the use of native is to 
>> promote safety, why encourage the use of web components?
>>
>> Thanks.
>>
>> -- 
>> 

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

[Matthieu Pizenberg]

Here is a somewhat painful record update:

setImage : String -> String -> Image -> Model -> Model
setImage tool url image model =
let
mapping =
case tool of
"rectangle" ->
.rectangle model.resourcesMapping

"outline" ->
.outline model.resourcesMapping

"scribbles" ->
.scribbles model.resourcesMapping

_ ->
Dict.empty

id =
Dict.get url mapping
|> Maybe.withDefault -1

config =
model.config

newConfig =
case tool of
"rectangle" ->
{ config | rectangle = Dict.insert id (NoGT url image) 
config.rectangle }

"outline" ->
{ config | outline = Dict.insert id (NoGT url image) 
config.outline }

"scribbles" ->
{ config | scribbles = Dict.insert id (NoGT url image) 
config.scribbles }

_ ->
config
in
{ model | config = newConfig }


On Friday, March 3, 2017 at 2:12:39 PM UTC+8, Richard Feldman wrote:
>
> There have been various discussions of potential ways to improve Elm's 
> record update syntax. Evan commented that "(examples > design work) at this 
> point" - any potential designs for syntax improvements would need to be run 
> through a gauntlet of examples to see how well they'd work, so the first 
> step in the process is to gather those examples.
>
> So let's collect a ton of different real-world examples! That will help 
> guide the design process.
>
> If you've run into a record update that you felt was painful and could be 
> improved in some way, please post it here! (Also, *please keep this 
> thread for posting of examples* *only* - it'll be easier to link back 
> here during design discussions if we can reference a clean thread of 
> examples, as opposed to a mismash of examples interleaved with suggestions.)
>

-- 
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.