Re: [elm-discuss] Re: Randoms as LazyLists

roups.com> wrote: > > >> On Saturday, December 9, 2017 at 2:13:18 AM UTC, Mark Hamburg wrote: >> Functions get garbage collected. Otherwise think what would happen every >> time you use partial function application or define a function within a let >> or other ne

Re: [elm-discuss] Re: Randoms as LazyLists

. Mark > On Dec 8, 2017, at 6:13 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > Functions get garbage collected. Otherwise think what would happen every time > you use partial function application or define a function within a let or > other nested context. Because

Re: [elm-discuss] Re: Randoms as LazyLists

Functions are also heap allocated objects and reference other objects — e.g., decoders — just like other objects do. Mark > On Dec 7, 2017, at 2:32 AM, 'Rupert Smith' via Elm Discuss > <elm-discuss@googlegroups.com> wrote: > >> On Tuesday, December 5, 2017 at 5:16:22

Re: [elm-discuss] Re: Randoms as LazyLists

If you have a recursive JSON structure to decode, then the decoder either needs to refer to itself (a cycle) or it needs to generate a new decoder on each recursive step. Mark On Thu, Nov 30, 2017 at 2:43 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > > On

Re: [elm-discuss] Re: Randoms as LazyLists

My bad. Cyclic generator not decoder. Recursive decoders have the same issues. Mark > On Nov 27, 2017, at 8:45 AM, 'Rupert Smith' via Elm Discuss > <elm-discuss@googlegroups.com> wrote: > >> On Monday, November 27, 2017 at 4:33:57 PM UTC, Mark Hamburg wrote: >> That

Re: [elm-discuss] Re: Randoms as LazyLists

Nov 27, 2017, at 2:37 AM, 'Rupert Smith' via Elm Discuss > <elm-discuss@googlegroups.com> wrote: > > >> On Monday, November 27, 2017 at 7:50:01 AM UTC, Mark Hamburg wrote: >> P.S. Cyclic structures can be avoided by having the compiler perform a >> strongly conne

Re: [elm-discuss] Re: Randoms as LazyLists

Example usage of laziness: We have an expensive layout algorithm which depends both on the data being laid out and the view size. Whenever either of these changes, we need to re-run the layout algorithm but we would prefer to do the computation only when absolutely necessary and only once for

Re: [elm-discuss] Re: On Intl/CLDR

One way to maintain language portability to other environments is to make a distinction between the language and the libraries. Almost every environment is likely to have something special — that's part of what justifies being it's own thing. It is entirely reasonable to say that the Basics

Re: [elm-discuss] Elm with one message

If you are going to go that route, then you might as well just send the function to invoke back around through the message loop. Well, I guess that breaks the debugger in a way that sending the new model through the loop does not, but as noted previously sending the model has issues with async

Re: [elm-discuss] Elm with one message

1:57 AM, Vlad GURDIGA <gurd...@gmail.com> wrote: > > On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote: >> >> One other note: If you don't care about Reactor and the Debugger but do >> care about async problems, you could get almost the same structure

Re: [elm-discuss] Elm with one message

> On Thursday, August 24, 2017 at 7:18:44 PM UTC+3, Mark Hamburg wrote: >> Ignoring the commands and subscriptions part, I think this could be >> summarized as being built around having any of the things that would send a >> message instead send a new state. This eliminates

Re: [elm-discuss] Elm with one message

Ignoring the commands and subscriptions part, I think this could be summarized as being built around having any of the things that would send a message instead send a new state. This eliminates the level of indirection of wrapping the desire to change the state into a message and then

Re: [elm-discuss] Re: Would Enums make a good addition to Elm?

Definitely the big reason from my perspective to make more things comparable is to allow their use with dictionaries and sets. For that usage, the comparison could even be compiler dependent (or even execution dependent) but I'm sure that someone would build code that depended on properties of

Re: [elm-discuss] Elm `reusable views`

Wow. If only this stuff were well supported... On Thu, Aug 3, 2017 at 9:40 AM, Peter Damoc <pda...@gmail.com> wrote: > Indeed, adding a ResizeObserver polyfill allows for the expected behavior: > https://ellie-app.com/3VFHVxMsW2ya1/1 > > > On Thu, Aug 3, 2017 at 7:18 PM, M

Re: [elm-discuss] Elm `reusable views`

We watch for resizing using some resize observation JavaScript code — search on ResizeObserver and you can find a number of hits — and feed the values back through a port tagged with the size of the observed entity. Attaching the observer in a virtual DOM is an interesting problem because elements

Re: [elm-discuss] Would Enums make a good addition to Elm?

I thought about whether this was an opportunity to improve error messages but wasn't sure what the improvement would be. Is it detection that a previous case already matched everything? Is it specifically noting that the case involved a variable that shadows an existing variable? Or is this

Re: [elm-discuss] Would Enums make a good addition to Elm?

Something like this would probably address a "puzzle" I just resolved yesterday for one of the engineers on my team. He was testing character codes and did what one would be inclined to do in most programming languages and defined names for referencing the values — e.g., leftArrowKey : Int. He

Re: [elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

Agreed that encapsulation is the way to isolate the engineering trade offs because that's what this really is about. Ideally, one would never store values more than once and derived data would always get re-derived. But that ideal world ignores the cost of computations. Sometimes the cost of

Re: [elm-discuss] Re: Separating model state structure from the view hierarchy

f interest between the cloud and the client. Coming up with a clean way to organize the code is resulting in lots of exploratory sketches.) Mark On Fri, Jul 21, 2017 at 9:43 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > One argument against the "pass the model to all view functio

Re: [elm-discuss] Passing whole state to each view function

Per the other thread discussing this this morning, I don't know that passing the whole data model to all of the view-side functions is that horrendous. (We pass around a UXConfig structure in all of our views to provide access to translation functions amongst other things and the biggest pain is

Re: [elm-discuss] Re: Why is the signature of 'program.subs' 'model -> Sub msg' ?

My understanding is that yes, Elm does this with every update and then the effects managers have to look at the new subscriptions and compare them to the old subscriptions. I would love to hear that my understanding is wrong because while this isn't bad if you have just a few subscriptions, it

Re: [elm-discuss] Re: Separating model state structure from the view hierarchy

One argument against the "pass the model to all view functions" approach is that it pretty much blows up laziness. If one ignores that, then one could do something like the following: * All view-side functions including both update and view receive a global context containing the data model.

Re: [elm-discuss] Re: State of CSS in Elm

The latest version of the library does look very nice. I'm just starting to use it for prototyping some new cases. A skim suggests that the only way to use laziness is to drop in and out of HTML. Is that a correct read or did I miss something? Mark On Wed, Jul 5, 2017 at 10:38 AM, Matthew

Re: [elm-discuss] Passing whole state to each view function

Thanks for the term "referentially equivalent". It's a nice counterpart to "referentially transparent". (Long-time LISPers would know these as "EQ" v "EQUAL".) Mark On Sat, Jun 24, 2017 at 8:52 PM, Max Goldstein wrote: > Great points, Mark! > > I came across this

Re: [elm-discuss] Passing whole state to each view function

Actually, Html.Lazy also saves the differ the task of comparing the subtrees when laziness saves us from work, so it can be a big win if UI updates are a significant chunk of the work. That said, Max is correct that memory allocation for new structures is also a cost and is something to be

Re: [elm-discuss] Passing whole state to each view function

Also note that while the approach of transforming your model into a more view-specific data structure — e.g., extracting the pieces of interest — can be a great pattern in terms of code clarity, it works against using Html.Lazy. For background on the pattern, see Charlie Koster's piece on

Re: [elm-discuss] Re: elmq - is it a worthwhile abstraction or not?

The. Config parameter to generate messages is much like the out message approach in that essentially the child is listing off things that it either can't handle itself or that it doesn't actually care about but wants to let the parent know about. For example, a sign in module when finished may

Re: [elm-discuss] Re: Implementing a protocol on top of WebSocket: should I build a effect module ?

The Phoenix code is interesting but it is not an example of one effects manager using another. It bypasses the web socket effects manager and talks to the low level API. Mark > On May 16, 2017, at 4:38 PM, Oliver Searle-Barnes wrote: > > You might find

Re: [elm-discuss] Implementing a protocol on top of WebSocket: should I build a effect module ?

I've been looking at similar issues for protocol handling. As I understand it — and I would welcome someone pointing to evidence otherwise — effects modules can't use other effects modules. That means that if you want to use web sockets, you either don't use some of the services that effects

Re: [elm-discuss] Platform.Cmd.batch executes commands in reverse order

What you can do is emit the commands in two batches. The first sends the time critical operation(s) and sends a trigger message back to send the second batch of commands. Note that you can use Cmd.batch to send multiple commands on the delayed path: type Msg = Later (Cmd Msg) update : Msg ->

Re: [elm-discuss] Re: Moving on

On Apr 30, 2017, at 8:43 AM, Max Goldstein wrote: > > Fourth, web components were briefly mentioned. Richard gave a talk on these > last year and it seems like everything you need already works. Specifically, on this, no. The virtual DOM API does not make the sort of

Re: [elm-discuss] elm-css with type classes (a response to the Elm Town podcast)

Maybe this is covered in OCaml's polymorpic variants — I couldn't tell from a quick skim — but another feature that would cover this without introducing type classes is support for more arbitrary union/sum types. That way, one could write something like: type Auto = Auto type alias LengthOrAuto

Re: [elm-discuss] Re: Moving on

Just look at what npm did for the >> JavaScript community. Look at the success of React and Redux, which are >> more or less based on TEA. But they have excellent JS interop and an open >> ecosystem. Wouldn't it be great if Elm were just as widespread? And had >> just as many contributo

Re: [elm-discuss] Re: Moving on

Exactly and look at the months old comment at the top of the read me: NOT RELEASED YET — I hope to release it relatively soon, but I cannot make any promises. Until then, please use ports if you want to use localStorage. On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy

Re: [elm-discuss] Re: Moving on

advanced cases or people > who don't want/can't to follow TEA. > > Similar approach could apply to things like localStorage. Why not have a > low-level libs more or less mirroring web APIs, but later community could > build something higher level, like > https://github.com/elm-lang/persi

Re: [elm-discuss] Re: Moving on

> > This will evolve, but see above, the constraint is that Elm remains > reliable... Which the lack of attention to bug fixes undermines. How long were there warnings that arrays had problems? How long has Elm sometimes generated bad code for cyclic definitions leading to runtime crashes? The

Re: [elm-discuss] Re: Moving on

I was late to the Lua community — Lua 4.0 verging on 5.0 — but in some ways at a similar point or earlier to where Elm is trying to be given that at the time Lua conferences and talks at other conferences were not a common thing. Lua the language is controlled by three people with the

Re: [elm-discuss] Re: Comments on the TEA Components package

I think we have two general trains of thought regarding development here. One is YAGNI. Let things grow organically. Refactor when it gets messy. The other is Build for Success. Over engineer because you will probably end up shipping the prototype and once you do it will be too late to go back

Re: [elm-discuss] Re: Comments on the TEA Components package

The monster model design is one aspect that leads to the ball of mud code. Let's look at the source quote for the term big ball of mud: A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

Since the call is for concrete use cases, here is one: Reading from local storage. My program wants to cache various things in local storage or for the purposes of this example it wants to read from various locations in local storage to get the values needed at various points in the model/UX. If

Re: [elm-discuss] Re: Comments on the TEA Components package

Here is where our app is migrating after starting as an intermixture of view-side code and data-side code. The high level split is a store and a display. The store knows about things like how to talk to our server. As I summarized it, the UX code should know nothing about Phoenix. The display

Re: [elm-discuss] Re: Comments on the TEA Components package

It's certainly reasonable to say that there is a point where pursuing fractal TEA is overkill and not buying one much but extra plumbing work. But it is also exactly the case of things like the sign up form where being able to say "Here is a sign up form. It has a model, messages, update, and

[elm-discuss] Comments on the TEA Components package

Marek Fajkus's original announcement was on elm-dev but that list tends to become disapproving of discussions fast, so I'm moving over to here to discuss it. The post suggested that it was in the Elm package library but it seems to have been pulled, so I will point to the Github repository:

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

Given the existence of Process.sleep, the argument that tasks have to return at some point and we couldn't guarantee that from JavaScript seems incredibly weak. Given that effects manager development seems to have ground to a halt — Local storage? Phoenix? — it seems pretty vital for a language

Re: [elm-discuss] Cmd.map

y > mistake? I don't really think that would the case. And if you have to, you > could just do it, without developing circles around all those "safety" > guards, I guess... > > 30.03.2017 1:36 AM "Mark Hamburg" <mhamburg...@gmail.com> napisał(a): > > W

Re: [elm-discuss] Cmd.map

>> a user when I go to the user info page. I want this to be reflected on the >> code, so I never have to check if there is a user. >> >> So far these issues are pointing me towards some sort of page separation, >> but I haven't been able to come up with something I

Re: [elm-discuss] Cmd.map

The config approach pops up various places — e.g., elm-sortable-table — but isn't as well specified anywhere that I've seen because it doesn't have as clear a pattern to specify. Cmd.map (and Html,map) come out of what could be called Classic TEA. The classic Elm architecture was built to allow

[elm-discuss] Bug report (Undefined is not a function!)

I've now seen something like this a few times. The last time I tried to build an SSCCE, the bug went away when I looked more closely so I expect to get nasty messages from the bug submission system if I try to report it as is, but I figured I would see whether anyone else has seen anything like

Re: [elm-discuss] Re: To wrap or not to wrap

26, 2017 at 10:57:46 PM UTC+1, Mark Hamburg wrote: >> >> I think I have some code that follows this pattern: >> >> module Mod exposing (Model, Msg, update) >> >> type Model = Model Imp >> >> type alias Imp = { ... private stuff goes here ... } >&g

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

Specifically to support MessagePack it seems like Elm needs: 1. Support for binary data — even if just as a blob that it can pass around but not inspect. There are references to blobs in places like the Http module but this appears to have been consigned to the backburner. 2. Support for binary

Re: [elm-discuss] Re: To wrap or not to wrap

arch 23, 2017 at 4:21:10 PM UTC, Mark Hamburg wrote: >> >> Should one wrap a model implemented as a record in a type to keep the >> details private? > > > If you wrap your Model to keep it private, you will only need to > wrap/unwrap the functions that the module e

[elm-discuss] To wrap or not to wrap

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

Re: [elm-discuss] Re: Elm FP vs Elm FRP

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

Re: [elm-discuss] Re: How do you handle dependencies between updaters?

. But using out messages to retrieve values does avoid having huge and seemingly haphazard parameter lists. Mark On Tue, Mar 21, 2017 at 3:20 PM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > On Tuesday, March 21, 2017 at 6:27:01 PM UTC, Mark Hamburg wrote: >> &

Re: [elm-discuss] Re: How do you handle dependencies between updaters?

Mar 21, 2017 at 11:26 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > Oliver asked whether our out messages approach had an equivalent of > Cmd.map. I'll paraphrase some code to show how it works. It's definitely > more code than the simple Cmd approach but it provides more func

Re: [elm-discuss] Re: How do you handle dependencies between updaters?

Oliver asked whether our out messages approach had an equivalent of Cmd.map. I'll paraphrase some code to show how it works. It's definitely more code than the simple Cmd approach but it provides more functionality as well. I'm simplifying away a lot of details like the fact that the login

Re: [elm-discuss] Re: How do you handle dependencies between updaters?

The main reason to separate is when the smaller pieces have their own conceptual integrity. That becomes something one can manage independently and maintain more local invariants about thereby making that piece of the code easier to reason about. But a dependency has to be managed somewhere and

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

Agreed. Tasks actually were the core way to do things in 0.16 — though ports then were more focused on reactive programming models as I recall. Effects (what essentially became commands) were largely a shim on top of tasks. But then along came Elm 0.17 and it's emphasis on effects managers

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

that this seems to be a routine stumbling block. Mark > On Mar 9, 2017, at 3:09 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > I got asked for non obfuscated/simplified examples, so let me run through > some more realistic code. I would pull from our own codebase but we've

Re: [elm-discuss] Re: Is it possible to create a circular reference in Elm?

I've been thinking about this as well because functional languages should provide a great basis for exploiting multi core systems. You can run the evaluation of a "top level" function like `update` in a bump arena allocator — and can even re-run the function safely if the arena turns out to be

Re: [elm-discuss] input value solution

Is this a correct summary: Updating Html.Attributes.value is bad if the user types rapidly because it can fall behind user input and setting the value competes with typing but we want to set it when the value in the model changes for other reasons? A couple of "solutions" come to mind: One is

Re: [elm-discuss] Re: elm + reactive programming

Let's consider throttling. We'll assume that we want to throttle messages of a particular type to not arrive more often than a particular interval. The exact rules are exactly the sort of thing we want to hide inside the throttle module. We've got some state to manage. The last time we let a

Re: [elm-discuss] Re: elm + reactive programming

The real test here for Elm isn't just "can you write a program that throttles input". Of course you can. It's can you write a library that would allow people who needed to throttle input or detect double-clicks or detect other more complicated gestures without needing to know the specifics of

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

latter problem seems like the sort of thing that should be very straightforward to solve and would also allow for writing the first version of updating the left padding that I wrote above. Mark On Fri, Mar 3, 2017 at 8:44 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > Our codebase suffers

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

Our codebase suffers from this as well. And unlike what one of the follow ups noted, this isn't an issue of wanting to add fields. Rather, it's an issue of not being able to use an expression in the first part of the record update. In this case, one doesn't even need a general expression but

Re: [elm-discuss] Re: Possible performance bug when using SVG xlink:href?

How are you passing your model to the rendering function in Html.Lazy without it triggering on other changes to the model? Does Html.Lazy not look for changes in the function itself and you just use a closure to pass the actual model value? That would seem like a bug in Html.Lazy if it did so

Re: [elm-discuss] Re: Html.Attributes.none

Agreed. I wanted this just the other day as well. For similar reasons, it would also be nice to have an “official” Html.none rather than just using Html.text “”. Mark On Jan 24, 2017, 3:51 PM -0800, OvermindDL1 , wrote: > Yes, for precisely the same usage.  It is much

[elm-discuss] Intended usage of -- comments (and elm-format)

What is the intended usage of -- comments in Elm? I'm used to using them as line end comments in other languages and/or lightweight comment lines all to themselves but elm-format tends to respond to them by more radically adjusting the code layout which suggests either that their intended usage

Re: [elm-discuss] Re: Emphasizing /r/elm more

o help with this >> but don't do a particularly good job; it's a hard problem to solve from the >> outside) >> >> 3. you get a notification if someone replies to you, but not if someone >> replies to that reply. >> >> 4. searching through old conver

Re: [elm-discuss] Re: Emphasizing /r/elm more

ad the way. That way, the argument could be made "we're using it for Elm development discussions and it's working great". Mark > On Jan 4, 2017, at 10:13 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > I agree that this only works if elm-discuss gets killed. It mig

Re: [elm-discuss] Re: UI effects (align/tether, scroll into view) after elements are inserted

but then leaves me still uncertain about when it executes relative to the actual view rendering. Mark > On Jan 4, 2017, at 10:15 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > I don't have a port. I'm just using the standard Dom package. But it would > presumably h

Re: [elm-discuss] Re: UI effects (align/tether, scroll into view) after elements are inserted

message on your port as a command in your `init` > function. In the port JS handler you run `requestAnimationFrame` and find and > focus your element there. Does that work? > >> On Wednesday, January 4, 2017 at 8:24:40 AM UTC-8, Mark Hamburg wrote: >> We just had a similar conce

Re: [elm-discuss] Re: Emphasizing /r/elm more

I agree that this only works if elm-discuss gets killed. It might, however, be necessary to also kill elm-dev because the leakage of elm-discuss traffic over into elm-dev will likely become much worse if elm-discuss goes away. Mark > On Jan 4, 2017, at 9:34 AM, Rex van der Spuy

Re: [elm-discuss] Re: Emphasizing /r/elm more

I'm well aware that the Elm subreddit can and will be moderated. The view point I was hearing and relaying was basically a political statement about choosing not to support Reddit. Mark > On Jan 4, 2017, at 8:38 AM, Charlie Koster wrote: > > Mark, Reddit is what you make

Re: [elm-discuss] Re: Emphasizing /r/elm more

I, in my ungrammatical bubble, should perhaps use some Elm-based software to keep me from becoming too casual in my writing. :-P > On Jan 4, 2017, at 8:32 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > Me, in my white male tech bubble, focused on user interface annoyances

Re: [elm-discuss] Re: Emphasizing /r/elm more

speech — and they were uncomfortable giving Reddit any business. Mark > On Jan 2, 2017, at 8:23 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > The web interface to Reddit is abysmal. Email isn't great but Reddit seems > incredibly tedious. > >> On Mon, Jan

Re: [elm-discuss] Re: UI effects (align/tether, scroll into view) after elements are inserted

We just had a similar concern come up but with the existing Dom package. If the init for a model wants to generate a focus command — the autofocus property is proving unreliable for reasons as yet undetermined — how can we arrange to have that command execute after the view has actually been

Re: [elm-discuss] Re: Emphasizing /r/elm more

The web interface to Reddit is abysmal. Email isn't great but Reddit seems incredibly tedious. On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster wrote: > I just wanted to confirm one of your assertions anecdotally. In the past > week I wrote two Elm blog posts and opted to

Re: [elm-discuss] Weird bug where messages passed to the wrong 'component'

there's a fix. If you want to be lazy, stick a div in or avoid the map by pushing the tagger function further down. Mark > On Dec 14, 2016, at 10:23 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > > I'm looking at a bug tonight that looks very much like a tagger got dropped

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

is actually pretty straightforward. So, having some official, documented way to create JavaScript-based tasks would still be a huge win in opening up an escape hatch for performance issues and access to other functionality. Mark > On Dec 28, 2016, at 12:06 AM, Mark Hamburg <mhamburg...@gm

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

d over to JavaScript. Mark > On Dec 27, 2016, at 11:41 PM, GordonBGood <gordonbg...@gmail.com> wrote: > > > >> On Wednesday, 28 December 2016 14:18:13 UTC+7, Mark Hamburg wrote: >> My point was that the calls for Elm optimization could largely be mitigated >>

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

My point was that the calls for Elm optimization could largely be mitigated through a combination of fast enough for most purposes (arguably already there) coupled with a reasonable escape hatch to the host environment (as of now JavaScript and not really there) for the cases when it isn't. I'm

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

This could, however, feed into the questions over Elm's interface to JavaScript. The easier it is to escape to JavaScript, the easier it is to say that Elm is fast enough for the vast majority of code that matters and if that doesn't cover a tight loop in your code, you can write just that part

[elm-discuss] Faster subscription logic: A thought

When I look at applications I've built in the past and the parts of them that would naturally be represented using subscriptions — e.g., subscriptions for image status (or even image data) on a grid of images — I worry about how well they scale. In particular: * As I understand it, subscriptions

[elm-discuss] Awaiting effects managers: Persistent cache and Phoenix

What is the status on the persistent cache effects manager? https://github.com/elm-lang/persistent-cache What is the status on the Phoenix effects manager? https://github.com/saschatimme/elm-phoenix Thanks. Mark -- You received this message because you are subscribed to the Google Groups

Re: [elm-discuss] Stance on native APIs for 0.18?

My view of the ideal world here with respect to JavaScript is that JavaScript (or any other foreign language host) is basically a separate universe that gets orchestrated by and communicates with Elm. Since Elm is implemented as compiling to JavaScript and it runs within the JavaScript universe,

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

Having external compute run asynchronously opens the possibility of having it run in parallel some day. That said, if Elm were to emphasize that sort of programming, it might drive some shifts in how other pieces are structured. The world is going async — see node.js — but it's a painful process.

Re: [elm-discuss] Weird bug where messages passed to the wrong 'component'

;> On Wednesday, 14 December 2016 03:55:29 UTC+1, Mark Hamburg wrote: >> I just dug into what I think is essentially the same bug. My guess was that >> textfields were getting removed from the DOM and then firing their blur >> events up through the event mapping chain —

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

place to deploy Tasks. Mark On Tue, Dec 13, 2016 at 8:06 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > Then people would complain that all native calls returned Results rather > than the type they wanted returned. > > Mark > > On Tue, Dec 13, 2016 at 7:42 AM, J

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

Then people would complain that all native calls returned Results rather than the type they wanted returned. Mark On Tue, Dec 13, 2016 at 7:42 AM, Joey Eremondi wrote: > the elm package repo would very quickly get poluted with js code that >> causes runtime exceptions

Re: [elm-discuss] Weird bug where messages passed to the wrong 'component'

I just dug into what I think is essentially the same bug. My guess was that textfields were getting removed from the DOM and then firing their blur events up through the event mapping chain — which had been updated to match the new view tree structure. It's on my list to try to build a small

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

syntactic sugar around monads than Elm does. Mark On Mon, Dec 12, 2016 at 8:19 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > One doesn't need them to be asynchronous but making them asynchronous > helps reinforce the notion that this is happening outside the Elm universe. > And if

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

com> wrote: > On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote: >> >> While there are certainly times when synchronous calls would have been >> nice, I recognize that having synchronous behavior for potentially mutable >> external state also tends to

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

, but it's simpler code and simpler to explain. Mark On Mon, Dec 12, 2016 at 6:03 AM, Mark Hamburg <mhamburg...@gmail.com> wrote: > Ah. Sorry. My misunderstanding. I went looking for the Effects.tick > replacement in 0.17+ and only found AnimationFrame. > > Mark > > On S

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

managers and > benefits from, maybe even is absolutely dependent on, having separate > concepts of Task and Cmd. To decide about maintaining that latter stance, > will require digesting your material more fully.) > > > ​ > > 2016-12-11 21:26 GMT+01:00 Mark Hamburg <mhamburg

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

before rendering an animation frame. Mark On Sun, Dec 11, 2016 at 12:26 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > Since I wasn't proposing to get rid of subscriptions and since this > functionality is covered through subscriptions, my proposal arguably > doesn't

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

Since I wasn't proposing to get rid of subscriptions and since this functionality is covered through subscriptions, my proposal arguably doesn't cause a problem. But that's just getting through the loophole of this specific example to dodge this particular case, so let me see if I can get straight

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

y as well? Or > would they become an abstraction for some sort of task port interaction? > > On Sat, Dec 10, 2016 at 2:34 PM, Mark Hamburg <mhamburg...@gmail.com> > wrote: > >> In the case of ticks, what I gather from a read through of the code that >> it does is guar

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

In the case of ticks, what I gather from a read through of the code that it does is guarantee that all of the tick requests placed between animation frame strobes will all be delivered at the next animation frame strobe. Is that a correct read? If so, in a task based world, what it would call for

Re: [elm-discuss] Re: [elm-dev] Re: 0.17 Tasks vs Cmds

Those are Elm 0.16 effects are something totally different. There is no reason why tick tasks couldn't be batched in their execution. There are certainly things that Elm 0.17 and 0.18 are doing in effects managers that aren't feasible with tasks right now because tasks are in a sense too

  1   2   3   >