This looks very promising (pun very much intended). I like the Geolocation API and think it should be part of the standard library.
I think that Promises will finally get us to cover most of the Web APIs (like getUserMedia) and provide simple libraries for that. I think that your geolocation example proves that. I'm looking forward to playing around with it. Just take your time with the implementation, I think you're on the right track.
Anyone else share this feeling about geolocation? I wasn't really sure, and breaking it out felt more cautious. I figured there'd be a bunch of things like this, and they can sometimes feel low-level. One day, I can imagine people wrapping them up in some way or another that's nicer, and it'd be a shame to take the name Geolocation from everyone ever. Not really sure though!
I have been thinking about future portability of Elm to other platforms which may or may not have geolocation capabilities.
I would prefer the standard library just have things that are guaranteed to be there on all platforms.
Anyone else share this feeling about geolocation? I wasn't really sure, and breaking it out felt more cautious. I figured there'd be a bunch of things like this, and they can sometimes feel low-level. One day, I can imagine people wrapping them up in some way or another that's nicer, and it'd be a shame to take the name Geolocation from everyone ever. Not really sure though!I like having separate libraries personally; it's not fun waiting for lots of things you don't use to compile... Everything does look very cool, I'm eager to see more of how the signals tie in!
--
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.
I agree. I'd prefer some specific like that be a library. Having really solid, useful things will help promote the libraries, so people know it's not just for experimental stuff.
seqmap2 func promiseA promiseB = | |
promiseA | |
`andThen` \a -> promiseB | |
`andThen` \b -> succeed (func a b) |
map2 = | |
Native.Promise.map2 |
apply = | |
map2 (<|) |
map3 func promiseA promiseB promiseC = | |
map func promiseA | |
`apply` promiseB | |
`apply` promiseC |
sequence promises = | |
case promises of | |
[] -> | |
succeed [] | |
promise :: remainingPromises -> | |
seqmap2 (::) promise (sequence remainingPromises) |
interleave = |
case promises of | |
[] -> | |
succeed [] | |
promise :: remainingPromises -> | |
map2 (::) promise (interleave remainingPromises) |
--
I think this is a misunderstanding:
For an Applicative Functor (sorry for the jargon) lifts have no execution order of the arguments.
There is a difference between Applicative
and Monad
, but the difference is not that one has an “execution order” whereas the other does not. Parsers are often Applicatives
, and liftA2
then is sequential composition of parsers (“first parse this, then parse the remaining unconsumed input as that“).
If what you were trying to say is that for a (law-abiding) Applicative
and, say, its liftA2
function, the equivalence
liftA2 f x y
==
liftA2 (flip f) y x
holds, then that is wrong.
That's exactly what I meant. I think I'm confused by the analogue monad vs applicative = sequential vs parallel. I apologise for the misinformation. I wonder if there is any real difference between liftA and liftM then.
No problem, good to clear that up in case it has an impact on the naming discussion.
Aside: that equivalence does hold for liftM2
if the monad is what they call a commutative monad. The difference between Applicative
and Monad
is less about parallel vs. sequential, more about the presence or absence of context-dependency (using information from inside one computation to influence the choice of another computation). For the parser case, it so happens that if one only uses the Applicative
part, one characterizes exactly all context-free grammars.
--
getCurrentPosition : (Position -> Promise x a) -> (Error -> Promise y b) -> Options -> Promise z () |
watchPosition : (Position -> Promise x a) -> (Error -> Promise y b) -> Options -> Promise z Int |
clearWatch : Int -> Promise x () |
getCurrentPosition : Options -> Promise Error Position |
watchPosition : Options -> Promise Error (Position, Int) |
Sebastian, have you seen this message and the following ones?
Assuming that a promise “that doesn’t need the full monad package”, by being an Applicative
, would automatically allow parallelism is wrong. There are Applicative
s for which the equivalence
liftA2 f x y
==
liftA2 (flip f) y x
does not hold.
So, concerning your question whether this would hurt some of the Applicative
rules: The real question should be whether or not it follows from the Applicative
rules (because only if it would always hold, you could do the desired “parallelism optimization” for all Applicatives
). And the answer is No.
Alternatively, maybe you actually want to ask a different question, where Applicative
is replaced by something like “a commutative Promise
“. Problem is: Whereas Monad
and Applicative
can easily be distinguished by just their interfaces (“Is there a >>=
function or not?”), it’s not possible to tell just from the types / available operations whether or not a Promise
or Monad
or Applicative
is commutative in the required sense.
--
Hi Janis,
yes, I read them and smelled the strong relation to my issue.
To wrap up what I think you are saying: The parallelization optimization should not be part of the Applicative
API because it assumes more about the structure of Promise
than it should? Isn’t this the same as saying every applicative functor should be a kind-of free applicative functor (e.g. exploit nothing more about the structure than given by the laws)? Note that I’m not entirely firm with the concepts I just threw out, so please correct me.
One way or the other, there should be some functions in the API which make use of this optimization, even if they aren’t part of the inofficial Applicative
API (e.g. mapN
). Maybe we could call them fetchN
or just one function fetch{Parallell|Many} : [Promise a] -> Promise [a]
, which would be akin to sequenceA
.
This is just my initial reaction, but it doesn't feel like "fun Elm FRP" anymore and that's kinda worrying to me.