[elm-discuss] timeout in unit test

[Max Goldstein]

No, there is no way to do this currently. 

You can open an issue on GitHub if you want to discuss further. 

-- 
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: Proposal: move Random.Extra.constant to Random

[Max Goldstein]

I also think it’s a good idea. I’ve brought it up with Evan and Richard before. 
But I can tell you from experience that getting changes merged into the Random 
module is very difficult.

Also, shameless plug for mgold/elm-random-pcg, which includes this and many 
other useful functions built on a superior PRNG. 

-- 
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] Looking for pretty printers written in Elm?

[Max Goldstein]

Can you please tell us more about what you are trying to pretty print (JSON?) 
and why (restraints, assumptions, etc)?

-- 
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: Rails integrations issues

[Max Goldstein]

Assuming that works as described, you should think about sending a PR upstream. 

-- 
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] Is it possible to write a general tree-fold function?

[Max Goldstein]

I will add that you are using z when you define _l and _r but you only need to 
use it once. 

Also, a good test case is to write an in-order traversal on a binary search 
tree that will return the keys in sorted order. 

-- 
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] Platform.Cmd.batch executes commands in reverse order

[Max Goldstein]

"independently, concurrently, in the order they're provided"

This is a contradiction. Even if the runtime started the tasks at the same 
time, the works they do can complete in any order. Either your code (Elm or 
otherwise) should work with any ordering, or you should sequence things in Elm 
tasks. 

If the runtime is iterating through the list backwards, that's an 
implementation detail. 

-- 
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: Missing json decoding tool to decode multitouch events cleanly

[Max Goldstein]

What about something like this?

decodeTouches : Decoder (List Touch)
decodeTouches =
Decode.field "length" Decode.int
|> Decode.andThen
(\len ->
case len of
1 ->
Decode.map (\a -> [ a ])
(Decode.field "1" touchDecoder)

2 ->
Decode.map2 (\a b -> [ a, b ])
(Decode.field "1" touchDecoder)
(Decode.field "2" touchDecoder)

3 ->
Decode.map3 (\a b c -> [ a, b, c ])
(Decode.field "1" touchDecoder)
(Decode.field "2" touchDecoder)
(Decode.field "3" touchDecoder)

_ ->
Decode.fail "Unexpected length"
)

-- 
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] List of all members of a union type

[Max Goldstein]

Building on Charles, how would this handle recursive union types?

-- 
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] Literature reviews repo

[Max Goldstein]

Why don't you open a PR and see what people think? :)

I'm also in favor of having a folder of sample apps to demonstrate the current 
best practice, and anything else that would be useful. 

-- 
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] Literature review of requested features

[Max Goldstein]

I'm salvaging this idea from the "moving on" thread. Basically, some 
features like audio playback, binary data, task ports, and so on have been 
commonly requested. I'd like to propose that the advocates of these 
features do some of the pre-code legwork. This is more of a literature 
review than a design document. It would serve several purposes: to give 
those clamoring for features something to do (funnel the creative energy), 
to to let them examine the feature in more depth to determine if it really 
solves their problem, and to give some guidance during implementing that 
we're talking about the same thing. It would also provide a common place to 
link when someone asks "what are task ports?".

This project would take the form of a collection of markdown documents, 
each researching a particular proposed addition and say why it would be 
useful. Each document should, for its proposed feature X:

   - Define X
   - Explain of why X is useful
   - Describe the best way(s) to do X in Elm today
   - Describe how other ML-family and JS-ecosystem languages do X, with 
   links
   - Give type signatures or syntax of a *proposed* API for X

This is work that Evan would have to do anyway. (And he might still have to 
do it anyway, since I haven't talked to him about this and he might ignore 
or nix it.)

-- 
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: Looking for a better way to use `andThen` chains (and other beginner questions)

[Max Goldstein]

>
> If you're looking for a somewhat broader background on data modeling in 
> Elm, this talk is a must-watch: Making Impossible States Impossible
>

Sorry, looks like the YouTube link got put at the top of the post. 

-- 
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: Looking for a better way to use `andThen` chains (and other beginner questions)

[Max Goldstein]

https://www.youtube.com/watch?v=IcgmSRJHu_8Instead of lists with numbered 
items, have you thought about using a dictionary 
? Something 
like this?

import Dict exposing (Dict)

type alias No = Int
type alias Game = { stars : Dict No Star, teams : Dict No Team }
type alias Team = { name : String, color : String, species : String }
type alias Star = { name : String, planets : Dict No Planet }
type alias Planet = { name : String, minerals : Int, colony : Maybe Colony }
type alias Colony = { team : No, defense : Int }

getStarPlanet : No -> No -> Game -> Result String Planet
getStarPlanet starNo planetNo {stars} =
  Dict.get starNo stars
|> Result.fromMaybe "Star not found"
|> Result.andThen (\{planets} -> Dict.get planetNo planets |> 
Result.fromMaybe "Planet not found")

It's still a little repetitive, and you need to nest a Result.fromMaybe 
inside a Result.andThen callback, but it works. (You should maybe consider 
a union type for these errors instead of strings.) 

I've also tried to anticipate that you'll have uncolonized planets, which 
will still have things like minerals, size, atmosphere, temperature, things 
like that. Some of those will also have colonies which will have a team, 
defense, buildings, colonists, and so on.

Incidentally, if you're okay fixing the number of teams at compile-time, 
you might be able to avoid the inconsistent state of a colony whose team is 
not in the team dictionary.

type TeamNo = Red | Blue
type alias Teams = { red : Team, blue : Team }
getTeam : TeamNo -> Teams -> Team
getTeam no teams =
  if no == Red then teams.red else teams.blue

If you're looking for a somewhat broader background on data modeling in 
Elm, this talk is a must-watch: Making Impossible States Impossible

-- 
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: view function to call other view function with different Msg type

[Max Goldstein]

Yes, Ian is correct.

Html.Attributes.map 
 
: 
(a -> msg) -> Attribute a -> Attribute msg

Html.map  
: (a -> 
msg) -> Html a -> Html 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Call of init function behaviour

[Max Goldstein]

init is not a function. It is a constant value. It will be evaluated 
immediately and, if you've wired things up right, referred to in main. 

If you have a message that triggers a state reset, it's not crazy to reuse the 
init value. But it sounds like it's getting used when you don't want it to be, 
so maybe you're using it somewhere other than main on accident?

If not, then you may have some page reloading issue that's not tied to init 
specifically. 

-- 
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: Post Examples of Painful Record Updates Here!

[Max Goldstein]

@art, I disagree about adding arbitrary expressions between { and |. You 
should use a let-binding for something like *Array.get (offset + i) 
arrayOfRecords |> Maybe.withDefault defaultRecord*.

I know this is supposed to be pain points, not solutions, I'm going to try 
to coalesce some of the syntax proposals that have been brought up.

*Qualified names as base records*, such as {Module.defaultOptions | ... }. 
The default options pattern makes this very useful and it does not 
encourage nesting records deeply.

*Dot-accessed records as base records*. This would allow { element.padding 
| left = "4px" }. Having records as fields of other records is especially 
useful when the subrecord type can be reused (e.g. { padding : Rect, margin 
: Rect }.

*Arbitrary expressions as base records*. Allow anything of record type. I 
disagree with this one per above.

-

*Nested getter functions*, so that *.foo.bar* is sugar for *.foo >> .bar*

*Setter functions*, perhaps with syntax *.foo=*

*Nested setter functions*, a combination of the two above, *.foo.bar=*

*Setters that take a function given the current value of the field as an 
argument.* *padding |> .right@ (\padRight -> padRight * 2)* This is 
particularly useful for mapping over lists instead of setting one value.

*-*

I wonder if we could dispense with the vertical bar update syntax entirely 
if we had nested setters. Something like

Style.defaults
  |> .padding.left = 5
  |> .margin.top = 10

The compiler should specifically optimize this case so that many chained 
updates do not create intermediate records. (A downside is that you lose 
the ability to refer to the current record in the expression for the new 
value, but that record wouldn't exist because of the optimization. So that 
would mean you can't easily map over a list that's in a record.)

-- 
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: Unit testing questions and TDD

[Max Goldstein]

I'm not aware of any really good examples of full webapp tests; maybe it's 
time to write some? That said,

Have you see strategies for effective testing 
? 
It's been updated a bit on master since the last release.

Is there a way to mock or leave out the location in this example or other 
> simplification?


You don't have to use Expect.equal, and you can write your own expectation 
functions using Expect.pass and Expect.fail. But it sounds like App.init 
needs a big record that you don't want to pass, but you want to call 
App.init. So you may need to refactor that function.

In another example, I want to check a view section that I pass the main 
> model to. I obviously don't want to set every property of the model so is 
> there another way?


Instead of

type alias Model = { foo : Foo, bar : Bar }

view : Model -> Html Msg
view { foo } = -- code that ignores bar

-- try

view : {a| foo : Foo} -> Html Msg
view { foo } = -- same code

This syntax means the view function accepts any record as long as it has 
the stated field. It can have extra fields, like Model, or not, like a test 
mock. As a bonus, this will make fuzz shrinking much more effective because 
only relevant fields will need to be shrunk.

Also, in that latter example is there an easy way to see if an html output 
> contains a particular string? 


elm-html-test  


-- 
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: Request for idioms / announcement of a possible book

[Max Goldstein]

> 1. I have a chapter on `Maybe` that treats it as a type with several 
> idioms around it. Does the chapter make sense to you more experienced Elm 
> programmers? 
>

In case you haven't heard me say it, *Maybe is a data structure*. Things 
like map and andThen make a lot of sense in that context. Now it's not a 
bad thing to look at those patterns in a simple example, before getting 
into things like JSON decoders and random generators that don't actually 
contain the value they're going to produce when you map over them. But -- 
and it sounds like this is the plan -- make sure you present it as, "these 
are examples of patterns that we'll see recur for more complex types", not 
"this is what you need to know to understand Maybe".

-- 
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: Decoder for Recursive Type

[Max Goldstein]

Try using Json.Decode.andThen to decode just the tag, and then with that 
information decide which other decode you want. You will be able to use 
decoders recursively this way because the self-reference will be inside a 
function.

-- 
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: Divide by zero?

[Max Goldstein]

I don't think anyone likes that 2 // 0  == 0, but no one has a better idea.

I don't like the idea of the standard libraries writing to the console in a 
way you can't turn off, but a console.warn statement might allow the bug to 
be caught in development. Although it would need a source map to be useful, 
so that's no longer an easy fix.

-- 
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] Is type inference in Elm fully decideable?

[Max Goldstein]

Records can still be useful in union types if you have more than a few 
fields, or multiple fields of the same type. Often you write a function 
that updates a record by looking at a select few fields and it never needs 
to know about others. Occasionally you will have multiple records of this 
sort. So you can pipe the different records in different cases to the same 
function to handle that part of the update, and then other logic to handle 
whatever else needs to happen.

-- 
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] Is type inference in Elm fully decideable?

[Max Goldstein]

I honestly don't know if your code "should" typecheck or not, but if it 
did, it wouldn't do anything more than what you already have. The function 
you pass would only have access to the rect field. I think this code would 
be simpler, and no less expressive, if the function argument was Rectangle 
-> a. The fact that it's wrapped with some arbitrary fields is mixing 
concerns.

I anyone using extensible records much?


I don't think people are using extensible record type aliases much. The { a 
| fieldICareAbout : Int } -> Thing pattern is useful, though. (For example, 
to call a view helper with the whole model but guarantee that it can't look 
at certain fields.)

Nesting these field definitions makes the code a lot less readable then 
just listing the records exactly. Try to make your type definitions more 
explicit, and use your functions signatures to abstract away some of the 
details.

State.mapPosition : (Rectangle -> a) -> State -> Maybe a
State.updatePosition : (Rectangle -> Rectangle) -> State -> State

-- 
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] Starting Elm, need help understanding -> syntax

[Max Goldstein]

Yes, exactly, functions always take exactly one argument and return exactly one 
result. 

A few caveats, though. Either that argument or result can be a tuple or record 
that holds multiple values. And the result may itself be a function, hence 
currying.

-- 
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: Giving elm-vim some love

[Max Goldstein]

I would love to see better vim support, but I don't have the vimscript 
knowledge either to make it happen.

-- 
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] Architecture Pattern: Separating Model and ViewState

[Max Goldstein]

No, it's not really an interest of mine anymore. In the year since this post 
I've refocused onto elm-test and its dependencies. I never got much evidence on 
whether this is a worthwhile pattern or not.

-- 
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: Svg without getBBox?

[Max Goldstein]

Try it with ports. If that's helpful, it could possibly be added to the DOM 
package: https://github.com/elm-lang/dom

-- 
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] Modeling units of measure with phantom types

[Max Goldstein]

>
> I think the quantities you meant to compare are torque and energy (both of 
> which have units of force*length).
>

Yup, sorry.
 

> Torque, although sometimes expressed as a scalar or a vector, is actually 
> best represented as a bivector (two components per spatial dimension in 
> whatever system we are looking at).
>

How so? I know that the force and length are orthogonal, but that would 
still be one component per spatial dimension. 

-- 
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] Modeling units of measure with phantom types

[Max Goldstein]

As John Kelly pointed out to me in another thread, there's a trick called a 
"phantom type" that's possible in Elm. It's where a union type has a type 
variable that's not used on the right side. If you don't expose the 
constructor, you can use the type to only allow values that have come 
through other functions. Here's an example:

-- the Phantom Type
type Measurement a
= M Float

-- "dummy" types
type Length = Length
type Width = Width
type Area = Area

add : Measurement a -> Measurement a -> Measurement a
add (M a) (M b) =
M (a + b)

multiply : Measurement Length -> Measurement Width -> Measurement Area
multiply (M a) (M b) =
M (a * b)


I've been thinking about how to make these guarantees, there was a recent 
ThoughtBots post on it, and I'm not sure anyone has seen this before. 
Building out a whole system of measurement this way seems really tedious, 
but for a smaller and more specific problem, it might be a valuable 
technique to know about.

Note that this only works if it's impossible to create a polymorphic type, 
e.g. *Measurement a*, because that will get unified with whatever type is 
expected by the annotation. If every Measurement value is concrete, it 
can't be passed in the wrong place.

As I've been thinking about this, I've seen multiple orthogonal pieces of 
information that we sometimes sloppily roll up into the type:

   - The *representation*, the storage of bits in memory, such as IEEE 
   floating point or 64-bit integer.
   - The *dimension*, in the physics sense, such as length*mass.
   - The *interpretation*. Is it length or width or height? Is length*mass 
   torque or momentum?
   - The *units*, such as meter*kilograms.

When dealing with a discrete case -- the classic example is not mixing up 
rows and columns in a grid/table -- we need the representation and the 
interpretation (rows or columns), but units and dimensions seem not to 
apply. Similarly, if we want to distinguish between strings (URLs, IDs, 
escaped and unescaped HTML, and so on), we seem to want the same things.

It might be interesting to have a wrapped String library that would perform 
the typical operations on strings with type-level identifiers, so when you 
require an ID (aliased to WrapedString IDType) you can only get one that's 
been through your validator. Or you could build URL-specific abstractions 
like *Url.join : Url -> List String -> Url*.

So, just a neat idea not everyone is aware of, hopefully someone finds it 
interesting or useful.

-- 
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: [early prototype] Elm-Data: a server loading code generator

[Max Goldstein]

Rupert,

I've been doing something very similar and it is proving very worthwhile, 
> so I would encourage you to pursue this.
>

Thanks (:
 

> For Elm, I output one (big) file called Model.elm, that gives me the data 
> model mapped onto Elm, and encoders and decoders for it. Then for each 
> grouping of endpoints (each service implemented in Java provides the 
> grouping) I generate one Elm file that implements the Http logic for the 
> service.
>

I've come to the same file structure, because JSON API allows for included 
resources. For example, articles can include their author an vice versa, 
which means those decoders have to be defined in a common file. I'm trying 
to wrap them in one module per resource, though.
 

> Each service requires a set of callback functions to be passed in - one 
> for each endpoint, plus one for each endpoint when it results in an error, 
> plus a default error handler for cases when the endpoint specific error 
> handler doesn't process the error.
>

I'm taking a different approach. I'm using the RemoteData library to track 
the (possibly error) state of each ID'd resource, so if there's an error, 
it's just stored. You won't know until you try to get that ID and you wind 
up with the Failure case of the RemoteData type. I'm also planning on 
having an error log that's written to in opaque events and exposed 
read-only through an API. 
 

> Another possibility would be to use an API description meta-data such as 
> Swagger. A Swagger codegen for Elm could easily output something useable.
>

I've used both Swagger and JSON API before, and I'll say that JSON API has 
almost no downsides but Swagger is much more an engineering tradeoff. An 
Elm swagger codegen is something that should exist but I'm taking a 
different approach.
 

> I think Elm will be well suited to writing code generators - in a manner 
> similar to how it 'codegens' Html. You can design a set of functions for 
> constructing the component parts of the output language you are working 
> with. Elm is good for doing complex AST manipulation and it can be set up 
> to guarantee correctly formed output. Code generation of Elm in Elm will be 
> a mind bender.
>

I'm hesitant to rely on server-side rendering Elm when it's not officially 
supported (I say that as the co-author of Elm test and Richard's shell 
utility for it does exactly that, so maybe I'm not being consistent). I'm 
also a little less concerned with well-formed output, since elm-format can 
smooth over a lot of bumps in a hacked-together system. I'm more 
comfortable in Ruby but Noah Hall has written some JSON tools in Python 
that I'd like to build on if it makes sense to do so (he's left NRI so 
maybe not?).

Thanks again for your encouragement! 

-- 
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] [early prototype] Elm-Data: a server loading code generator

[Max Goldstein]

Hi everyone,

I've been thinking for several months now about a useful abstraction for 
loading data from the server. It's painful to work with HTTP and JSON 
directly because you lack: caching, logic to not send a request already in 
flight again, error handling, and so on.

I came upon the idea that the client (that's you) will provide a type alias 
for each resource's attributes (and perhaps other crucial information), and 
I could generate code that would retrieve resources of those types. 
Generating code also allows the tool to create JSON encoders and decoders, 
a common pain point.

Each resource gets its own module with a standard set of functions. I've 
split out loading a resource (making a request if one is necessary) from 
getting a resource (obtaining it immediately from information available, if 
possible). Keeping track of what's been loaded requires an opaque Store 
model and StoreUpdate message.

I don't have this anywhere near usable yet; I haven't started working on 
the generating part of this at all. I first want to write the code I want 
to be generated by hand, and get feedback on that. Does this approach seem 
okay? Are there any problems you can envision? What you be good to work on 
next?

Have a look here:

https://github.com/mgold/elm-data/tree/master

-- 
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: Dealing with invalid state transitions

[Max Goldstein]

You could model your data using the RemoteData library on elm-package, and use 
the map function to apply changes only to loaded data. 

-- 
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: Guidance for using "type alias" vs. single-constructor union types

[Max Goldstein]

I did not know F# supported that, which is good news. It means that there's 
feasible, theoretically sound way of solving this problem. In Elm, it would 
require making the mathematical operations aware of units and therefore 
even more "special" that the *number* not-a-typeclass. But units still feel 
like the right abstraction for this problem, especially if strings could be 
marked as having a unit (never mix up usernames and passowrds again!), so 
I'd much rather consider adding units of measure to the language *later* than 
some weird, halfbaked idea *now.*

-- 
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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

[Max Goldstein]

The function String -> a is called eval, and it's not coming to Elm because 
it would break all kinds of type guarantees. You can implement functions 
from String to a specific concrete type, although that type will have to 
have some notion of failure or emptiness if it's not wrapped in a Maybe or 
a Result. Nick gives you an example of how to do that; more simply you can 
just do a case analysis of all the strings you want (or if statements with 
regexes...).

But if at all possible, don't use string identifiers at all. Sometimes it 
can't be helped (usually JS of JSON interop) but especially if all your 
union type's tags are not functions, just pass those around within Elm.

-- 
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: Guidance for using "type alias" vs. single-constructor union types

[Max Goldstein]

It's tempting to want something like

type clone Name = String
type clone Currency = Int
type alias Accounts = Dict Name Currency

These hypothetical "type clones" would act like their base type until you 
tried to use them in nonsensical ways. But trying to define their behavior 
is tricky.

The Haskell community has apparently tried this under the name "subtypes" 
and concluded they are very difficult to implement and have other 
undesirable properties, but I couldn't find anything formal.

More concretely, say one defines type clones for Length and Width in the 
hope of avoiding accidentally adding them, which would make no sense. But 
we'd want to allow multiplying them to obtain Area. The only language I 
know that handles this well is Frink , which tracks 
physical units through all computations.

All that said, it may be possible to define this well enough and simply 
enough to warrant further explanation. For example, in any correct program 
with type clones, one should be able to replace any clone with an alias and 
have identical code generated. If there's interest, I can start a new 
thread exploring these type clones further.

-- 
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: [Suggestion] Type values and simplifying the language still

[Max Goldstein]

* rereads * Janis, you are incredibly good at telling people that they're 
wrong.

Ah, I got caught up in the third paragraph about the native representation, 
and thought that those were Elm records, not JavaScript objects.

Also, the phrase "No type value has more than one value", for all of its 
bold redness, reads perilously close to "no type has more than one tag".

However, I think there's some value in pointing out the legitimacy of tags 
that have no arguments: under the proposal, union tags would still have 
either one argument or none, just not more than one. One of the more 
confusing parts of union types is that different tags can be functions of 
different arities or non-function values, depending on how they are 
defined. If we wanted to eliminate this confusion, we could require an 
arity of exactly one, and tags like Up and Down would need to be Up () and 
Down ().

But that's needlessly confusing, so limiting the number of tags to one 
seems more like a restriction than a simplification. Yes, you've found a 
way to make a strictly smaller language without diminishing expressive 
power. The same is true for requiring f x y = ... to be written as f = \ x 
y -> ... but no one is advocating for that.

So, I'm sorry I misunderstood your proposal and lectured on things you may 
well have known about. And for what it's worth, I've used two-argument 
constructors before, and I've advocated for records instead of positional 
arguments before. I think this is a place where we can allow some freedom 
to the programmer.

-- 
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: [Suggestion] Type values and simplifying the language still

[Max Goldstein]

First, I appreciate that this proposal is being made in the spirit of Elm: 
seeking to simplify the language, with reference to existing usage (red 
sentence in the first post), and trying to solve an existing problem 
(serialization of union types). It's clear that Maxime wants to learn and 
improve the language. Thank you.

So let's look at how union types are used, what jobs they are hired to do, 
if you will. You've noticed in core that union types with one tag are used 
to hide things. Sometimes that's as an opaque type: there is one tag that's 
not exposed, and is pattern-matched easily, and the data the tag holds can 
change even in a patch release (example here 
). 
Core also contains a rare pattern of, say *type Task x a = Task* where the 
*Task* value defined is not actually used anywhere because it's actually a 
native implementation. Serializing arbitrary union types will have to 
account for this case.

A more realistic use of union types is as a finite set of labels, even if 
these labels don't carry any information along with them. For example:

type Direction = Up | Down | Left | Right

>From this we derive pattern matches with static 
(compile-time) exhaustiveness checking, which is a huge improvement in 
reliability and refactorability over "stringly typed" conventions (instead 
of strongly typed, get it?) that you'll see in JavaScript and the like. 
Replacing the Direction type with a record including a string removes this 
huge improvement.

Adding data to these tags allows for the classic use case of data that only 
makes sense in certain contexts. I remember working with a C++ graphics 
library where certain fields of structs were only defined if an enum was 
set to a particular value. But this isn't really a separate use case from 
labels without data, since you can freely mix within a type. The RemoteData 
type 
does
 
this to great effect.

More theoretically, union types and records are not the same; they are 
actually duals. Union types are referred to as "sum types" and records (and 
tuples) are "product types". Here's the reasoning: consider two types, *a* 
and *b*. Let's denote the number of values of type *a* as |a|, and 
similarly |b|. If we construct the sum type *Result a b* then there are |a| 
values for the Err case and |b| values for the Ok case. So |Result a b| = 
|a| + |b|, hence sum types. For the pair (a, b) we can pick any *a* and any 
*b* so |(a,b)| = |a|*|b|, hence produce types.

If you want to produce (create) a value of sum type, such as *Result a b*, 
you can pick either case to work with. But when you consume (inspect) a 
value of that type, you must be prepared to handle all cases. For product 
types it is reversed: to produce a value of type (a,b) you must have both 
an *a* and a *b*, but when you consume such a value, you can pick out the 
one you want.

So, while I appreciate the gesture, I don't think this will work.

-- 
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: pattern match sum type inside a record inside a Maybe

[Max Goldstein]

What about:

case Dict.get id model.displayables |> Maybe.map .view of

-- 
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: Type Alias Question

[Max Goldstein]

Maybe this will help: all record types already exist when the type checker 
starts. Even though there are no terms of that type, you could write x = { 
bar = "foo" } and that value will be assigned the type { bar : String }, 
notice the equals in the value and the colon in the type.

So, type aliasing a record is just like type aliasing an Int: It doesn't 
increase the number of types available, it just adds a new name (alias) for 
an existing type.

Meanwhile the type keyword, no alias, creates a union type, which you say 
you understand. Point being that a union type is a new type, which could 
not be written before it was defined. (Record constructors are useful 
shorthand, but if hypothetically the language didn't provide them, there 
wouldn't be any programs that would become unwritable because of that 
change.

-- 
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: Type specific messages

[Max Goldstein]

This sounds fine to me. It's certainly a lot better than:

type Msg
  = SwitchCowToExpandedReadOnly
  | SwitchCowToCollapsedReadOnly
  | SwitchCowToReadWrite
  | SwitchChickenToCollapsedReadOnly
  | ...

I think it largely hinges on your ability to separate orthogonal behavior 
as separate types. If Animal and EditMode make sense as types, and you can 
write useful functions that only take one, then that's what you should do. 
If animals and edit modes and actions have interwoven dependencies, things 
are of course trickier.

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Max Goldstein]

I think it's pretty obvious at this point that this is another classic 
"internet argument" in which nothing is really resolved and no one changes 
their minds. That's because there isn't single concrete example or use-case 
that definitively proves one side is superior.

In which case, things default to the status quo. Unless you can come up 
with an incredibly amazing example that highlights a huge difference in 
favor of *where*, the language is not going to change. Yes, Elm has made 
breaking changes but they have often made the language *smaller*. I've read 
JS devs who are frustrated not so much by breaking changes, but by breaking 
changes *for no reason*. Benefits from this change are marginal and 
tradeoff-laden at best. Evan has said 
 that one should avoid 
refactors that lead to "You know that code that was totally fine? It is 
different now," and that's what a let-to-where switch would look like. 

There is nothing in this discussion that will make Elm a substantially 
better language, so it's a pity that we're spending all this time on it. 
Evan isn't worrying about syntax anymore; he's making the parser faster and 
the package installer more robust. I know the guy who is working to 
implement Array in Elm so that it's less buggy and easier to maintain. 
There are people who produce the Elm-Town podcast, and they invited the 
author of a library on to talk about it and how it ported Haskell patterns 
to idiomatic Elm. I personally worked on fuzz testing (i.e. property-based 
testing similar to QuickCheck) for elm-test, which is powered by a random 
number generator that I ported to Elm and have submitted a patch for core. 
If your Haskell experience has led you to parsers, maybe you could help out 
elm-format. Or you could livestream yourself working on a program and 
invite the community to watch, comment, and learn. As Evan has advised us, 
"choose not to block". You can give back to the community *right now* by 
building something cool instead of arguing on the internet.

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Max Goldstein]

>
> Let/in leads to a sort of vertigal zig zagging as you need to jump to the 
> bottom then scan backwards for the supporting information. 


This seems subjective and somewhat dependent on code style. Do you have an 
example where sequentially reading the bindings causes confusion ("why 
would you need to compute that?") not resolved until the returned value? 
Otherwise this fails to be concrete and actionable.
 

> The pattern Joey suggests seems good, the counter argument though is that 
> you need to check the 'in' to know if that pattern is being used so you end 
> up doing the zig zag read anyway.


Coding convention around the name "result" or similar would eliminate that. 

The argument regarding being able to use let/in with anonymous functions 
> seems irrelevant as it's use would be a clear sign that the function should 
> be broken out into a named function.
>

Janis gives a good example of when you'd want a local binding in an 
anonymous function here 

. 

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Max Goldstein]

Those in favor of where clauses, would you mind summarizing any arguments 
from the thread that do not rely on personal preference but concrete 
improvements to code readability or maintainability, in a way not achieved 
by Joey's suggestion? We are looking for code examples in which 
where-clauses either let you do something let-clauses don't, or are visibly 
superior to them.

I'll put forward Janis's concern that where clauses don't work as well in 
anonymous functions, eg.

List.indexedMap (\i x -> let bar = f x.foo in g i bar) aList

(I'm not entirely sure why this wouldn't work with where-clauses, but Janis 
knows his stuff.)

Also, have where-clauses been requested by anyone who does not know 
Haskell? I think let-clauses are much more natural coming from imperative 
languages, and Elm's target audience is JS devs, not Haskell devs. This 
discussion seems to be "features for feature's sake" to me, rather than 
"features that are a solution to a problem". My question is, what is the 
problem that where-clauses solve when we have let-clauses? How do they 
solve the problem of local constants in a way superior -- by more than mere 
personal preference -- to let-clauses?

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Max Goldstein]

>
> Task.succeed () |> Task.andThen \_ -> do hard stuff
>

Sorry, that should be Task.map not Task.andThen. 

-- 
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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[Max Goldstein]

Regarding the pain of wiring up a subscription port, have you seen Task.perform 
? It 
allows you to do async work using no ports other than The Elm Architecture 
itself. 

As for doing pure but computationally intensive work in a Task, you can do it 
in Elm:

Task.succeed () |> Task.andThen \_ -> do hard stuff

This won't work for inner render loops, and the asynchronous Elm will still be 
slower than JS, but it may be useful in some circumstances.

-- 
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: Our little, failed Elm 0.18 deployment

[Max Goldstein]

If you have a polyfill to fix a 17 -> 18 regression, you should make a pull 
request to core, or at least write up a blog post explaining the problem and 
solution. 

-- 
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: Why is "port" forbidden as field name inside record?

[Max Goldstein]

This restriction is annoying, but it's easy to relax later (from an API 
perspective, maybe not an implementation one). 

-- 
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] Formating numbers

[Max Goldstein]

You should go for it! Here's a guide I wrote on publishing a package: 
https://medium.com/@Max_Goldstein/how-to-publish-an-elm-package-3053b771e545?source=linkShare-a81ca980bdb1-1481936793

And here is a JS library that does formatting, which you can use for 
inspiration: https://github.com/d3/d3-format

-- 
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 to use Dict.empty?

[Max Goldstein]

If you can isolate an sscce  of the bad error message, 
you can report it to the catalog 
.

-- 
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: Documentation storage : IN or OUT ?

[Max Goldstein]

You're going to be more specific about what concerns you about the current 
format. The Elm community likes to work together towards solutions, not get 
into debates. To that end, the tooling and conventions create a 
multi-layered system of documentation:

As in any language, *code comments* are used to document *individual lines 
of code* whose meaning is not obvious.

*Declaration comments* with the {-| prefix are used to document *public 
values and types*. (A "value" is a function or a definition.) These work in 
concert with the type annotation. Because the comment and annotation are 
displayed together in the rendered docs, they are written together in code.

The *module comment* at the top of the *file/module* gives information 
about the module: why it exists as a logical grouping of code. This comment 
also includes @docs declarations to define the order that public functions 
are documented. They are usually separated by headers (it's just markdown) 
and each section may also include a comment. Elm encourages library authors 
to use these features so that their module docs are sensible when read top 
to bottom. There is also a way to preview docs 
 prior to publication.

The *README* for each *package* includes information about what the package 
does, how to start using it, and what to look for in the more detailed 
module docs. They may also include instructions for filing bugs or 
upgrading from previous versions of the package or language.

Finally *guides and blog posts* will go into depth and examples on how to 
accomplish a* useful unit of work*, such as JSON decoding or refactoring a 
union type. These may focus on a module from the core library, one or more 
third-party libraries working together, or a language feature.

You will notice that READMEs and guides are not source code files, but are 
valuable parts of the hierarchical documentation system.

-- 
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] How to use Dict.empty?

[Max Goldstein]

It would be helpful if you showed us more context, including the definitions of 
your record type aliases.

-- 
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] `Case of` branches grouping

[Max Goldstein]

In addition to the underscore pattern (meh - makes it easy to forget about a 
case added later) and refactoring types, I can also recommend extracting a 
function. You still have to have n cases but each of them will be short. 

-- 
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: fold function argument order

[Max Goldstein]

Fold takes arguments in the same order as update: the element and then the 
accumulator. 

Don't trust partial application of infix ops unless you know they are 
commutative. Write a lambda instead. 

-- 
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] Using Elm with JSON when you do not know the names and types of the properties at compile time

[Max Goldstein]

You know about Json.Decode.andThen, right? It lets you chain callbacks that 
decode the JSON based on previous decoding passes. 

-- 
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: Make `+12` mean 12, not `+ 12`

[Max Goldstein]

>From the title and first paragraph I thought you were proposing a language 
>change. But it looks like you're just talking about String.toInt. If that's 
>correct, it seems reasonable to allow this. (Perhaps hex as well?)

-- 
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: One month with Elm, two questions

[Max Goldstein]

Oops, that second annotation should be

viewHelper : { a | name : String } -> Html 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: One month with Elm, two questions

[Max Goldstein]

I see now. You want to see a UI widget in many possible states for the 
purposes of seeing a visual regression. (By "widget", I mean some piece of 
HTML generated by a function, not the loaded word "component", which 
usually implies state. Although it could be either.) Without saying too 
much, I know there is some programmatic HTML-based testing in the pipeline 
but actually seeing the rendered output would be a nice complement to that.

If all you want to do is generate a random value of the Model type, you 
should be fine with Random, not fuzzers. All of the map functions for 
fuzzers have versions in the core Random library, and I'd be happy to go 
into more detail here if you need it.

The other possibility is to randomly generate many Msg values, and run 
update on them. This has the potential benefit of testing the update 
function, and avoiding some weird mode state that update would never 
produce (though as much as possible such states should be made 
unrepresentable).

But back to fuzzers: a fuzzer is just a random number generator plus a way 
to shrink the value generated. There *might* be value in shrinking those UI 
widget examples. Imagine devcards, except when you see a visual regression, 
you can hit a button to generate a model that is in some way "smaller" than 
the previous one. You can keep doing this (and rejecting changes that "fix" 
the problem) until you get to a minimal reproduction of the error. This 
would likely give insight into the root cause, and ideally, the example can 
be saved as a regression test.

This has an impact on how I was planning to expose fuzzers. I think for 
this use case, you'd want to take a fuzzer and say, "give me a random 
value, and a way to say that it does or does not reproduce an error." It 
would also have an impact on how view functions are written. It's common to 
write

viewHelper : Model -> Html Msg

indicating that the function consumes the entire model, which could be a 
very large record. If you wrote instead

viewHelper : { a | name : String }

this indicates that any record with a name field of type string is 
acceptable. It will accept a larger record, such as model, but also just 
{name : "Steve"}. This means shrinking can target the fields the view is 
using, and not the ones it is ignoring, to produce a much better result. It 
also means that you'd need to produce a special fuzzer for this function, 
and expose it from its module (typically the View module hides its helpers).

So, I might be getting ahead of myself here. If it's worthwhile to be able 
to shrink models that cause visual glitches, than this is a road we can 
pursue further. If not, and even if it is but in the short term, I think 
you will be able to randomly generate a model with the random libraries, 
not fuzzers.

-- 
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: One month with Elm, two questions

[Max Goldstein]

Hi Frankie, thanks for trying Elm, glad you like it!
 

> But why isn't the ability to create fuzzy records/data available outside 
> that package? What I usually do is to stub out the UI given a certain model 
> type. Being able to call fuzzy generators in my Main namespace to populate 
> the model makes it easier iterate on an initial design and can still be 
> very useful to run the application in 'mock mode'. Any chance we can see 
> the generators extracted in their own library?


I'm the co-author of elm-test. We're going to add a way to run fuzzers 
outside of elm-test  
but that's probably not what you want. The fuzzers are designed to produce 
edge cases, and most of the work that goes into them is around being able 
to shrink values into smaller forms to obtain a minimal test failure. Test 
data is fundamentally different from mocked data, especially if you want to 
be able to do UI design or take screenshots (i.e. for documenting your UI). 
I think you may want random-extra 
 which 
includes a lot of similar helper functions, though it's still fairly 
primitive.

Long-term, I would love for someone to port part of faker 
 to Elm.

-- 
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: Pattern matching using existing bound variables

[Max Goldstein]

That's exactly Maybe.withDefault "something", which is a great example of 
partial application. 

-- 
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 to Modularize Big Files?

[Max Goldstein]

Yes, that is exactly the file structure I had in mind. Let me know if you run 
into trouble. 

If you extract another module, it should import Common and be imported by Main, 
just like View. Because of this 1-n-1 structure, I think of this as a diamond. 

-- 
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] Cmd.andThen

[Max Goldstein]

Austin, you're exactly correct. Cmd is meant to be passed out to the runtime, 
that's it. 

The reason Http allows you to skip Task is for learnability. You can make a 
simple request without learning what a Task is. But we shouldn't be hobbled by 
that when we want to compose different types of effects. 

-- 
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] Cmd.andThen

[Max Goldstein]

Hmm. I want to say it's an issue with the library, but fixing it would 
involve changing a fair amount of code and using the low level Websocket 
API.

-- 
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] Ducked Inference

[Max Goldstein]

It's an interesting perspective, but Matz is doing what's right for ruby. 
Ruby is dynamically typed; Elm is statically typed. Ruby is mature and has 
a lot of users counting on stability; Elm is pre-1.0 and has a smaller, 
more adventurous user base. Granted we have upgrade guides and elm-format 
to help with new releases, but it's still somewhat painful. But I'm hopeful 
because 0.19 is focusing mostly on elm-package and not the language itself 
(last I heard) which may mean the big breaking changes are mostly behind us.

That said, Elm likes DRY but not to a fault. It's possible to refactor code 
in Ruby and, if not Elm, Haskell, that is twice and short and three times 
as cryptic. Elm's annotations are helpful when programming, enforced by the 
compiler, and used in documentation. It reflects the curried nature of Elm 
functions. I think type annotations are great, and so do most Elm users. 
They should stay exactly how they are, except perhaps for tooling to help 
you fill them 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Cmd.andThen

[Max Goldstein]

Http has an escape hatch to get a Task. Other libraries should do the same. 

Cmd is deliberately simple, with the hard work being done in Task. 

-- 
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: ANN: style-elements v2 published

[Max Goldstein]

Hi Matt! I looked at the documentation and these are my thoughts.


   - The last example has the Title line twice. Copypasta?
   - It looks like this only works well if Style is imported as a (..) 
   import. I think you make a good case for this usually-discouraged feature. 
   However, I think best practice would be to keep the stylesheet definitions 
   in their own module with no other (..) imports, and expose only the 
   rendered stylesheet and Class type. If you agree, maybe add this to the 
   README?
   - You should document the types defined at the top of the documentation. 
   What the heck do these represent? Maybe there's a better name for Model 
   since that's normally something the application author defines as part of 
   TEA (The Elm Architecture).
   - Maybe it would be helpful to see the rendered CSS for the definitions 
   in the README?

Overall, great work!

-- 
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: Random.list

[Max Goldstein]

Oh, and I'm obliged to say: this function will never terminate if you pass 
it the wrong predicate, so be careful about that!

"Wrong" might mean unsatisfiable (or always satisfied, depending on how you 
want it to work), or not satisfied by any element generated, for example, 
(\n -> n > 100) for (Random.int 0 100).

-- 
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: Random.list

[Max Goldstein]

You can do this, but you have to define something that *should* be defined 
for you (and is by random-extra and elm-random-pcg): Random.constant.

import Random

constant x = Random.map (always x) Random.bool

listUntil : Random.Generator a -> (a -> Bool) -> Random.Generator (List a)
listUntil element predicate =
  element |> Random.andThen (\elem ->
if predicate elem then
  constant [elem] -- or []
else
  Random.map (\tail -> elem :: tail) (listUntil element predicate)
  
  )

You can play with the implementation depending on whether or not you want 
the last element and whether the predicate should return True or False.

-- 
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] Whither Rationals?

[Max Goldstein]

What problem are you trying to solve that you can't do with Floats?

-- 
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 to use Navigation library

[Max Goldstein]

One of the main benefits of routing/navigation is that a user can bookmark 
or send a URL to someone else, and the website loads up in the correct 
state. Option number 1 seems like it would handle this case naturally. I'm 
not sure how it would work for option number 2.

-- 
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] What Elm needs to move forward

[Max Goldstein]

Regarding simple type systems, experiments, and language features for 
library authors -- finding the right abstraction is hard. In 0.18, there's 
an HTTP abstraction, so you can run requests in parallel (but not arbitrary 
effects: racing a file read and a file delete is a bad idea!). Then there's 
an abstraction for arbitrary effects, Task, which can be chained with 
andThen. Finally there's Cmd which is more restricted and represents the 
final unit of work to be done by the runtime. The most sophisticated thing 
you can do is map over its return value (not the work itself), usually to 
wrap it so you can identify what happened. But importantly, the preferred 
way to run an HTTP request is to turn it directly into a Cmd. You can turn 
it into a Task, and a Task into a Cmd, but that's an escape hatch for 
experts.

Back to the larger goals: I think it's fair to say that we want to be able 
to write webapps/SPAs in Elm. That is, we want it to replace Angular, 
Ember, React+Flux, etc.

Evan has said that he wants to wrap the "web platform", and as a result of 
that, we have access to most web primitives but not nice framework 
abstractions. We have virtual DOM but resuable UI components. We have HTTP 
but no models (like Ember Data or Rails, not the Elm model that holds all 
your state). That is, Elm is really good at computation and the ability 
extract functions is incredibly useful. But things stop working when you 
look at the inputs and outputs of a webapp, and they are primarily HTML and 
HTTP (also the current time, randomness, and a few others).

So I think what we need is the ability to abstract over HTTP with models, 
and to abstract over HTML with reusable components. The former seems really 
hard. The former seems hard only if you need to hold state in your 
component; maybe we'd have some luck trying to make "components" that are 
actually just functions?

-- 
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] Elm experience - proposal for additions to List and Random core libraries

[Max Goldstein]

I think List.get has been avoided since it seems imperative, and requires 
the use of Maybes. If you expect an item to be there, use a different data 
structure, or use an Array which has better time complexity.

I agree completely on Random.constant.

Random.permutation is available in random-extra 

 
as shuffle. It takes O(n log n) time because it converts it to an array 
first. But it's certainly possible the author of the function -- me -- made 
a mistake.

-- 
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] Unpublishing a package

[Max Goldstein]

What about a way to hide packages during search (unless you ask for them), but 
still be available to download?

-- 
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: Proposal: Shorter qualified imports

[Max Goldstein]

It's tedious to write, and slightly tedious to read, but Elm thinks that 
*tedium 
is better than mystery* and anything implicit or shortcut-like would be 
mysterious. Elm also doesn't like having multiple ways to do things.

-- 
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] Suggested edit to Json.Decode docs

[Max Goldstein]

That's probably an oversight. Yes, docs for core should not reference a 
third-party library. 

-- 
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] 0.18 Below the Hood

[Max Goldstein]

My impression is that it's a Haskell extension that's very commonly used. In 
the process of upgrading, I uncommented some signatures only for the compiler 
to tell me that they are incorrect, so this feature has been useful already. 

Oh, and almost forgot: flipping the argument order for andThen, and the removal 
of backticks. It makes |> chains much nicer. 

-- 
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] 0.18 Below the Hood

[Max Goldstein]

I'm personally looking forward to three longstanding bugs being fixed. First, 
recursive definitions like x = x are caught by the compiler. Second, a bug 
caching compiled forms of modules has been resolved, forcing a rebuild when 
necessary. Finally, let-bound values can be given type annotations that 
reference type variables from the top level. This makes certain code much more 
readable. 

0.17 was a groundbreaking release. 0.18 is a much more polished one. It's true 
that we don't have server-side rendering yet, and the debugger UI needs a few 
tweaks, but this is forward progress and I'm happy for it. 

-- 
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: Why Range syntax got removed in favor of List.range

[Max Goldstein]

If someone was so tenuously commuted to Elm that this syntax removal drives 
them away, oh well.

Yes, the Elm language is getting smaller. That's been true for a few releases 
now. Evan is trying to remove hurdles for new users (because we need a lot of 
new users!), not preserve legacy code (Elm is young and inherently easy to 
refactor). 

-- 
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] port Maybe field behavior

[Max Goldstein]

I also think this is reasonable, although it's possible there's something 
I'm missing.

-- 
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] A spawned task cannot produce a result?

[Max Goldstein]

So, I'm mostly speculating here, but could you use Task.andThen to get the ID, 
which you then use to kill the task that updates the security token, if 
necessary?

-- 
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: Is Elm really wrong?

[Max Goldstein]

Okay, fair enough, we shouldn't aspire to piss off anyone. Also, I apologize 
for speaking for everyone instead of just me. 

What I meant was, Elm needs to choose differently from Haskell, at least some 
of the time, or else there wouldn't be a reason for it to exist. And, what 
seems weak and limited to one person can seem friendly and easy-to-start-using 
to others. 

-- 
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: Is Elm really wrong?

[Max Goldstein]

"We" means the Elm community. 

I did not know that records are not comparable. I suppose they aren't useful as 
Dict keys, and we have sortBy .field for sorting lists of them. 

-- 
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 Elm really wrong?

[Max Goldstein]

More coherent post here... first, don't freak out, this is from April. I 
think I've seen it before.

One argument that's at least worth debating is:

There is no map function, but there are List.map, Dict.map, Array.map among 
> others, and none of them are related to one another. This is not only 
> annoying, but also breaks the abstract data-type guarantee: our call-sites 
> are now tightly coupled to our implementation details. If I decide to 
> change from a List a to an Array a for efficiency reasons, my whole 
> codebase needs to know about it.


I think this is wanting to have it both ways: I want the compiler to know 
what data type this is, but I don't want my codebase to know. And his 
justification for this is "the abstract data-type guarantee", as if that's 
handed down in a sophomore CS course. And it's true, Python has a map 
function and Ruby enumerables have a map method. But that contributes to 
the, well, abstractness of the code. Elm's module naming schemes mean you 
get noun and verb together, rather than "map over this mappable thing". 
It's much like a lot of haskell code: "yes I know it's a monad but I have 
no idea if you're doing IO, inserting into a singleton list, or creating a 
constant random number generator -- and I need to know that to figure out 
if this code does what I want it to do!" But in Elm, if you want to change 
from List to Array, change the type defintion or annotation and the 
compiler will tell you where everything else needs to change. Sure, it's 
tedious, but I'd rather have a boring and straightforward path forward then 
none at all.

Finally, the fact that we're pissing off Haskellers is good. We're not 
making the language for them. We're making it for JS developers and those 
new to programming.

-- 
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 Elm really wrong?

[Max Goldstein]

+1 to Peter's post, and relatedly: when is a 7-element tuple more useful than a 
record with named fields? For any purpose, not just comparison?

-- 
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] How do I subscribe to an event at a fixed point in time?

[Max Goldstein]

Could you run Time.now andThen calculate the amount of time left until expiry, 
then Process.sleep until then?

-- 
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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Max Goldstein]

I would love more Ruby-like names across the board, except for the presence of 
aliases, but Elm grew out of Haskell so it carries some of that history. 

It really comes down to what Evan wants to do. People come to Elm from many 
languages, and everyone has preferences. Changing things makes upgrading 
harder, invalidates old code, and gives the larger community the impression 
that Elm is not stable. 

-- 
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: Naming functions

[Max Goldstein]

If you're going to refer to items by ID a lot, you should probably use a 
dictionary keyed on ID. Assuming items is a record with an id field:

{ model |
items = model.items |> Dict.insert updatedItem.id updatedItem }

-- 
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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Max Goldstein]

Normally I'm opposed to syntax or name changes. But I think this or some 
variation is a good idea. (Maybe foldl becomes fold, since it's usually the one 
you want.)

That said, it's all subject to Evan's approval. 

-- 
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] why no more primes on 0.18 ?

[Max Goldstein]

Hey folks, this really should be on the dev list. 

That said I agree with most of what's been said here. The place I'll miss 
primes the most is actually the grammatical possessive: root'sValue, etc. But 
that's not a huge deal. 

-- 
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] Elm Test building custom generators

[Max Goldstein]

Fuzz.map4, which I think was only added in 2.1.0 so that's why Zachary didn't 
see it in August. 

-- 
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] Task.perform stops working when performed from an imported module

[Max Goldstein]

Well... what was the problem?

-- 
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: Why does this not work via record intersection

[Max Goldstein]

You need a rather non-obvious piece of syntax:

make_xword : { a | rows : Int, cols : Int } -> Xword

This basically means that the input is a record with rows and cols, and any 
other fields. The origin of this syntax is that any record *a*, as long as 
it's extended with these fields, is acceptable.

-- 
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] View: Model -> Html Msg

[Max Goldstein]

Syntactically, it's just like List Int. Msg is a type parameter of Html. 

Semantically, Html is not a data structure. It's a somewhat magical thing that 
can produce messages when the user interacts with it. The type parameter tells 
you what those messages are. 

-- 
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] No Runtime Exceptions - Still not computing

[Max Goldstein]

Yes, Result is worth looking at. It's like Maybe, except the error case can 
carry some information too (usually a string). Task is used for 
asynchronous effects (e.g. HTTP requests) which often can fail in odd ways. 
I'd focus on Result for now, as all the tooling I'm about to mention is the 
same across these types.

Joey mentioned we like to map over arrays. Well, you can also map over a 
Maybe or a Result. The trick is that these are also data structures; they 
just happen to hold at most one (successful) element. So you find yourself 
doing things like

String.parseInt "not an integer"
|> Result.map doSomethingWithTheInt
|> Result.andThen doSomethingWithTheIntThatCouldFail

This way you build up pipelines that ignore the fact that you don't 
actually have an integer. The error short-circuits the pipeline and gets 
handled at the end, so it's like throwing in that you can handle the error 
at a distance. And you can collapse many errors into one case that you 
handle all in one place. (minor detail: this is using the argument order 
for andThen coming in 0.18)

I few weeks ago I had to add a lot of try...catch blocks around someone 
else's code, and let me tell you, it wasn't fun.

-- 
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: keeping functions out of the model

[Max Goldstein]

Thank you for your kind words, Joel.

If 0.18 debugging totally breaks an animations, I'll think of something. 
These are some valid concerns but I haven't seen a smoking gun yet.

-- 
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: keeping functions out of the model

[Max Goldstein]

Zinggi: My objection is that the easing function is part of the logical 
identity of the animation. It's tedious to keep track of the function 
separately. Also, animation concepts like velocity and retargetting rely on the 
easing function. "The same animation with a different easing function"… is not 
the same animation. 

-- 
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 to decode a recursive JSON from a port?

[Max Goldstein]

To clarify Rupert: try removing the JSON.stringify call. Elm expects actual 
objects, not a string representation of objects. I think. 

-- 
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: keeping functions out of the model

[Max Goldstein]

Serialization: animations are view state. They can safely be left out of a 
serialized and persisted model.

Print out the model: True, but if you're using animation in an app, you're 
beyond poking at the model in the REPL.

Harder to equate: My animation library provides an "equals" function. In 
addition to sampling the easing function, it accounts for a few other ways 
animations can have different representations but be considered equal (e.g. 
start at time t with delay k == start at time t+k with no delay).

"just store the things needed to create the function" -> This is 
essentially the "EasingDescription" idea I talked about above. The problem 
is that easing functions can be created in many way (sinusoids, 
polynomials, exponentials, bounces) and I want to allow the client to 
specify any function.

-- 
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: keeping functions out of the model

[Max Goldstein]

Hi, I'm the author of the second library you mentioned. It's natural to 
represent easing functions as, well, functions.

One way to avoid this would be to change (or supplement) 
elm-community/easing-functions 
 to contain a big union 
type of all the easings possible. Then we could have a function that turns 
that type into an easing function. The animation models would contain a 
reference to this EasingDescription rather than the function itself.

There are some major downsides to this approach, not counting the work 
involved and library clutter. First, consumers of the animation library 
will have to know about the EasingDescription; it couples the two libraries 
and causes the abstraction to leak. Second, animations will only be able to 
use easing functions that have descriptions, not any easing function they 
like. Finally, my library allows animations to be undone or retargeted, 
which involves working with the easing function in ways beyond the 
description.

So, a better approach might be to sample the easing function provided 
(perhaps 100 times in 0..1) and use linear interpolation between these 
samples. Many samples gives a more accurate animation but consumes more 
memory. This approach also means that retrieving an easing function from an 
animation will be inexact.

Even so, until someone tells me that everything will explode if you have 
functions in your model, I'm going to sit tight.

-- 
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 over-use of 'let... in' considered an anti-pattern?

[Max Goldstein]

>
> ... anyway I hope you get the idea.
>

If the real code was this short, I'd suggest inlining it, but the real code 
is probably long enough to warrant this style.
 

> they start to *resemble *OO/imperitive style variable assignments
>

But they're not. You can't assign to the same value more than once. You can 
actually have some values before the *in* depend on others, but you can't 
do so circularly-- so subject to those dependencies the values may be bound 
in any order. And doing these assignments can only affect anything else 
through how the in-expression is used; they don't attach to an object or 
contaminate global scope. 
 

>  eg chain the model through individual updating functions using '|>'
>

Chaining is great when you want to apply many transformations in sequence. 
Let-bindings are parallel. If it makes sense to have reusable, atomic 
update functions for your record ("updateVelocity"), go for it. But doing a 
batch update of a record with let-bound values feels more natural.
 

> Any strong opinions about this?
>

We try not to have strong opinions. Write code that is correct, explicit, 
and concise (prioritize in that order). Language features and code style 
are in service to that goal. 

-- 
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: [ANN] typed-format 1.0.0

[Max Goldstein]

Looks like a good package, thanks for contributing!

My feedback is, rather than have functions with many arguments that you 
have to name in the docs, why not take a record instead? You can even 
provide a default.

prettyFloat 

 : { prefix : Maybe String, suffix : Maybe String,
showPos : Bool, sep : Char, decimalPoint : Char, decimalPlace : Int }
-> Format 

 
a (Float -> a)

Also, for prettyFloat, will passing *Just ""* and *Nothing* as the first 
argument produce the same result? If so, it seems like you should drop the 
Maybe.

-- 
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: Random in 0.17 and purity

[Max Goldstein]

Hi Andrew, 

The official docs are harder to change than I'd like, but I welcome docs issues 
and PRs to my library:

https://github.com/mgold/elm-random-pcg

Eventually the RNG will replace core's, and hopefully I'll be able to update 
the docs at that time. 

-- 
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: Random in 0.17 and purity

[Max Goldstein]

Hi Andrew, 

The official docs are harder to change than I'd like, but I welcome docs issues 
and PRs to my library:

https://github.com/mgold/elm-random-pcg

Eventually the RNG will replace core's, and hopefully I'll be able to update 
the docs at that time. 

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