[elm-discuss] Re: Looping While/Until
What exactly do you need the while-loop for?
On Thursday, July 6, 2017 at 7:04:18 AM UTC+2, John Bugner wrote:
>
> In imperative OO languages, there are for/while loops:
>
> A for-loop often looks like this:
>
> for (i = 0; i < 100; i++) {
> a[i] = f(i);
> }
>
> In Elm (and Haskell), we have the neat `map` function that captures this
> pattern:
>
> map f a
>
> A while-loop looks like this:
>
> while (!isDone(s)) {
> f(s);
> }
>
> Haskell has the `until` function that captures this pattern:
>
> until isDone f s
>
> Elm lacks this function. Is there a reason why? What's the current elmic
> way of doing this? Explicit recursion, I assume?
>
> Anyways, it seems that somebody else already yearned for `until` like me,
> and made this module:
> http://package.elm-lang.org/packages/Chadtech/elm-loop/1.0.2/Loop ...
>
> I note though, that he changed the order of the arguments from Haskell's
> `(a -> Bool) -> (a -> a) -> a -> a` to `(a -> Bool) -> a -> (a -> a) -> a`.
> I'm not sure why. If he wanted to match the usual impOO order, then why not
> `a -> (a -> Bool) -> (a -> a) -> a` instead ? Anyways, I think Haskell's
> order is the right order, because it let's you make useful closures, like
> this:
>
> collatz : Int -> Int
> collatz =
> let
> u : Int -> Int
> u n =
> if isEven n
> then n // 2
> else 3 * n + 1
> in
> until ((==) 1) u
>
> This function is elegantly defined, but not very useful, because the
> result of every (positive) number will simply return 1 (mathematicians
> strongly suspect so, anyways). What's interesting is the *sequence* that a
> number makes on it's way down to 1. So I made a function that repeats like
> `until`, but also records each intermediate result in a list, like `scanl`:
>
> scanUntil : (a -> Bool) -> (a -> a) -> a -> List a
> scanUntil p u s =
> let
> p_ : List a -> Bool
> p_ xs = case xs of
> [] -> True
> x :: _ -> p x
> u_ : List a -> List a
> u_ xs = case xs of
> [] -> []
> x :: _ -> u x :: xs
> in
> until p_ u_ [s]
>
> I'm not sure that `scanUntil` is the best name. Can anybody think of a
> better name? I also note that list that it returns is reversed compared to
> `scanl`'s and Haskell's `iterate` function (
> https://hackage.haskell.org/package/base-4.7.0.2/docs/Prelude.html#v:iterate
> ), but feels right because the most useful value is probably going to be
> the last one calculated. But maybe this doesn't matter, because if you
> really want the last one calculated, then you'd just use `until` instead
> anyways.
>
> Anyways... answers, thoughts, and comments are welcome.
>
>
--
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: Decoding json from incoming websocket packets
Thanks Alex, your response makes perfect sense. It definitely makes sense to treat data received on websocket as stream as opposite to discrete messages. Some challenge here is absence of indication when connection got closed and reopen (to reset the buffer). Maybe need to consider using elm-lang/websocket. Also it is a bit surprising that such common task does not have ready-to-go solution. Alex, thanks again for your response. -- 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: Unexpected compiler behaviour and message "pattern is redundant".
Thanks. I wasn't aware of that - makes sense. -- 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: Decoding json from incoming websocket packets
If you control the sender and are guaranteed to get some messages exceeding
the websocket limit (which I'm assuming is 4500 bytes) is to either send
multiple smaller updates, or assign some sort of message id and prepend it
to each chunk.
Another option you can do (if you can't control the sender) is have a
string buffer, and each time you get data, if it can't be decoded, append
it to the buffer. After every append, attempt a decode, and if it's
successful, clear the buffer. This will probably break if you get multiple
unrelated messages.
One thing you should keep in mind is websockets on their own aren't really
for messages, it's for streaming data. If you can guarantee synchronous
messages (ie first message must always complete before the second message
starts), you could send a byte length + json (ie "14{ foo: 'bar' }", and do
the buffer method I suggested.
So if you have big messages, your best bet is to chunk them yourself so
you're guaranteeing the size. Otherwise, hope they are synchronous and
assemble them in elm.
On Monday, 10 July 2017 09:12:31 UTC-4, _Boris _ wrote:
>
> Hello,
>
> I have implemented very straightforward converting received packet into
> Msg:
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
> Sub.batch
> [ WebSocket.listen wsServer decoderServerMsg
>
> where decoderServerMsg:
> decoderServerMsg : String -> Msg
> decoderServerMsg rcvdStr = case JD.decodeString jsonDecServerMsg rcvdStr
> of
> Ok serverMsg -> ServerMsgReceived serverMsg
> Err err-> SystemError ("Failed to parser server msg:"++err++"
> string:"++rcvdStr)
>
>
> It works well as long as there is no fragmentation, ie. every packet
> contains valid json payload.
> My problem starts when packet exceeds about 4500 bytes and then it is
> broken into two chunks.
> I believe it very common case so before reinventing the wheel I wanted to
> ask if there is already solution for this problem that I can use?
>
>
> Thanks,
> Boris
>
>
--
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] Decoding json from incoming websocket packets
Hello,
I have implemented very straightforward converting received packet into Msg:
subscriptions : Model -> Sub Msg
subscriptions model =
Sub.batch
[ WebSocket.listen wsServer decoderServerMsg
where decoderServerMsg:
decoderServerMsg : String -> Msg
decoderServerMsg rcvdStr = case JD.decodeString jsonDecServerMsg rcvdStr of
Ok serverMsg -> ServerMsgReceived serverMsg
Err err-> SystemError ("Failed to parser server msg:"++err++"
string:"++rcvdStr)
It works well as long as there is no fragmentation, ie. every packet
contains valid json payload.
My problem starts when packet exceeds about 4500 bytes and then it is
broken into two chunks.
I believe it very common case so before reinventing the wheel I wanted to
ask if there is already solution for this problem that I can use?
Thanks,
Boris
--
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.
