Re: [elm-discuss] Re: elm-tools/parser: how to access intermediate parsed objects downstream in parsing pipeline?

[Yosuke Torii]

>
> how do I know what row/col the mistake came from in the input String?


Have you looked at Parser.LowLevel

module?
I haven't tried it yet but it should help tracking the error position.


2017-08-03 2:59 GMT+09:00 Dave Doty :

> Thanks! I assumed andThen would be involved somehow but didn't quite see
> how to use it.
>
> That said, I don't think validation is necessary during the parsing
>> process. You can check it after everything is parsed. That is much simpler.
>
>
> If I check everything after it is parsed, how do I know what row/col the
> mistake came from in the input String? If the parsing succeeds, then the
> result is simply type OK DFA, but if I find a mistake then I want to be
> able to report which specific part of the input String caused that problem.
>
> --
> 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/gxy9D6bncIQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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-tools/parser: how to access intermediate parsed objects downstream in parsing pipeline?

[Yosuke Torii]

You cannot do like that in the middle of pipeline, but instead you can use `
andThen 
` 
to 
make a new parser based on the previous value you parsed.

For example, you can pass `states` value to parse `acceptStates` like this. 
(Simplified a lot, not tested)

dfaParser : Parser.Parser DFA
dfaParser =
  statesParser
|> andThen (\states ->
  succeed (DFA states)
|= alphabetParser
|= acceptStateParser states
|= ...
)

You can also make a recursive parser and pass the intermediate state to the 
later parser.

deltaListParser : Context -> Parser.Parser (List Delta)
deltaListParser context =
  oneOf
[ deltaParser
|> andThen (\delta ->
   if checkDuplication delta context then
 deltaListParser (updateContext delta context)
   |> map (\rest -> delta :: rest)
   else
 fail "found duplicated values"
, succeed []
]

deltaParser : Parser.Parser Delta

That said, I don't think validation is necessary during the parsing 
process. You can check it after everything is parsed. That is much simpler.


2017年8月2日水曜日 12時17分57秒 UTC+9 Dave Doty:
>
> The elm-tools/parser documentation recommends using parsing pipelines such 
> as 
>
> type alias Point = { x : Float, y : Float}
> point : Parser Pointpoint =
>   succeed Point
> |. symbol "("
> |. spaces
> |= float
> |. spaces
> |. symbol ","
> |. spaces
> |= float
> |. spaces
> |. symbol ")"
> spaces : Parser ()spaces =
>   ignore zeroOrMore (\c -> c == ' ')
>
>
> I am parsing text in this way, but it is much longer than just two floats. 
> The high-level parser parses text with five major parts in order 
> (describing portions of a finite automaton) and it looks like this (and 
> uses five "subroutine" parsers that I've not shown):
>
> type alias State = String
> type alias DFATransition = State -> Char -> Result String State
> type alias DFA =
> { states : List State
> , inputAlphabet : List Char
> , startState : State
> , acceptStates : List State
> , delta : DFATransition
> }
>
> dfaParser : Parser.Parser DFA
> dfaParser =
> Parser.succeed DFA
> |. spaces
> |. Parser.keyword "states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "input_alphabet:"
> |. spaces
> |= alphabetParser
> |. spaces
> |. Parser.keyword "start_state:"
> |. spaces
> |= startStateParser
> |. spaces
> |. Parser.keyword "accept_states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "delta:"
> |. spaces
> |= deltaParser
> |. spaces
>
> to parse text such as, for instance, 
>
> """
> states:  {q,q0,q00,q000}
> input_alphabet:  {0,1}
> start_state: q
> accept_states:   {q,q0,q00}
> delta:
> q,1-> q
> q0,1   -> q
> q00,1  -> q
> q000,1 -> q
> q,0-> q0
> q0,0   -> q00
> q00,0  -> q000
> q000,0 -> q000
> """
>
> Here's what I want to do: insert code in the middle of the pipeline that 
> can reference the data that has been parsed so far.
>
> For example, after this portion of the pipeline has succeeded: 
>
> dfaParser =
> Parser.succeed DFA
> |. spaces
> |. Parser.keyword "states:"
> |. spaces
> |= statesParser
> |. spaces
> |. Parser.keyword "input_alphabet:"
> |. spaces
> |= alphabetParser
> ...
>
> then the data for states and alphabet have been successfully parsed into 
> two Lists. I would like to access those lists by name, later down the 
> pipeline. 
>
> One reason is that I would like to pass those lists as input to subsequent 
> parsers (startStateParser, acceptStatesParser, and deltaParser), to help 
> them do error-checking. 
>
> For example, the next thing parsed is a String parsed by startStateParser, 
> and I want to ensure that the parsed String is an element of the List 
> parsed by statesParser. But at the time I put the line |= startStateParser 
> in the pipeline, the parsed result of statesParser doesn't have a name 
> that I can refer to.
>
> Another reason is that I want to do error-checking in the middle of a 
> pipeline. For example, my implementation of deltaParser reads the lines 
> such as "q,0 -> q0" and "q0,1 -> q" one at a time, and I would like to 
> access data parsed by previous lines when looking for errors on the current 
> line. (For example, it is an error to have duplicates on the left side of 
> -> such as the line "q,1 -> q" followed later by "q,1 -> q0", but to 
> indicate this error and reference the correct line number, I need access to 
> the lines parsed so far as I am processing the line with the error.)
>
> I get the feeling that perhaps I'm structuring this incorrectly, so I 
> welcome advice on a better way to structure the 

[elm-discuss] Re: Looping While/Until

[Yosuke Torii]

Hi John,

I don't know the reason why Elm does not have them but Elm's core library 
usually gives best minimum set of functions. For example, List module don't 
have `find`, `zip`, and `scanl` that are included in community package 
named list-extra 
.
 
But I don't think all of them should always be listed in core, simply 
because it is too many. So it should be important how often we use them or 
how these functions effectively work in practice.

I agree that basically it is better to not write a bare recursion. I also 
agree `until : (a -> Bool) -> (a -> a) -> a -> a` is better than `until 
: (a -> Bool) -> a -> (a -> a) -> a`. But in my daily development, 
generating a list or calculating until some condition is very rare logic. I 
wonder which is easier to choose/remember a function or to write/read a 
recursive function.


2017年7月24日月曜日 19時13分09秒 UTC+9 John Bugner:
>
> For example, making a function that flood fills an area from a given start 
> point. You know that it'll eventually end, but you don't know exactly how 
> many times you need to recurse, unlike 'map' or 'fold', where the number of 
> times is the same as the number of items in the list/collection.
>
> It's basically a wrapper for the recursion, letting your function focus on 
> the logic.
>
> On Monday, July 10, 2017 at 10:28:15 AM UTC-5, Erkal Selman wrote:
>>
>> 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.

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

[Yosuke Torii]

Marek

This reply is only to my part. Did not read other parts.


> Maybe you've noticed that I haven't commented your example with
> reusability. That was on purpose because telling when and on what you
> should use it is completely different topic. For sure it can be used for
> integrating community components. It can be used anytime you're using
> Cmd.map Html.map and Sub.map. That's actually beauty of abstraction that it
> can be applied regardless of your domain. Same way s you can List.map view
> over List of data to turn them into view you can use this to map date
> picker's api to app and anything else. My intention is not telling anyone
> when and on what to use it. It's just super thin helper for doing (a, Cmd
> b) -> (c, Cmd e) with the use of functions.


I'm strongly against this way of thinking.

Telling nothing about who to use, when to use or what to use for is
the *easiest
*way. But does it make anyone happy? As you say, we can use Cmd.map,
Sub.map and Html.map everywhere but we are happy with the fact `view`
function does not return `Cmd msg` so you can say there must be no side
effects in view.

"That's actually beauty of abstraction that it can be applied regardless of
> your domain."


Yes it *can *be, but *should not* be. We (...not every one but at least
many of us including me) found NOT everything is a component. The old TEA
document was doing just like you; "There is a pattern that is sometimes
useful". I thought "oh cool, everywhere in my app should be organized like
this" ...and I regretted it later. Things got needlessly complicated. For
example, some components required many options like { onSelect, onChange,
... } and the parent component just translated to that layer's msg. But
actually that component was used only once. I refactored that component to
have some knowledge about the application and the code got significantly
simpler than before. After that, I've get that better habit to think like
"okay, this is just a view, no need to have state for now".

It's just super thin helper for doing (a, Cmd b) -> (c, Cmd e) with the use
> of functions.


Maybe you need this function? This is thinner.

andThen : (model -> (model, Cmd msg)) -> (model, Cmd msg) -> (model, Cmd
msg)
andThen update (model, cmd) =
  let
(newModel, newCmd) =
  update model
  in
newModel ! [ cmd, newCmd ]


This function enables separating concerns so you can apply many operations
one by one. I'm recently using this and now `update` function is cleaner
than ever. If your core problem is this, this might be the answer, not
components. So I wanted to know what concrete problem you are really want
to solve.



2017-04-20 23:22 GMT+09:00 Marek Fajkus :

> Richard,
>
> What I'm saying is that *individual functions*, as opposed to *a group of
>> functions and data structures* (model, view, update, msg, etc) is the
>> right unit of composition.
>
>
> I struggle to understand to see where is a difference. Html.program
> constructor is record of functions as well. Sometimes it's just nicer to
> have arguments named. Also as docs and code clearly says it's just
> composing functions, nothing more. init with init, update with update... I
> think saying that pure function inside record is by any mean different than
> pure function living in module's namespace is really misleading. For
> instance this using elm-decode-pipeline
> 
>  you're lifting (operation called pure in Json.Decode it's succeed)
> function (usually type constructor) to `Decoder` context. And it's fine
> because this is how functional programming work.
>
> You have mention experience with teaching beginners on many occasions.
> That's fair point I don't have that much experience teaching beginners
> however I have quite a lot experience with folks doing side project in elm
> being scared of complex apps.
> For instance our HR have contacted Tomas  just
> few days ago. Since he knows me from elm community meetups he DM. We're
> both czech (and was speaking czech) so I have to translate it (adding
> original and translation:
>
> czech:
>
>> No na to zatím nemám :) jsem Funkcionalni lama :)
>
>
> english:
>
>>  I can't do this :) I'm not that skilled in functional programming
>
>
> Than I spend 2 hours trying to convince him that there is nothing to be
> afraid of.
>
> Just on this Tuesday he wrote me again without previous warning (this is
> before interview which he will have next week):
>
> cze:
>
>> Třeba se to vyřeší samo a nevezmete mě. Alespoň pak naboucham nějaké
>> zkušenosti do zásoby na příští kolo ;)
>
>
> eng:
>
>>  Maybe it will resolve itself and will not hire me. At least I will have
>> time to gain more experience on next round.
>
>
> *THIS IS COMPLETELY CRAZY!*
>
> We've already lost one talented guy because he was afraid that he won't be
> able to do anything on such 

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

[Yosuke Torii]

I just read the whole conversation on Slack and realized what I said here
was somewhat pointless. I apologize for not reading the context.

So Marek's library is for organizing entire app, not about using external
library. If so, Richard's answer on reddit seems best fitted. About the
external libraries that have their own state, it is already answered well.

rtfeldman [3 days ago]
> the difference is that `thebritician/elm-autocomplete` is managing its own
> state because there is absolutely no possible other way to implement that
> library
> it's the last resort, not the default


I agree. It seems true from my experience too. Sometimes model, update, msg
and view are all together. But it is a special case. elm-component's API is
telling beginners as if they should always be together. Okay I completely
understand the context. It must be an anti-pattern!

Sorry again for confusing.


2017-04-20 9:21 GMT+09:00 Richard Feldman :

>
>> I thought I've understood this but I'm more and more confused by what
>> you're saying:
>>
>>> Crucially, between 0.16 and today, *we learned that a Model-View-Update
>>> triplet is the wrong unit of composition for Elm applications.*
>>
>> init update and subscribe are actually function. Looks like I still miss
>> something. Are you trying to say that Cmd.map is not function or what?
>>
>
> What I'm saying is that *individual functions*, as opposed to *a group of
> functions and data structures* (model, view, update, msg, etc) is the
> right unit of composition.
>
> In the example earlier in this thread
> , I
> showed an API for a reusable checkbox using a single function. I then
> showed an alternate API that resulted from the mindset that a *group* *of
> functions and data structures* (model, view, update, msg, etc) should be
> the atomic *unit of composition* - the notion that "you should build Elm
> applications by composing together model/view/update triplets" which I've
> seen cause pain. I pointed out that this mindset led to an overengineered
> checkbox API that was unnecessarily complex.
>
> Does that clarify?
>
> on different topic:
>>
>>  many of us have tried this, and found that composing individual
>>> functions was both simpler and consistently led to a much better experience.
>>
>>
>> Not even pointing out all nonsense: I just don't see any of them here
>>  just
>> yet. I hope they will shop up.
>>
>
> I'm not going to dig up a bunch of peoples' names and pester them to
> testify that this actually happens. :P
>
> Please don't start sending links to same Reddit thread once again.
>
>
> I'm doing that so that if beginners stumble on this thread and skim
> through it, they don't have to dig for what I'm recommending. :)
>
> --
> 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/Lo6bG96zotI/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Comments on the TEA Components package

[Yosuke Torii]

Richard,


> Can you think of a way to use this overloaded word in a way where the
> people in the discussion are not confused by it, even though they think it
> means different things?


I don't know. I just answered the question why I received your message as
"DIY every time". I'm not looking for the alternative for "component" .

I covered how to grow Elm application code bases
> <https://www.reddit.com/r/elm/comments/5jd2xn/how_to_structure_elm_with_multiple_models/dbuu0m4/>,
> and Evan covered reuse <https://guide.elm-lang.org/reuse/>.
> What is the remaining problem? :)


Again I agree to how to break the monolith and when to do it. But is any of
those reusable things non-TEA? I find UI libraries at packages.elm-lang.com
but they are often written in TEA manner. If it is not simple, how can they
be instead?

Sorry if you have already explained enough. Honestly it is hard to read
whole of messages, as Noah said.


Peter,

The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)


Yeah, I know. But at least, some of the UI widgets that does not have
side-effects can be solved. As far as I can see, the discussion here is not
on this stage yet.

I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg`
would solve it. The problem is that it allows any kind of side effects
including HTTP. But I don't find good explanation of why HTTP via view is
bad while random (or time stamp too?) is OK.


2017-04-20 5:40 GMT+09:00 Peter Damoc <pda...@gmail.com>:

>
>
> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii <jinjor...@gmail.com>
> wrote:
>
>> I'm curious what makes it sound that way, since as you noted, that is not
>>> the point I'm making.
>>>
>>
>> I don't know if others feels like me or not. But at least for me, "no
>> components" sounds a bit confusing (it is in official guide too).
>>
>
> I view it as destructive so, you're not alone in seeing something not OK
> with that.
>
>
>> Also, "no components, no nesting TEA" does not answer the problem
>> discussed here. So how can we do instead? Maybe introducing sortable-table
>> pattern is more constructive for this discussion. I think it is a variant
>> of TEA, managing its own state, but still keeping the form of "reusable
>> *view*". So great!
>>
>
> the sortable table is a clever component that pushed the external call to
> update inside the view.
> You still need what used to be the ChildMsg tag but now instead of
> calling the Child.update and saving the state it receives the updated
> state and just saves it.
>
> Other than the update trick, it's more or less the same thing as the old
> MUV triplets.
> You can even use the pattern to do nesting.
>
> The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)
>
>
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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/Lo6bG96zotI/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Comments on the TEA Components package

[Yosuke Torii]

>
> I'm curious what makes it sound that way, since as you noted, that is not
> the point I'm making.
>

I don't know if others feels like me or not. But at least for me, "no
components" sounds a bit confusing (it is in official guide too). As you
explained the context behind the term "component" is quite huge. I use the
word "component" just to say "reusable UI", so "no component" sounds like
"no reusable UI". But isn't sortable-table a component? For those who
understand the context, it is not a component, but I don't know how others
feel (especially who come from JS world).

Also, "no components, no nesting TEA" does not answer the problem discussed
here. So how can we do instead? Maybe introducing sortable-table pattern is
more constructive for this discussion. I think it is a variant of TEA,
managing its own state, but still keeping the form of "reusable *view*". So
great!



2017-04-20 4:39 GMT+09:00 Richard Feldman :

> You are right if everyone make their UI from scratch, but how about others
>> who wants to *use *existing library? For instance, date picker is a
>> popular widget. We expect this widget to do lot of complex things behind
>> the scene. But it requires state management (e.g. selected month). Without
>> nested TEA, how can we use this library? [...] elm-sortable-table is a good
>> example (I wonder why nobody mention it, btw). Calling update function is
>> not needed. You can use it just like  element. I hope UI libraries
>> that uses this pattern will increase.
>>
>
> I think Sortable Table is a perfect example of this!
>
> How do we use the library? The same way we use any library: we read the
> docs and plug into the API it provides.
>
> It doesn't need to be any more complicated than that. :)
>
> Terms like "component is proven to be an anti-pattern" sounds too negative
>> for me.
>>
>
> I appreciate the sentiment, but I think it's appropriate to be negative
> when exploring something has yielded an overall negative result. :)
>
>
>> It sounds like "Elm proposes DIY every time, no reusable UI ever!", even
>> if you mean "no need to make everything a component for building app, there
>> are actually not so many reusable UI parts in practice".
>>
>
> I'm curious what makes it sound that way, since as you noted, that is not
> the point I'm making.
>
> Any feedback on how I could be clearer would be appreciated!
>
>> --
> 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/Lo6bG96zotI/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Comments on the TEA Components package

[Yosuke Torii]

Richard,

I'm curious how your product *uses* (not makes) external UI library. You 
are right if everyone make their UI from scratch, but how about others who 
wants to *use *existing library? For instance, date picker is a popular 
widget. We expect this widget to do lot of complex things behind the scene. 
But it requires state management (e.g. selected month). Without nested TEA, 
how can we use this library? I think TEA gives the best user experience for 
those widgets.

If I understand correctly, Marek's library is trying to reduce the cost of 
using them. I agree with your opinion about breaking the monolith or "don't 
make needless things for saving time". It's the best practice of agile 
development. But does "scale" mean just "my app become big"? I expect that 
word to mean "easy to use external library, custom widgets can be easily 
made and they can be used across pages".

I don't think the exploration of TEA is finished. elm-sortable-table is a 
good example (I wonder why nobody mention it, btw). Calling update function 
is not needed. You can use it just like  element. I hope UI 
libraries that uses this pattern will increase.

Terms like "component is proven to be an anti-pattern" sounds too negative 
for me. It sounds like "Elm proposes DIY every time, no reusable UI ever!", 
even if you mean "no need to make everything a component for building app, 
there are actually not so many reusable UI parts in practice".



2017年4月20日木曜日 2時27分09秒 UTC+9 Richard Feldman:
>
> so, the Model-View-Update triplet *is NOT* the wrong unit of composition 
>> for Elm applications? :) 
>>
>> > How do you propose to split the functionality one has in a highly 
>>> complex app with a lot of pages without using those triplets?
>>>
>>> I don't haha...I just defended their use a few posts ago, complete with 
>>> the specific example of the reusable signup form.
>>
>>
> To recap:
>
>1. Earlier 
> 
>I said "between 0.16 and today, *we learned that a Model-View-Update 
>triplet is the wrong unit of composition for Elm applications...composing 
>individual functions* was both simpler and consistently led to a much 
>better experience. I've laid out my advice for specifically how to do that 
>here 
>
> 
>."
>2. Later 
> 
>I pointed out an example of when it would be useful to use Html.map 
>and Cmd.map to make a reusable signup form, and for that use case it 
>happened to make sense to have a separate model, view, and update.
>
> In (1) I am saying that I expect you'll have a better time if you think 
> about building Elm applications in terms of *composing individual 
> functions*, not in terms of composing Model/View/Update triplets.
>
> In (2) I am giving an example of a very specific set of circumstances in 
> which a separate Model/View/Update makes sense.
>
> In summary: "Here is a useful but complex tool. Always reach for a simpler 
> one first." 
>
>>

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

Re: [elm-discuss] Re: input value solution

[Yosuke Torii]

Thank you kind people!

Gusztáv, cool! It worked fine for me. I've never come to the simple idea of
setting the value outside. I don't see any downside of this now.

For reference, here <https://ellie-app.com/DY2qpJnRNDa1/0> is what I tried
(thanks Ellie). This is tiny example but my real app worked fine too.

I hope the normal value attribute will work like this someday. But for now,
this seems a good workaround :D



2017-03-15 14:07 GMT+09:00 Gusztáv Szikszai <cyber.gusz...@gmail.com>:

> This should be part of elm-lang/dom as a task or a command. I have my own
> dom package which elm-ui uses and it has this functionality, if you don't
> want to use non official packages than i would suggest adding and *id 
> *attribute
> to your input and creating a port (port setValue : String -> String -> Cmd
> msg) that sets it's value and then calling that command when you want to
> set it.
>
> On Tuesday, March 14, 2017 at 7:28:06 AM UTC+1, Yosuke Torii wrote:
>>
>> There have been many discussions about this, but please allow me to pick
>> it up again.
>>
>> As far as I know, the problem is briefly summarized as follows:
>>
>> `Html.Attributes.value` behaves crazily when we type rapidly.
>> `Html.Attributes.defaultValue` solves this but it does not allow to
>> programmatically change the value. There seems no solution for satisfying
>> both of these requirements.
>>
>> I believe this is very common requirement of web/gui apps. How do people
>> address this? Personally, I've been blocked on this for 6 months... So I
>> don't want a clean solution. Any workaround / hack is welcome.
>>
>>
>> --
> 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/kdNuohiIX4U/unsubscribe.
> To unsubscribe from this group and all its topics, 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] input value solution

[Yosuke Torii]

There have been many discussions about this, but please allow me to pick it 
up again.

As far as I know, the problem is briefly summarized as follows:

`Html.Attributes.value` behaves crazily when we type rapidly. 
`Html.Attributes.defaultValue` solves this but it does not allow to 
programmatically change the value. There seems no solution for satisfying 
both of these requirements.

I believe this is very common requirement of web/gui apps. How do people 
address this? Personally, I've been blocked on this for 6 months... So I 
don't want a clean solution. Any workaround / hack is 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: Subscriptions and deep nested components.

[Yosuke Torii]

I'd do like this. Not sure how deep it can do well though.

https://gist.github.com/jinjor/2a26826bc0a1ed833146a7b29c6e3ab8


2016年9月23日金曜日 3時11分40秒 UTC+9 Umur Ozkul:
>
> I have a deep component hierarchy and subscriptions are needed by the 
> components deep down. However subscriptions are handled by main. What is 
> the best way to delegate the messages to responsible components deep in the 
> hierarchy?
>

-- 
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: Problem with Html.Lazy

[Yosuke Torii]

Thanks for your responses.

If it used equality then imagine suddenly comparing a huge model that you
> passed in, the speed benefits are entirely gone at that point.


I'm not sure if huge model always requires huge cost. If `{ largeModel =
largeModel }` is passed and two largeModel are reference equal, it is cheap
cost to compare them.

  view model = lazy someViewHelper model.data
>   someViewHelper data = someView { data = data }


Yeah, this is good for workaround, but it needs interface to be changed. I
often pass large-grained models to let views choose what parameters to use
by their responsibility, but this way lazy never works. So breaking into
small models are possible but I wonder it is good for maintainability.



2016-09-13 11:54 GMT-05:00 Mark Hamburg <mhamburg...@gmail.com>:

> There are things you can do in your code to help and things that Elm could
> do (maybe already does) in its implementation to help:
>
> For the data construction issue, you need to create an intervening
> function that does the construction:
>
> view model = lazy someViewHelper model.data
> someViewHelper data = someView { data = data }
>
>
> But probably not:
>
> view model = lazy (\data -> someView { data = data }) model.data
>
>
> The compiler could optimize that but might not. That leads to the list of
> things the compiler could do (and may be doing) to help:
>
>
>- Lift constant expressions. This would help with anonymous functions,
>config records, etc.
>- Optimize { m | field = value } to return m if m.field is already
>equal (referentially) to value.
>
> Sadly, this last optimization doesn't get us anywhere if we are routinely
> working with tagged union members since we can't just return the value we
> already have. The compiler could cache the last few values constructed with
> any given type tag but that creates a drag on the GC.
>
> Mark
>
> P.S. I shifted my code for a while to a form where update had the
> signature: update : Msg -> Model -> ( Maybe Model, Cmd Msg ) with the
> maybe on the result being used so that unchanged could be indicated by
> returning Nothing. This, however, makes sequences of updates harder
> because we don't have the model always available which is nice for writing
> operators like the following:
>
> (!>) : (model, Cmd msg) -> (model -> (model, Cmd msg)) -> (model, Cmd msg)
> (!>) : (oldModel, oldCmd) update =
> let
> (newModel, newCmd) = update oldModel
> in
> (newModel, Cmd.batch [oldCmd, newCmd])
>
>
> The version that works with maybe results needs triples for the state
> which can largely be hidden but does tend to then require beginUpdate and
> endUpdate functions as well.
>
>
> On Tue, Sep 13, 2016 at 7:34 AM, OvermindDL1 <overmind...@gmail.com>
> wrote:
>
>> Lazy is purely and entirely for speed reason, the referential equality is
>> for that purpose. If it used equality then imagine suddenly comparing a
>> huge model that you passed in, the speed benefits are entirely gone at that
>> point.  It is very much a corner case that should not be used except in
>> very specific situations.  :-)
>>
>>
>> On Tuesday, September 13, 2016 at 7:43:28 AM UTC-6, James Wilson wrote:
>>>
>>> I had similar feelings; lazy uses a magical referential equality between
>>> things that afaik isn't exposed elsewhere; to me it would be more
>>> obvious/clear if it used the same sort of equality as everything else (==),
>>> which I'd hope would be able to short circuit the meat of the checking if
>>> referentially equal anyway.
>>>
>>> Basically, I'd be interested to hear more about the decision to use
>>> referential equality with lazy too :)
>>>
>>> On Tuesday, 13 September 2016 12:09:05 UTC+1, Yosuke Torii wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have a question about Html.Lazy.
>>>>
>>>> Now I'm optimizing rendering using Html.Lazy but I feel it is difficult
>>>> to use. I found the arguments are not often *referentially* equal and
>>>> the view functions are unfortunately called. There are some problems around
>>>> this.
>>>>
>>>>
>>>> 1. Sometimes new values are created every time.
>>>>
>>>> view model = lazy someView { data = model.data }
>>>>
>>>> 2. Views do not know how arguments are passed.
>>>>
>>>> view model = lazy grandchildView model
>>>>
>>>> 3. It is not easy to know if optimization succeeds or not.
>>>>
>>>> view model = Debug.log "U

[elm-discuss] Problem with Html.Lazy

[Yosuke Torii]

Hi,

I have a question about Html.Lazy.

Now I'm optimizing rendering using Html.Lazy but I feel it is difficult to 
use. I found the arguments are not often *referentially* equal and the view 
functions are unfortunately called. There are some problems around this.


1. Sometimes new values are created every time.

view model = lazy someView { data = model.data }

2. Views do not know how arguments are passed.

view model = lazy grandchildView model

3. It is not easy to know if optimization succeeds or not.

view model = Debug.log "Unfortunately called!" <| text (toString model)


I made a demo to describe this problem.

Source: https://github.com/jinjor/elm-issues/blob/master/src/HtmlLazy.elm
Demo: https://jinjor.github.io/elm-issues/html-lazy.html
(9 example views, but 4 ~ 9 are not optimized unfortunately)

So my question is:

   - Is it a bad idea to compare by *normal *equal? 
   - Have anyone already solved this problem?


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] Problem with SVG icons

[Yosuke Torii]

Hi,

I have a question about SVG icons. I found both 
elm-community/elm-material-icons and jystic/elm-font-awesome have the same 
problem. When icons are small, they do not fit to their container 
components.

SSCCE (using elm-font-awesome):

   - Source 
   
   - View 
   
If width >= 15px, it works as expected. Otherwise, the icon is not located 
at the right position.

What is the best solution to this issue? I also found if svg tag has `display: 
block` style, it works as expected. I wonder if always attaching it causes 
some other problems or not. Any idea?

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] Visualizing module dependencies in a project

[Yosuke Torii]

Hi all,

I made elm-dep-check , a tool for 
visualizing module dependencies in a Elm project. The motivation was just 
curious to know how my project is working as a whole (which is over 7k LOC 
large now, btw), but I also think this may be useful to keep Elm projects 
healthy.

Using this tool, you'll know following information:

- How modules are depending on other modules
- Local rules of a project is observed (e.g. `Model.*` should not use 
`View.*`)
- Whether circular dependencies among *directories* exist or not (e.g. 
`Some.A` -> `Other.B` -> `Some.C`)

Other possible features are noted here 
.

This tool is still POC state now, but already provides enough information. 
Do you think it helps your project?

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] Re: Form with union type

[Yosuke Torii]

Hi Simone,

I wrote the fixed version here 
 (copy & 
paste to Try Elm ).
Union type was not wrong. The `on` function assumes an event object to be 
decoded, but you expect a string.
So I used `targetValue` decoder, which is a shortcut for `e.target.value`.


2016年7月28日木曜日 0時25分46秒 UTC+9 Simone Vittori:
>
> I'm building a language selector and I'd like to map the options to a 
> union type.
>
> Here's what I tried:
>
> import Json.Decode exposing (Decoder, customDecoder, string)
>
> {-| Currently supported languages. -}
> type Language
> = English
> | Japanese
>
>
> {-| A JSON decoder of Language. -}
> languageDecoder : Decoder Language
> languageDecoder =
> customDecoder string fromStringLanguage
>
>
> fromStringLanguage : String -> Result String Language
> fromStringLanguage str =
> case str of
> "English" -> Ok English
> "Japanese" -> Ok Japanese
> other -> Err ("Invalid language: " ++ other)
>
> And here's how I'm using it:
>
> -- MODEL
>
> type alias Model = Language
>
>
> -- UPDATE
>
> type Msg
> = Change Language
>
> update : Msg -> Model -> Model
> update msg model =
> case msg of
> Change language -> language
>
>
> -- VIEW
>
> view : Model -> Html Msg
> view model =
> Html.form []
> [ select [ on "change" <| Json.Decode.map Change languageDecoder ]
> (List.map (viewOption model) ["English", "Japanese"])
> ]
>
> It does compile successfully, but when I select another option from the 
> dropdown list, nothing happens. Any ideas?
> Is this the right way of decoding a union type?
>

-- 
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: Is there a way to investigate a Html tree?

[Yosuke Torii]

Recently I wrote a little parser for `toString` representation.

https://github.com/jinjor/elm-time-travel/blob/master/src/TimeTravel/Internal/Parser/Parser.elm

It turns
toString <| div [] [ input [ type' "text", class "foo", onClick 1 ] [], 
text "hello" ]

into
Record ([Property "type" (StringLiteral "node"),Property "tag" (
StringLiteral "div"),Property "facts" (Record []),Property "children" (
Record ([Property "0" (Record ([Property "type" (StringLiteral "node"),
Property "tag" (StringLiteral "input"),Property "facts" (Record ([Property 
"type" (StringLiteral "text"),Property "className" (StringLiteral "foo"),
Property "EVENT" (Record ([Property "click" (Record ([Property "options" (
Record ([Property "stopPropagation" (Union "False" []),Property 
"preventDefault" (Union "False" [])])),Property "decoder" (Value ""
)]))]))])),Property "children" (Record []),Property "namespace" (Value 
""),Property "descendantsCount" (Value "0")])),Property "1" (Record 
([Property "type" (StringLiteral "text"),Property "text" (StringLiteral 
"hello")]))])),Property "namespace" (Value ""),Property 
"descendantsCount" (Value "2")])

Peter, is this close to what you want to do?


2016年7月28日木曜日 18時21分58秒 UTC+9 Peter Damoc:
>
> I need to gather all the class names used in a Html tree generated by the 
> app. 
>
> Is there a way to do this short of converting the html to a string and 
> manually parsing it? 
>
>  
>
>
>
> -- 
> 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.

Re: [elm-discuss] Re: Draft blog post - "How to Use Elm at Work" - looking for feedback

[Yosuke Torii]

Sorry, please let me adjust my previous comment.

I said React+Elm is too large, but now I found it's NOT so large as I
thought.
(Of course not as small as lightweight libraries yet)

I just saw the number at TodoMVC.

elm.js: 69.7 KB gziped
(including all user code)

react-with-addons.js: 174 KB gziped

jquery.js: 83.9 KB gziped

I'm surprised the fact Elm is even smaller than jQuery.
It means React+Elm is smaller than React+jQuery.
Considering it's temporary to use them together, this number is not too
bad, I think.


2016-07-11 3:37 GMT+09:00 Richard Feldman :

> It's all good. :)
>
> This stuff is complicated!
>
> On Sun, Jul 10, 2016, 11:19 AM Peter Damoc  wrote:
>
>> Richard,
>>
>> Thank you for taking the time to write this considerate answer.
>>
>> I apologize for the post I wrote yesterday.
>> I was in a very very dark place after a night plagued by insomnia at the
>> end of an extremely stressful week where I could not get anything done.
>>
>> Fear is the path to the dark side... and I think I let fear take over.
>>
>> Anyway, it is fascinating to see that such a seemingly simple topic has
>> the brightest minds in the world still looking for an answer.
>>
>> I did not knew that the situation is this complicated.
>>
>>
>>
>>
>> On Sun, Jul 10, 2016 at 8:54 PM, Richard Feldman <
>> richard.t.feld...@gmail.com> wrote:
>>
>>>
>>>
 Regarding the user form, you said that what I asked is trivial in Elm.
 Do you have some kind of sample code that you can share or, if you
 would be so kind, could you post some sample repository that does that?

>>> I would *LOVE* to be proven wrong about that. I would love to see some
 simple Elm code that outputs a form that looks like it came from 2016 and
 go "oops, my bad, sorry for wasting everyone's time".

>>>
>>> Sure - I even wrote a blog post
>>> 
>>>  about
>>> it. :)
>>>
>>> That post includes examples in the form of SignupForm.elm
>>> 
>>>  and the styles that go with it
>>> .
>>>  I
>>> didn't bother inline the styles into Elm, but obviously that's a copy/paste
>>> and find/replace job.
>>>
>>> All of Graphics.Input was dropped
>>>
>>>
>>> Ah, I did not know that! My mistake. You're right, Janis.
>>>
>>> Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not
 arguing that people are not still fighting.
 What I said was that "*they were explicitly or implicitly dismissed"*.

>>> If you want me to be more explicit, I was thinking about the discussions
 around boilerplate that prompted elm-parts, the difficulties around
 geometry that prompted debois/elm-dom.

>>>
>>> Facebook released React with a built-in, dead-easy way to do reusable
>>> stateful components: each component has its own local mutable state.
>>>
>>> However, they at Facebook weren't satisfied with how this UX scaled, so
>>> they also released Flux as a more scalable way to manage state.
>>>
>>> Many people weren't happy with Flux, though, so they started looking
>>> elsewhere, for example to ClojureScript, leading to Omniscient.js
>>>  based on David Nolen's
>>> cursor-based state management model for Om
>>> .
>>>
>>> David Nolen himself ended up moving away from that with Om Next
>>> , which
>>> abandoned cursors in favor of a custom state management system based on
>>> Relay, Falcor, and Datomic. Obviously not everyone agrees with him;
>>> Omniscient.js is still under active development. Its last commit is 2 days
>>> ago.
>>>
>>> Others looked to Elm, like Dan Abramov, who created Redux
>>> . It's very popular in the React
>>> world, although since Facebook hired Dan, he's been working on ways to make
>>> React not need it anymore. That seems likely to result in the release of a
>>> new way to do things , whenever whatever it is
>>> gets released.
>>>
>>> Others thought Redux was too heavyweight and trying to do too much at
>>> once, which has led to Choo
>>> , a self-described
>>> 
>>> adaptation of Elm 0.17's architecture in JS.
>>>
>>> I've spent hours discussing these things with Jafar Husain at Netflix,
>>> who thinks Observables are the answer. See for example rx-react
>>>  or Andre Staltz's popular
>>> Cycle.js .
>>>
>>> This is to say nothing of how Angular manages state. Or Ember. Or
>>> Aurelia. Or Vue.
>>>
>>> My point is this:
>>>
>>> *Every single community that's 

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

[Yosuke Torii]

FYI, I just released jinjor/elm-inline-hover 
.

I hope it would be helpful for you ;)


2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:
>
> How do you handle styling in your Elm programs? 
>
> Do you use one of the following libraries?
>
> rtfeldman/elm-css
>
> seanhess/elm-style
>
> massung/elm-css
>
> Or do you do something completely different (manual style inlining, 
> classes and external css) ? 
>
> I tried using Sean's library but I quickly ran into pseudo-selectors 
> trouble wanting to implement a simple hover effect. 
>
> Somehow, keeping a set of hover states for some simple nav-link seams such 
> an overkill. 
>
> How do you handle such scenarios? 
>
>
>
> -- 
> 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.

Re: [elm-discuss] Support for binary data

[Yosuke Torii]

I need binary things too for two cases, uploading files and Web Audio. 
These are not special things.

I'd like to know the plans, when it is most likely to come (or how these 
features are prioritized).


2016年6月21日火曜日 19時36分59秒 UTC+9 John Mayer:
>
> I took a shot at starting a basic version of this in my fork of websocket 
> and a new package simply called binary. My approach was largely thin 
> wrappers on top of the spec.
>
> Evan, is your draft public? No updates from you since January. IMHO, don't 
> try to carry this one yourself. This is an opportunity to spread the load 
> and develop yourself as a manager of contributors while building out the 
> process for accepting large contributions.
> On Jun 21, 2016 6:09 AM, "Gábor Varga"  
> wrote:
>
>> This feature would come handy for me too.
>> Our use-case is that we get some encrypted data from an MQTT broker and 
>> it might be broken up to several messages. 
>> The binary data first has to be reassembled before it can be converted to 
>> UTF8 encoded strings.
>>
>>
>>
>>
>> On Thursday, April 7, 2016 at 1:18:17 AM UTC+2, Ian Mackenzie wrote:
>>>
>>> I'd love to have ArrayBuffers supported for doing WebGL stuff. For 
>>> rendering very large and complex scenes, I think it would be useful to be 
>>> able to do a lot of the heavy lifting (level of detail and occlusion 
>>> calculations etc.) on the server, and then just send compact ArrayBuffers 
>>> to the client that could be passed directly to 
>>> WebGLRenderingContext.bufferData() or similar (via an Elm wrapper, 
>>> presumably, but without any parsing/conversion/copying).
>>>
>>> On Tuesday, 12 January 2016 11:32:43 UTC+11, Evan wrote:

 I have been drafting Blob and ArrayBuffer APIs, but I wasn't sure who 
 needed them.

 What is your particular use case?

 On Mon, Jan 11, 2016 at 4:55 AM, John Watson  
 wrote:

> Can anyone tell me what the plans are for supporting binary data in 
> elm?  I'm thinking of a Byte (and some sort of Byte Array) type and also 
> implementing Blob in HTTP responses. 
>
> -- 
> 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...@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: Time Travel Debugger for v0.17

[Yosuke Torii]

Oh, it looks great!

I'll look into it. Thank you :)


2016年6月9日木曜日 18時45分22秒 UTC+9 Fedor Nezhivoi:
>
> I guess currently we may stay with 
> https://github.com/fluxxu/elm-hot-loader. This of course introduce 
> webpack which is not a great thing, but it may be a workaround for now.
>
> понедельник, 6 июня 2016 г., 14:23:35 UTC+6 пользователь Yosuke Torii 
> написал:
>>
>> Hi all,
>>
>> Is it convenient for you if there would be a new version of Time Travel 
>> Debugger for 0.17?
>> I made a prototype on GitHub (Repository 
>> <https://github.com/jinjor/elm-time-travel>, Demo 
>> <http://jinjor.github.io/elm-time-travel/>). (Not published yet.)
>>
>> Possible feature to be implemented in the future is:
>>
>>- format model (e.g. indent, syntax highlight)
>>- show diff between before and after msg
>>- watch certain property and stop when it is changed
>>- form a Cmd tree where the root is user action and has chained Cmds
>>- enable to show panel in other place (Currently it is fixed on the 
>>right)
>>
>>
>> Please give me feedback if you are interested :)
>>
>> 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] Re: How do you handle module name clashes?

[Yosuke Torii]

I'm curious about it too.

For library authors, there seems no way to check duplication automatically.
Is this a new issue, or is there a guideline about module names?


2016年6月10日金曜日 21時55分35秒 UTC+9 Peter Damoc:
>
> I want to use 
>
> mdgriffith / elm-style-animation / Style
> and 
> seanhess / elm-style / Style
>
> How does one handles such situations?
>
> The modules do something completely different and are complementary 
> somehow. 
>
>
>
> -- 
> 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.

Re: [elm-discuss] Re: Time Travel Debugger for v0.17

[Yosuke Torii]

Hmm... It seems the most interesting part is hot swapping (which is hard
for me to implement). Without hot swapping, the remaining feature is
"search some point, play from that point and go toward another future".
This makes sense to some extent because you sometimes miss the route, but
you cannot fix the behavior.

In this context, let's ask Evan. I recently found it is difficult to modify
inline style of all list items at the same time. Hot swapping would also do
well for such cases.



2016-06-07 17:52 GMT+09:00 Claudia Doppioslash <
claudia.doppiosl...@gmail.com>:

> Yes, it's very useful for games.
> Here's why https://youtu.be/wxWM4t68cR4?t=12m in that video the developer
> is trying to get the character to jump to a specific place by adjusting the
> gravity.
> So the workflow is changing some code, then waiting for a build to
> complete, than playing to that point again.
> Which is a horrible and slow.
>
>
> On 7 June 2016 at 08:00, Yosuke Torii <jinjor...@gmail.com> wrote:
>
>> Yeah, I know. The time-traveling feature is still alive in my version (by
>> clicking messages).
>>
>> But I have little experience of animation or game-like programs. Is
>> slider useful for them?
>>
>
> --
> Claudia Doppioslash
>
> @doppioslash <http://www.twitter.com/doppioslash>
> http://blog.doppioslash.com
> http://www.lambdacat.com
>
> --
> 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/vtDxwvsL7DE/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Time Travel Debugger for v0.17

[Yosuke Torii]

Thank you for all feedback!

About the slider which traditional debugger used to have, I'm not sure it
would be used very much in practice. I think pointing exact state is better
feature and it is enough for debugging. It looks fancy for demonstration
though :)

About logging filtered model, I agree but think it can also be done by UI
(and localStorage which Elm does not support yet). I'll try with this way
first.

Anyway, I will release this soon. It's very early for practical use but you
can easily try it. I hope this implementation would inspire the upcoming
official one.



2016-06-07 7:00 GMT+09:00 Mario Sangiorgio <mariosangior...@gmail.com>:

> This is very promising!
>
> I think this is a simple and very effective solution to the problem. I
> also like that this is a pure Elm implementation which works on top of
> reactor but doesn't have any strong dependency on it.
>
> Just a few minutes ago Evan closed this issue on time travelling debugging
> on the reactor for Elm 0.17.
> https://github.com/elm-lang/elm-reactor/issues/186
> It would be great to discuss with him your implementation, to try to
> figure out what is missing and to come up with the best design to fill the
> gaps.
>
> On Mon, Jun 6, 2016 at 1:02 PM Zinggi <schrott57...@gmail.com> wrote:
>
>> Wow, this is great!
>> I also love the fact that this is 100% made with elm, no js at all.
>> It would be cool if the UI had a time slider, in the spirit of the old
>> time travel debugger.
>>
>> Maybe you could also add a debugView : Model -> a to TimeTravel.program
>> so that a user can apply a filter to what gets logged.
>> E.g. debugView = \model -> model.someInner.model
>>
>> Keep it up!
>>
>>
>> On Monday, 6 June 2016 10:23:35 UTC+2, Yosuke Torii wrote:
>>>
>>> Hi all,
>>>
>>> Is it convenient for you if there would be a new version of Time Travel
>>> Debugger for 0.17?
>>> I made a prototype on GitHub (Repository
>>> <https://github.com/jinjor/elm-time-travel>, Demo
>>> <http://jinjor.github.io/elm-time-travel/>). (Not published yet.)
>>>
>>> Possible feature to be implemented in the future is:
>>>
>>>- format model (e.g. indent, syntax highlight)
>>>- show diff between before and after msg
>>>- watch certain property and stop when it is changed
>>>- form a Cmd tree where the root is user action and has chained Cmds
>>>- enable to show panel in other place (Currently it is fixed on the
>>>right)
>>>
>>>
>>> Please give me feedback if you are interested :)
>>>
>>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/vtDxwvsL7DE/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: State of CSS in Elm

[Yosuke Torii]

>
> For `:hover`, I wrote a helper today (here
> <https://gist.github.com/jinjor/439a6721065eeb83abc5a9da4049cec9>). It's
> not used yet, but might be useful :)


Hmm... I just tried it, but not so useful as I thought.


2016-06-01 17:44 GMT+09:00 Yosuke Torii <jinjor...@gmail.com>:

> I use pure elm-html. Like David, I write styles in a separated Elm file
> called `Styles.elm`, but each style is declared as `List (String, String)`
> for composability.
>
> zIndex =
>   { subView = "600"
>   , messageBar = "700"
>   , contextMenu = "800"
>   }
>
> messageBar =
> [ ("position", "absolute")
> , ("color", "#fff")
> , ("z-index", zIndex.messageBar)
> , ("padding", "5px 10px")
> , ("transition", "height opacity 0.8s linear")
> ]
>
> successBar =
>   messageBar ++
> [ ("background-color", "#4c5")
> , ("opacity", "1")
> ]
>
> Sometimes it takes arguments for dynamic values.
>
> mainView windowHeight =
>   flex ++
> [ ("height", px (windowHeight - headerHeight))
> , ("position", "relative")
> ]
>
> I also use tiny CSS for resetting default styles and using `:hover`. For
> `:hover`, I wrote a helper today (here
> <https://gist.github.com/jinjor/439a6721065eeb83abc5a9da4049cec9>). It's
> not used yet, but might be useful :)
>
>
> 2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:
>>
>> How do you handle styling in your Elm programs?
>>
>> Do you use one of the following libraries?
>>
>> rtfeldman/elm-css
>>
>> seanhess/elm-style
>>
>> massung/elm-css
>>
>> Or do you do something completely different (manual style inlining,
>> classes and external css) ?
>>
>> I tried using Sean's library but I quickly ran into pseudo-selectors
>> trouble wanting to implement a simple hover effect.
>>
>> Somehow, keeping a set of hover states for some simple nav-link seams
>> such an overkill.
>>
>> How do you handle such scenarios?
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
> --
> 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/AC6cqdeKDOs/unsubscribe.
> To unsubscribe from this group and all its topics, 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: State of CSS in Elm

[Yosuke Torii]

I use pure elm-html. Like David, I write styles in a separated Elm file 
called `Styles.elm`, but each style is declared as `List (String, String)` 
for composability.

zIndex =
  { subView = "600"
  , messageBar = "700"
  , contextMenu = "800"
  }

messageBar =
[ ("position", "absolute")
, ("color", "#fff")
, ("z-index", zIndex.messageBar)
, ("padding", "5px 10px")
, ("transition", "height opacity 0.8s linear")
]

successBar =
  messageBar ++
[ ("background-color", "#4c5")
, ("opacity", "1")
]

Sometimes it takes arguments for dynamic values.

mainView windowHeight =
  flex ++
[ ("height", px (windowHeight - headerHeight))
, ("position", "relative")
]

I also use tiny CSS for resetting default styles and using `:hover`. For 
`:hover`, I wrote a helper today (here 
). It's 
not used yet, but might be useful :)


2016年5月31日火曜日 18時26分37秒 UTC+9 Peter Damoc:
>
> How do you handle styling in your Elm programs? 
>
> Do you use one of the following libraries?
>
> rtfeldman/elm-css
>
> seanhess/elm-style
>
> massung/elm-css
>
> Or do you do something completely different (manual style inlining, 
> classes and external css) ? 
>
> I tried using Sean's library but I quickly ran into pseudo-selectors 
> trouble wanting to implement a simple hover effect. 
>
> Somehow, keeping a set of hover states for some simple nav-link seams such 
> an overkill. 
>
> How do you handle such scenarios? 
>
>
>
> -- 
> 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.

Re: [elm-discuss] Re: How to implement wrapping components in elm

[Yosuke Torii]

Oh, it looks just nesting views (I'm not familiar with ClojureScript
though). If so, the solution is much simpler. Like this:

```
container : List (Html msg) -> Html msg
container children =
  div
[  style [ ("padding", "20px") ] ]
children
```

full version


Isn't it working for you? I often use this pattern for popup.


2016-05-18 19:15 GMT+09:00 Daniel Kwiecinski :

> Here is a sketch of how it would look like in reagent (ClojureScript)
>
>
> ; -- SOME CONCRETE COMPONENTS
>
> ; a component taking a String as a model
> (defn hello-component [name]
>   [:p "Hello, " name "!"])
>
> ; a stateless component using another component
> (defn say-hello []
>   [hello-component "world"])
>
> ; a component taking a ratom (it's a signal in elm speak) as a model
> (defn reactive-hello-component [name]
>   [:p "Hello, " @name "!"])
>
> ; a component taking list of Strings as a model
> (defn list-hellos [names]
>   (for [n names]
>[hello-component (str "hello " n)]))
>
> ; -- GENERIC WRAPPING COMPONENT
>
>
> ; a wrapping components. take list of components as a parameter and wraps 
> them in pages
> (defn wrap-components [components]
>   (fn []
>   [:div {:class "components-wrapped-in-pages-so-we-can-swipe-them"}
>(for [c components]
> [:div {:class "page"} c])]))
>
>
> ; -- MAIN VIEW GLUING ALL TOGETHER
>
>
> (defn main-view []
>   (let [reactive-name (ratom "initial-name")
> input-state (ratom "")]
>[:div {:class "some-boilerplate"}
>
> ; the two lines below are not following re-frame pattern. There 
> are there just to express I have the state which changes.
> [:input {:onchange (fn [value] (!reset input-state value))}] ; 
> react to inout changes and pass the value to model (in re-frame instead of 
> directly updating the model we would send a signal (as in elm) and have 
> subscription react to the signal but for simplicity I ommit the patern)
> [:button {:onclick #(!reset reactive-name @input-state)}] ; copy 
> the states on button click
>
> [:span {:class 
> "here-come-generic-swipe-able-pages-wrapping-any-components"}
>
>  ; here is the usage of the wrapping container
>  (wrap-components [
>say-hello ; stateless component
>#(hello-component "some-fancy-name") ; #(...) 
> is lambda in clojure, here we close over some static state
>#(reactive-hello-component reactive-name) ; 
> #(...) here we close over some reactive state, so the component re-renders 
> when the model (state) changes
>#(list-hellos ["a" "b" "c"]) ; component 
> taking list as a state (model)
>])]]))
>
> ; -- MOUNT VIEW TO DOM
>
> ; bind the main-view to DOM and start observing deltas to render if needed
> (defn ^:export run []
>   (r/render [main-view] (js/document.body)))
>
>
>
>
> On Wednesday, 18 May 2016 08:42:45 UTC+1, Peter Damoc wrote:
>>
>> Can you mock some code that would show how would you like to use this?
>> Imagine that it is already implemented in some library and write against
>> that imaginary library.
>>
>>
>>
>>
>> On Tue, May 17, 2016 at 5:36 PM, Daniel Kwiecinski > > wrote:
>>
>>> The problem is that the generic container component (Let's call it C) do
>>> not know about it potential children (let's call them X, Y, Z) . There is
>>> top level component (Let's call it T) which has a knowledge about all of
>>> them (it is the app). The C is in self contained package, you can consider
>>> it to implement material design list view. How Can I implement C so T can
>>> use T with X, Y, Z ?
>>>
>>> On Tuesday, 17 May 2016 15:09:36 UTC+1, Peter Damoc wrote:

 Hi Daniel,

 If you have a limited number of components you can unify them into one
 kind of a component.

 Here is a self contained example that unifies Counter and RandomGif and
 then uses them in a single list.
 https://gist.github.com/pdamoc/aef6306a9001de109aeece37e5627d06




 On Tue, May 17, 2016 at 3:47 PM, Daniel Kwiecinski <
 daniel.k...@gmail.com> wrote:

> So let me expand my scenario a little bit. Lets assume that the
> CounterList component is very feature heavy. It makes lots of work to
> layout its children, manages drag to sort or whatever fancy stuff you can
> imagine. Now in my app I have many instances of usage of CounterList and I
> want to apply the complex behaviour not only to counters but also to gif
> and to mixed counters with gifs and many many other possible 
> configurations
> (think in hundreds). I don't really want to implement dedicated
> CounterList, GifList, 2GifsWith3CountersList and other few