The function uses the exposed Lazy.List.LazyListView type, which I would rather avoid if it makes sense to:
I always interpreted the warning in the documentation as "Don't use the name LazyListView or the Nil and Cons constructors, instead using head, tail and headAndTail for most pattern matchng". I think it makes sense not to use the internal representation given that Dict and Array change when better implementations arise. Does any code elm code actually pattern match these instead of using the functions? Always thought it was weird to have this type exposed at all.
generate : Generator a -> Seed -> LazyList a
generate generator seed =
let
( value, newSeed ) =
Random.step generator seed
in
cons value (generate generator newSeed)
--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/BM_ZmUk-vck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
'iterate' is the right way to do what you're looking for. No idea why they chose to expose that.generate : Generator a -> Seed -> LazyList agenerate generator seed =let start = Random.step generator seed inLL.iterate(\(v,s) -> Random.step generator s)start|> LL.map Tuple.first
The LazyList library as it exists is seriously flawed as it crashes for many cases for infinite length lazy lists, which is probably why there is that caution. Please see my extensive PR which fixes almost every function so they can handle infinite length lazy lists within the guidelines.
--
The rational to depreciating these seems to be performance when applied to their limited use in tests and I see that, as I tried to make changes to Lazy that would improve its lack of performance when run on some JavaScript engines that handle internal functions calling functions very poorly.
--
--
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+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
P.S. Cyclic structures can be avoided by having the compiler perform a strongly connected component analysis (e.g., using Tarjan's algorithm) and disallowing any SCC's that include anything other than function definitions. In fact, not doing so likely leaves open other cyclic cases and hence getting rid of Lazy likely does not eliminate cycles and instead just narrows the cases for which Elm is suitable.
--
That page already has an example built using the decoder APIs so unless something is changing to disallow the creation of such cyclic decoders, cycles remain.
--
Recursive decoders have the same issues.
type Content =
Content
{
slug : Maybe String
, path : Maybe String
, contentType : Maybe (ContentType)
, model : ContentModel
, relationships : Maybe (List Relationship)
, container : Maybe (List Content)
, id : Maybe String
}
type Relationship =
Relationship
{
subject : Maybe (Content)
, predicate : Maybe PredicateType
, object : Maybe (Content)
, id : Maybe String
}
I need to use Decode.lazy to do this. Is that memoized? Is that how decoders can create recursive values? Other than that, I don't see how they could.
var rec = { field : rec };
myapp.ports.myport.send(rec);
type Rec =
Rec
{
field : Rec
}
port myport : (Rec -> msg) -> Sub 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+unsubscribe@googlegroups.com.
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.
--
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.
Functions are also heap allocated objects and reference other objects — e.g., decoders — just like other objects do.
Meanwhile the memoized Lazy type library really is needed, else there is no way to implement memoization without custom JavaScript, which is frowned upon.
--
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 those functions (can) capture values, they are new values just as much as a list or record or other data value would be.
--
One can return a partial function application and it looks just like any other function, so in the general case, it can't be garbage collected. This isn't special to JavaScript. In fact, JavaScript doesn't support partial function application. What JavaScript, Elm, and pretty much any other language that purports to be functional does support is capturing values through closure creation and because those closures can be returned as values, they need to be subject to garbage collection.