Re: [elm-discuss] Compile problem between elm version

[Aaron VonderHaar]

Hi!

[(Float, Float)] should now become:

List (Float, Float)


On Nov 28, 2017 8:54 AM,  wrote:

Hi All :),
some years ago I wrote a very simple program to generate binary trees.

Now Elm won't compile, complaining on

type alias L = [(Float, Float)]

Someone can help me? Many thanks,
Rosario

-- 
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to 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 does this code compile?

[Aaron VonderHaar]

I'm assuming you're expecting an error because `sum` and `num` are values
that are referred to within their own definition?

The rule the compiler currently follows is that referring to yourself is
allowed if the reference is inside a lambda.  (In this example, the
compiler does know whether or not `foldr` is going to immediately call the
lambda or leave it unevaluated.)

On Sun, Nov 26, 2017 at 12:54 PM, Maris Orbidans 
wrote:

>
>
> https://gist.github.com/maruks/18fb2a23e1a2d019dc37563aa08ee46f
>
>
>
> blur : Dict(Int,Int) Int -> ( Int, Int ) -> Int
> blur cells ( x, y ) =
> let
> xs =
> range (x - 1) (x + 1)
>
> ys =
> range (y - 1) (y + 1)
>
> points =
> concatMap (\x -> map (\y -> ( x, y )) ys) xs
>
> *( sum, num )* =
> foldr
> (\p ( s, n ) ->
> case Dict.get p cells of
> Just h ->
>* ( sum + h, num + 1 ) --  ( s + h, n + 1 )*
>
> Nothing ->
> ( s, n )
> )
> ( 0, 0 )
> points
> in
> sum // num
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Decoding a json property with different types of values

[Aaron VonderHaar]

The simplest approach would be to use Json.Decode.oneOf along with
Json.Decode.map:

dataValueDecoder : Json.Decode.Decoder DataValue
dataValueDecoder =
Json.Decode.oneOf
[ Json.Decode.string |> Json.Decode.map Val
, ... decode your KeyType record ...  |> Json.Decode.map Key
]

(Note that if you have control over the JSON format, for more complicated
cases, it's often best to add a "type" field to your JSON, so you can
decode the "type" field first, and then you Json.Decode.andThen to switch
off of the type, which would be more performant if you have lots of cases,
but in your example probably wouldn't be worth the complexity.)


On Wed, Nov 15, 2017 at 11:14 AM, Thiago Temple  wrote:

> I have situation where I have to a jso object similar to this
>
> { "level": 1, "displayValue": "some text", "dataValue": "a string with
> the value" }
>
> { "level": 1, "displayValue": "some text", "dataValue": { "name": "xxx",
> "scope": "" } }
>
> Both cases for dataValue are valid, it can either have a string or an
> object.
>
> I have created types as such:
>
> type DataValue
>   = Val String
>   | Key KeyType
>
> type alias KeyType =
>  { name: String, source: String }
>
> type alias MyObj =
>  { level: Int, displayValue: String, dataValue: DataValue}
>
> How can I decode dataValue for MyObj?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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-make failing when path has spaces

[Aaron VonderHaar]

Hi!

This looks like a bug in the VSCode plugin; elm-make and elm-format can
both handle paths with spaces, so I suspect the VSCode plugin is not
properly quoting the arguments.

Does anyone familiar with the plugin have time to take a look at it?

On Nov 17, 2017 7:19 AM, "Thiago Temple"  wrote:

> I have an existing application and I'm trying to add Elm to it. The
> problem is that the existing application already has a folder structure and
> one of the folders has a space in it.
>
> So when saving a file using vscode I see the following error:
>
>
> 
>
> And that's because the web folder is actually called "Web Server". I can't
> change the folder's name because it will break a bunch of old stuff.
>
> Is there a way to configure elm-make/elm-format to work with that?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] best practices for handling unreachable code, i.e., how to handle situations where runtime assertions would be used in other languages

[Aaron VonderHaar]

d, that implies there is a bug in my code and I can report
>> it to the user through the "normal" error message (the one that is normally
>> used to tell the user they made a mistake).
>>
>> I think I just talked myself into thinking that this is the reasonable
>> way to do it. But it does make me long for runtime exceptions for those
>> errors where you know that not only the current function, but also any
>> function that may have called it, really isn't going to be able to do any
>> error-handling or recovery more sophisticated than "print error message and
>> stack trace to screen".
>>
>> Dave
>>
>>
>>
>> On Sunday, August 20, 2017 at 9:50:00 PM UTC-7, Aaron VonderHaar wrote:
>>>
>>> I think there are two common approaches:
>>>
>>> 1) Deal with the Maybe at a different level.  You mentioned having a
>>> deep call stack, and not wanting to pass a Maybe Int throughout, so maybe
>>> somewhere in the stack it makes sense to give a default value.  Even though
>>> you know you have a non-empty list, it's likely that in certain contexts
>>> you *could* intelligibly deal with empty lists.  Perhaps at a certain level
>>> there's an obvious default.  For example, maybe at a relatively low level,
>>> it makes sense to default to zero if there are no items.  Or if not, maybe
>>> you use the Int to make a String, and maybe it makes sense to default to
>>> the empty string or a placeholder if there's no max.  Or if not, maybe the
>>> string is used in some Html and maybe it makes sense to show a different
>>> thing if there's no String.
>>>
>>> If there are any levels that have an obvious default, I think it can
>>> also improve the modularity and reusability of your code to implement those
>>> defaults even though you know in reality that code path will never get
>>> executed.
>>>
>>> 2) You said you had a provably non-empty list, so why not make a
>>> NonEmptyList type to represent that instead of using List.  Then you could
>>> make `NonEmptyList.maximum : NonEmptyList Int -> Int` and not have to worry
>>> about Maybes.
>>>
>>> On Sun, Aug 20, 2017 at 1:12 PM, Dave Doty <pex...@gmail.com> wrote:
>>>
>>>> I have found many situations in which I am forced by the compiler to
>>>> deal with a situation that will never come up at runtime (or, if it does
>>>> come up, it's a bug in my code and not something the user can do to fix).
>>>> For example, I might make a provably non-empty List (e.g., it is
>>>> always made by the :: operator) and later ask for its max value:
>>>>
>>>> max: List Int -> Int
>>>> max list =
>>>> case List.maximum list of
>>>> Just v ->
>>>> v
>>>>
>>>> Nothing ->
>>>> Debug.crash "This should be unreachable."
>>>>
>>>> The "standard" way to handle this would be to make max return a Maybe
>>>> or a Result instead (i.e., just use List.maximum directly), but this
>>>> can have the effect of altering the type signature of several other
>>>> functions, all for an error that represents a bug in my program, not
>>>> something caused by user error that the user needs to be alerted about.
>>>> This might be 10 levels deep into a function call, and it seems dumb to
>>>> change the type signature of every function from max all the way back
>>>> up to the top to return Maybe, just to handle the situation (list is
>>>> empty) that can only arise through programmer error, not user error.
>>>>
>>>> Is there an "standard" way of dealing with situations like this? I
>>>> assume it's not Debug.crash, given the ample warnings against using it
>>>> in production code. But despite the advertisements of "no runtime
>>>> exceptions in practice", sometimes it seems that there really is no
>>>> graceful way to handle programming errors other than to tell the user
>>>> there's a bug in the code, and dump a stack trace so that the bug can be
>>>> tracked down. In other words, a runtime exception seems like it does
>>>> exactly what is needed in this situation.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Elm Discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to elm-discuss...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] best practices for handling unreachable code, i.e., how to handle situations where runtime assertions would be used in other languages

[Aaron VonderHaar]

I think there are two common approaches:

1) Deal with the Maybe at a different level.  You mentioned having a deep
call stack, and not wanting to pass a Maybe Int throughout, so maybe
somewhere in the stack it makes sense to give a default value.  Even though
you know you have a non-empty list, it's likely that in certain contexts
you *could* intelligibly deal with empty lists.  Perhaps at a certain level
there's an obvious default.  For example, maybe at a relatively low level,
it makes sense to default to zero if there are no items.  Or if not, maybe
you use the Int to make a String, and maybe it makes sense to default to
the empty string or a placeholder if there's no max.  Or if not, maybe the
string is used in some Html and maybe it makes sense to show a different
thing if there's no String.

If there are any levels that have an obvious default, I think it can also
improve the modularity and reusability of your code to implement those
defaults even though you know in reality that code path will never get
executed.

2) You said you had a provably non-empty list, so why not make a
NonEmptyList type to represent that instead of using List.  Then you could
make `NonEmptyList.maximum : NonEmptyList Int -> Int` and not have to worry
about Maybes.

On Sun, Aug 20, 2017 at 1:12 PM, Dave Doty  wrote:

> I have found many situations in which I am forced by the compiler to deal
> with a situation that will never come up at runtime (or, if it does come
> up, it's a bug in my code and not something the user can do to fix). For
> example, I might make a provably non-empty List (e.g., it is always made
> by the :: operator) and later ask for its max value:
>
> max: List Int -> Int
> max list =
> case List.maximum list of
> Just v ->
> v
>
> Nothing ->
> Debug.crash "This should be unreachable."
>
> The "standard" way to handle this would be to make max return a Maybe or
> a Result instead (i.e., just use List.maximum directly), but this can
> have the effect of altering the type signature of several other functions,
> all for an error that represents a bug in my program, not something caused
> by user error that the user needs to be alerted about. This might be 10
> levels deep into a function call, and it seems dumb to change the type
> signature of every function from max all the way back up to the top to
> return Maybe, just to handle the situation (list is empty) that can only
> arise through programmer error, not user error.
>
> Is there an "standard" way of dealing with situations like this? I assume
> it's not Debug.crash, given the ample warnings against using it in
> production code. But despite the advertisements of "no runtime exceptions
> in practice", sometimes it seems that there really is no graceful way to
> handle programming errors other than to tell the user there's a bug in the
> code, and dump a stack trace so that the bug can be tracked down. In other
> words, a runtime exception seems like it does exactly what is needed in
> this situation.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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-format did something change?

[Aaron VonderHaar]

As I get closer to the 1.0 release, I've been trying to figure out how we
can still get user feedback for future format changes.  So the plan is to
have -exp releases that have features that may change or be removed before
the next release.  I was trying that plan out with 0.7.0-exp to see how it
worked.  My thought was that people with less tolerance for formatting
changes and back-and-forth will want to stick to the stable releases, and
those that are able to try out new features can use the -exp version.

However, for 0.7.0-exp specifically, all 4 of the experimental features
will be graduating to the next normal release, and I have started working
on a few remaining bugs before the 0.7.1 release (which will not be -exp).


On Tue, Aug 15, 2017 at 3:40 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Tuesday, August 15, 2017 at 11:11:07 AM UTC+1, Rupert Smith wrote:
>>
>> I am just wondering if I should update all public repositories that I
>> maintain to match the latest version of elm-format? Otherwise we have to
>> keep turning off elm-format-on-save to make nice diffs.
>>
>
> I suppose the question is, is there a consensus on which version is
> considered to be the most 'definitive' for 0.18 code?
>
> Given that that whole thing is pre 1.0 and should be considered alpha,
> does it really make sense at this stage to distinguish between
> 'exp'erimental and alpha releases? That is, should I just go with 0.7.0-exp
> as the canonical formatter? Or do people think that it is better to go with
> 0.6.1-alpha?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Immutable data design problem

[Aaron VonderHaar]

arcel that takes a record with a parcel number,
> initial owner, and list of AssessmentEvents. Those AssessmentEvents must in
> turn have been created by calling createAssessmentEvent, which takes the
> independent fields of an AssessmentEvent and creates the full record with
> the derived fields. However, there really are yet more fields that can't be
> derived by looking at a single AssessmentEvent in isolation. Some
> calculation has to be done by determining chains of them and computing
> deltas along the chain.
>
> Currently I have createParcel computing a Dict of assessmentEventsById
> (so, it's assuming some ID already exists on the AssessmentEvents, which is
> a separate issue). It also computes a list of roll years that are relevant
> to the assessment events, which involves some date math. It computes an
> ownership chain - that is, a list of date ranges and who owned the property
> during that time range. And finally it computes the list of assessment
> events that are effective for each roll year. Each assessment event might
> appear in the list for as many as two consecutive years, depending on its
> dates.
>
> Then there will have to be deltas calculated between the assessment events
> for a given roll year. The accounts will be created from those. And
> finally, one or two bills will be created from each account, depending on
> the type of assessment event. All of this will be completely deterministic,
> based on the initial seed data of assessment events. But I need these
> accounts and bills calculated in order to properly view the data.
>
> If I am using IDs, then I can make a data structure that just contains the
> deltas by ID, rather than creating another AssessmentEvent structure that
> has room for the delta values. But that would mean that when outside code
> needed to get the delta value, it couldn't just have an AssessmentEvent. It
> would have to have an AssessmentStore (or Parcel) and an EventID and call a
> function which could use that to retrieve the delta value from the Dict.
> So, it's a pretty different model for the caller.
>
> So far I have been putting all this logic in one module, called Property.
> (The view logic is in a separate module.) I've been using datatypes with a
> single constructor, so the view code can pattern match against them. But
> now I'm starting to wonder whether it'd be safer to hide the
> representations here in the Property module.
>
> At some point in the future I will want to allow adding/removing/updating
> assessment events in real time. Then I will have to decide whether I want
> to just recalculate the entire set of data or try to figure out which bits
> need to change. Recalculating the whole thing will probably be performant
> enough. But I guess there could be an issue with IDs - if some data gets
> loaded from the database and needs to preserve existing IDs, I can't just
> generate new IDs for the whole set. I'll figure out that problem when I
> come to it.
>
> Regards,
> Lyle
>
> On Sunday, July 23, 2017 at 8:17:07 PM UTC-7, Aaron VonderHaar wrote:
>>
>> I'm not sure I understand all the details of your domain model, but it
>> seems like the notable point is that accounts are created implicitly as
>> assessment events occur, and you'd like to be able to, given an assessment
>> event, get the related accounts?
>>
>> I'd probably start with making a module (maybe called "AssessmentStore")
>> that has functions that describe what you need.  I'm thinking something
>> like:
>>
>> allEvents : AssessmentStore -> List AssessmentEvent
>>
>> and hmm... now that I write that out, it seems like that's all you want,
>> except that you ideally want AssessmentEvent to have a list of Accounts in
>> it.
>>
>> I think the approach I would prefer is similar to what you mention in
>> your last paragraph about keeping the data in separate structures, but you
>> question the safety of managing parallel structures.  If you create a
>> separate module to encapsulates the data, you can can limit the need for
>> careful handling to that single module.  I might try something like this in
>> `AssessmentStore`:
>>
>> type AssessmentStore =
>> AssessmentStore
>> { assessmentEventInfo : Dict EventId { name : String, ... } --
>> This is not the full AssessmentEvent; just the things that don't relate to
>> accounts.
>> , accountsByEvent : Dict EventId (List AccountId)
>> , accountInfo : Dict AccountId Account
>> , allEvents : List EventId -- (or maybe you want them indexed
>> differently, by time, etc)
>> }
>>
>> then have a function to create th

Re: [elm-discuss] Immutable data design problem

[Aaron VonderHaar]

I'm not sure I understand all the details of your domain model, but it
seems like the notable point is that accounts are created implicitly as
assessment events occur, and you'd like to be able to, given an assessment
event, get the related accounts?

I'd probably start with making a module (maybe called "AssessmentStore")
that has functions that describe what you need.  I'm thinking something
like:

allEvents : AssessmentStore -> List AssessmentEvent

and hmm... now that I write that out, it seems like that's all you want,
except that you ideally want AssessmentEvent to have a list of Accounts in
it.

I think the approach I would prefer is similar to what you mention in your
last paragraph about keeping the data in separate structures, but you
question the safety of managing parallel structures.  If you create a
separate module to encapsulates the data, you can can limit the need for
careful handling to that single module.  I might try something like this in
`AssessmentStore`:

type AssessmentStore =
AssessmentStore
{ assessmentEventInfo : Dict EventId { name : String, ... } -- This
is not the full AssessmentEvent; just the things that don't relate to
accounts.
, accountsByEvent : Dict EventId (List AccountId)
, accountInfo : Dict AccountId Account
, allEvents : List EventId -- (or maybe you want them indexed
differently, by time, etc)
}

then have a function to create the assessment store, and then the
`allEvents` functions suggested above (or any other function to get
AssessmentEvents) can take the data in that private data structure and
merge it together to give the data that you actually want to return to the
caller.  In fact, you never need to expose the AccountIds/EventIds outside
of this module.

If you are still worried about safety, you can add more unit tests to this
module, or try to define fuzz test properties to help you ensure that you
handle the computations correctly within the module.

I've found this sort of approach to work well because it lets you represent
the data in whatever data structure is most performant and/or appropriate
for your needs (it is often also simpler to implement because the data
structures tend to be much flatter), but also hides the internal
representation behind an module interface so that you can still access the
data in whatever ways are most convenient for the calling code.




On Sun, Jul 23, 2017 at 7:16 PM, Lyle Kopnicky  wrote:

> I have a series of datatypes that have already been modeled in a
> relational database in a product. I'm trying to construct a lighter-weight
> in-memory representation in Elm for purposes of simulating operations and
> visualizing the results. Ultimately I will probably want to do some
> export/import operations that will allow someone to view data from the real
> database, or create records in a test database. But, I don't think the
> in-memory representations need to correspond exactly to the database ones
> in order to do this. I'd like to focus on as simple of a representation as
> possible, and I'm leaving out a fair number of fields.
>
> We start with a provided series of AssessmentEvents. It's just a limited
> amount of data for each AssessmentEvent. Some of the fields in the database
> can be calculated from the others, so those don't need to be provided. From
> this data, we can calculate more information about the AssessmentEvents,
> including deltas between them. We can also derive a series of Accounts in a
> completely deterministic fashion. Each AssessmentEvent will have up to two
> years associated with it, and for each year there will be at least one
> Account. From this we can also calculate one or two Bills to go with each
> Account.
>
> It's a fairly complex calculation. Certainly I can do it in Elm. But what
> I'm waffling about is how to store the data. These calculations can be
> cached - they do not need to be repeated if the user just changes their
> view of the data. They only need to be revised if the user wants to
> insert/edit/update AssessmentEvents. So to do all these calculations every
> time the user shifts the view would be wasteful.
>
> It becomes tricky with immutable data. In an object-oriented program, I
> would probably just have, say, extra empty fields on the AssessmentEvent
> object, that I would fill in as I updated the object. E.g., it could have a
> list of accounts, which initially would be a null value until I filled it
> in.
>
> At first I thought I might do something similar in the Elm data structure.
> An AssessmentEvent can contain a List of Accounts (I'm oversimplifying as
> it really needs to list the accounts per year). The list of Accounts can be
> initially empty. Then as I calculate the accounts, I can create a new list
> of AssessmentEvents that have Accounts in the list. But wait - since the
> list of AssessmentEvents is immutable, I can't change it. I can only create
> a new one, and then, where in the model 

Re: [elm-discuss] Re: Why is the signature of 'program.subs' 'model -> Sub msg' ?

[Aaron VonderHaar]

Another example is a package like WebSocket, where the package will open a
network connection while you are subscribed and close it when you stop
subscribing.

On Jul 17, 2017 7:19 AM, "Marek Fajkus"  wrote:

Sometimes you don't need subscriptions if you're in some state. For
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.

-- 
You received this message because you are subscribed to the Google Groups
"Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to 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-format seems... problematic

[Aaron VonderHaar]

In the case of doc comments `{-| -}`, the way elm-format moves them is
indicative of how elm-make and elm-package interpret them, so if elm-format
is moving those, you probably had them in the wrong place.

For other comments, there is unfortunately ambiguity in Elm's syntax about
what any given comment is meant to be associated with.  In general, a `--`
comment is associated with the thing before it, unless it starts a new
line, and other comments are associated with things before/after depending
on what made sense in the parser.  There is a guide in progress that will
give examples of how comments will be parsed and where to put them if you
want to document a particular thing.

Thus far there has been little feedback about comment handling, so many of
the details have not yet been assessed to determine what is best.

You can provide specific examples by submitting issues for elm-format
https://github.com/avh4/elm-format/issues



On Wed, Jul 5, 2017 at 7:27 PM, Raoul Duke  wrote:

> It might make mechanical ascii diffing easier, but it seems to destroy
> so many other valuable ux things along the way.
>
> like, small example that seems to me to be a giant red flag: it moves
> my comments around, so they aren't actually next to the thing they are
> commenting about?!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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 to properly test a module?

[Aaron VonderHaar]

Probably the best starting point are the docs for elm-community/elm-test if
you haven't seen them already:
http://package.elm-lang.org/packages/elm-community/elm-test/latest

On Sat, Jun 17, 2017 at 7:32 AM, John Bugner  wrote:

> So, I made a module!: http://package.elm-lang.org/packages/JohnBugner/
> elm-bag/latest
>
> It's a bag (aka a multiset). But, I haven't tested it yet. I looked to
> 'Core' for inspiration ( https://github.com/elm-lang/
> core/blob/master/tests/Main.elm ), but it doesn't help me; It imports a
> bunch of 'Test' modules, but I don't know where these modules come from, or
> how to use them. What's the proper way to do this? Is there an official
> guide on this (yet)?
>
> Btw, why doesn't 'Core' have a bag/multiset type already?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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: Adding CSS produced by a view function to the document's

[Aaron VonderHaar]

I experimented with some ways to have view functions that return both Html
and the necessary styles.  I found I could make it work, but I ultimately
abandoned the idea because of a fundamental problem:

view model =
if model.showWidget then
Widget.view model.widgetData
else
text ""

In the code above, depending on the model, you may or may not call
Widget.view.  If your view functions are some new type that includes the
necessary styles, then you now have a problem that you will only know about
the styles for views that are currently visible, which means that your
final stylesheet will constantly be changing as the model changes.

What we really want is to get all the styles for all Html that *might*
appear, not for all Html that currently appears.  I suspect an API could be
designed that would allow such Html+styles views to be composed in a way
that could provide *all*possible*styles*, but I expect it would probably be
a significant departure from how Html-only views work, so I haven't pursued
that idea further.

At NoRedInk, we have an idea for a way to look at an entry point Elm file
and traverse all of the imported modules, collect all of the top-level
Stylesheets (similar to what the latest elm-test does for Test
definitions), and compile a .css file that we can reference in the 
(but this would be done outside of Elm).  However, that idea is also
currently in a state of haven't-yet-pursued-further.

On Thu, Jun 8, 2017 at 4:38 AM, Kevin Yank  wrote:

> The style-elements
> 
> package introduced at Elm Europe today needs to solve this problem too. For
> now, it too is just rendering an invalid 

Re: [elm-discuss] Unexpected Time.every drift over time

[Aaron VonderHaar]

Time.every relies on javascript's setInterval.  Do you see the same drift
in Safari/node using setInterval?

If you need more accurate timing, it's possible to attempt that now using a
combination of Time.now and Process.sleep (every time you get a message,
check the timestamp and calculate how long you want to sleep for).
Process.sleep relies on setTimeout, so this can still drift on any given
sleep, but you'd be able to calculate a correction when you trigger the
next sleep.

Also note that it's better if possible to change your logic to not rely on
fixed-interval messages, since Javascript itself does not provide a method
of real-time scheduling. Instead it's recommended to use the Time value in
the message to determine how much you need to update.  (This also would let
you swap in AnimationFrame.times if you want more responsive updates, which
is also recommended over using Time.every with a very small interval.)

On Sun, Jun 4, 2017 at 10:17 AM, RGBboy  wrote:

> I have been using Time.every for a project that requires ticks at a
> constant interval. I found that different platforms drift by varying
> amounts. Some platforms seem to oscillate around the desired 0 millisecond
> drift. This is acceptable for my use case. However some platforms
> constantly increase in drift over time. This is unacceptable for my use
> case.
>
> I put together an example application with Ellie that exhibits the issue (
> https://ellie-app.com/3p4mpnVyTj8a1/2). If you compile and open up the
> console you can see how much the application drifts over time in your
> browser. I have a bunch of results from the platforms that I have access
> to. You can see that Safari and Node.js both increase in drift over time:
>
> *Chrome 58.0.3029.110:*
>
> DRIFT: Nothing
> DRIFT: Just 4
> DRIFT: Just 4
> DRIFT: Just -1
> DRIFT: Just 0
> DRIFT: Just 1
> DRIFT: Just 2
> DRIFT: Just 3
> DRIFT: Just 5
> DRIFT: Just 1
> DRIFT: Just 3
> DRIFT: Just 4
> DRIFT: Just -1
> DRIFT: Just 1
> DRIFT: Just 0
> DRIFT: Just 2
>
>
> *Firefox 47.0:*
>
> DRIFT: Nothing
> DRIFT: Just -2
> DRIFT: Just 0
> DRIFT: Just 2
> DRIFT: Just -2
> DRIFT: Just -3
> DRIFT: Just -1
> DRIFT: Just 0
> DRIFT: Just -2
> DRIFT: Just -3
> DRIFT: Just 3
> DRIFT: Just -2
> DRIFT: Just -3
> DRIFT: Just -2
> DRIFT: Just -1
> DRIFT: Just -2
>
>
> *Safari 10.1:*
>
> DRIFT: Nothing
> DRIFT: Just 0
> DRIFT: Just 0
> DRIFT: Just 4
> DRIFT: Just 3
> DRIFT: Just 4
> DRIFT: Just 4
> DRIFT: Just 4
> DRIFT: Just 5
> DRIFT: Just 5
> DRIFT: Just 6
> DRIFT: Just 7
> DRIFT: Just 8
> DRIFT: Just 9
> DRIFT: Just 10
> DRIFT: Just 11
>
>
> *Node.js 7.10.0:*
>
> DRIFT: Nothing
> DRIFT: Just 2
> DRIFT: Just 5
> DRIFT: Just 6
> DRIFT: Just 10
> DRIFT: Just 17
> DRIFT: Just 22
> DRIFT: Just 27
> DRIFT: Just 32
> DRIFT: Just 37
> DRIFT: Just 40
> DRIFT: Just 43
> DRIFT: Just 45
> DRIFT: Just 51
> DRIFT: Just 54
> DRIFT: Just 56
>
>
> *Node.js 8.0.0:*
>
> DRIFT: Nothing
> DRIFT: Just 4
> DRIFT: Just 6
> DRIFT: Just 7
> DRIFT: Just 8
> DRIFT: Just 12
> DRIFT: Just 14
> DRIFT: Just 14
> DRIFT: Just 14
> DRIFT: Just 20
> DRIFT: Just 23
> DRIFT: Just 25
> DRIFT: Just 25
> DRIFT: Just 30
> DRIFT: Just 32
> DRIFT: Just 37
>
>
> There are a number of ways I can mitigate the issue but I am wondering
> where is the most pragmatic place for this to be fixed?
>
> *The given platform?*
>
> This would mean Safari, Node and any other inconsistent platforms fix
> this. This seems like it is extremely unlikely to happen. For example this
> is a known issue across multiple node version that was raised almost a year
> ago with no fix yet (https://github.com/nodejs/node/issues/7346).
>
> *Elm's Core Time module?*
>
> This would give consistent behaviour for all consumers no matter what
> platform they are running on. I have made a proof of concept that enables
> this so it is possible. I'm just not sure if this is a change that aligns
> with the intension of the module.
>
> *My application?*
>
> There are a number of things I could do within my application to mitigate
> the issue (which I am already doing). For example I could track the drift
> and counter it in my subscription. My only reservation here is that others
> will face the same issue.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Idris holes - Thoughts for Elm?

[Aaron VonderHaar]

If you haven't seen it already, https://atom.io/packages/elmjutsu has
support for creating case statement scaffolds (search the README for
"Insert case/of")

On Mon, May 22, 2017 at 10:06 PM, Zachary Kessin  wrote:

> totally agree, it would also make it easier to have your editor fill in
> the code for me
>
> Lets say you have a type like this
> type Direction = North|South|East | West
> move: Pos -> Direction -> Pos
> move pos dir =
>   case dir of
>  North -> ?rhs
>  South -> ?rhs
> etc
>
> What I would like is to write "case dir of" and hit <> (or some other
> key) in my editor and have the case statement with holes filled in for me.
>
> I think Idris does this already
>
> Zach
> ᐧ
>
> On Tue, May 23, 2017 at 2:11 AM, Witold Szczerba 
> wrote:
>
>> I think it looks like a good idea. When I am adding new a feature, very
>> often I have such a "holes", implementation details, which I do not want to
>> code at the time of introduction, because I am not sure the final result of
>> my changes. So, in order to make compiler happy, I am improvising with some
>> dump implementation just to let me go further and at the end, I have to
>> look for them and fix.
>>
>> Such a "holes" would be great.
>>
>> On Mon, May 22, 2017 at 8:40 PM, W. Brian Gourlie 
>> wrote:
>>
>>> For the uninitiated, Idris  is a
>>> pure functional language with a cutting-edge type system. However, this is
>>> not another "We should make Elm's type system more advanced by introducing
>>> X." Rather, I ran across a feature in Idris that seems like it would fit
>>> nicely into Elm based on the fact that it further empowers the compiler to
>>> assist the developer, and empowers the developer to iteratively develop
>>> their code. This feature is called holes.
>>>
>>> *What are holes?*
>>>
>>> To put it succinctly, a "hole" is a hole in your implementation. Think
>>> of it as an expression whose value is inferred based on surrounding
>>> context, but does not actually produce a value. Holes allow our code to
>>> type-check while freeing the developer from actually having to worry about
>>> implementing every part of a function or program as they're writing it.
>>>
>>> *How does an incomplete program compile?*
>>>
>>> The short answer is, it doesn't. There would need to be a distinction
>>> between a program that satisfies the type-checker, and a program that can
>>> be compiled. For example, there may be a hypothetical command `elm-make
>>> --check`. Or, perhaps, a special compilation mode that would convert holes
>>> into Debug.crash statements.
>>>
>>> *A practical example*
>>>
>>> Consider the following code:
>>>
>>> describeTemp : Int -> String
>>> describeTemp temp =
>>>   if temp > 100 then
>>> "Really hot!"
>>>   else if temp < 32 then
>>> "Freezing"
>>>   else if temp < 0 then
>>> ?belowZeroMessage
>>>  else
>>> ?catchAllMessage
>>>
>>> In the above example, we declared two holes using the syntax
>>> `?holeName`.  The theoretical output of the type checker may be something
>>> like:
>>>
>>> Type Checking Succeeded!
>>>
>>> You have 2 holes to fill:
>>>
>>> 8| ?belowZeroMessage
>>>^
>>> belowZeroMessage : String
>>>
>>> 10| ?catchAllMessage
>>> 
>>>
>>> catchAllMessage : String
>>>
>>>
>>> The example is simple and contrived, so it's not necessarily
>>> representative of a scenario where it would be useful, but for more complex
>>> applications where you want to build things iteratively, with
>>> type-checking, without resorting to returning dummy values or things like
>>> `Debug.crash`, this would be very useful!
>>>
>>> I'd be curious to know what everyone else thinks.
>>>
>>> Brian
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to 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.
>>
>
>
>
> --
> Zach Kessin
> Teaching Web Developers to test code to find more bugs in less time
> Skype: zachkessin
> +972 54 234 3956 <+972%2054-234-3956> / +44 203 734 9790
> <+44%2020%203734%209790> / +1 617 778 7213 <(617)%20778-7213>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: [elm-discuss] Idris holes - Thoughts for Elm?

[Aaron VonderHaar]

I think you could easily experiment with this style of development without
any syntax changes:

```
module Holes exposing (hole)

hole : String -> a
hole name =
Debug.crash ("unfilled hole: " ++ name)
```

and replace elm-make with:

```
#!/bin/bash

set -ex

elm-make "$@"
echo "Type Checking Succeeded!"
! grep -R "import Holes" src
```

The replacement `elm-make` script will fail if there are still holes to
fill.

On Mon, May 22, 2017 at 4:11 PM, Witold Szczerba 
wrote:

> I think it looks like a good idea. When I am adding new a feature, very
> often I have such a "holes", implementation details, which I do not want to
> code at the time of introduction, because I am not sure the final result of
> my changes. So, in order to make compiler happy, I am improvising with some
> dump implementation just to let me go further and at the end, I have to
> look for them and fix.
>
> Such a "holes" would be great.
>
> On Mon, May 22, 2017 at 8:40 PM, W. Brian Gourlie 
> wrote:
>
>> For the uninitiated, Idris  is a
>> pure functional language with a cutting-edge type system. However, this is
>> not another "We should make Elm's type system more advanced by introducing
>> X." Rather, I ran across a feature in Idris that seems like it would fit
>> nicely into Elm based on the fact that it further empowers the compiler to
>> assist the developer, and empowers the developer to iteratively develop
>> their code. This feature is called holes.
>>
>> *What are holes?*
>>
>> To put it succinctly, a "hole" is a hole in your implementation. Think of
>> it as an expression whose value is inferred based on surrounding context,
>> but does not actually produce a value. Holes allow our code to type-check
>> while freeing the developer from actually having to worry about
>> implementing every part of a function or program as they're writing it.
>>
>> *How does an incomplete program compile?*
>>
>> The short answer is, it doesn't. There would need to be a distinction
>> between a program that satisfies the type-checker, and a program that can
>> be compiled. For example, there may be a hypothetical command `elm-make
>> --check`. Or, perhaps, a special compilation mode that would convert holes
>> into Debug.crash statements.
>>
>> *A practical example*
>>
>> Consider the following code:
>>
>> describeTemp : Int -> String
>> describeTemp temp =
>>   if temp > 100 then
>> "Really hot!"
>>   else if temp < 32 then
>> "Freezing"
>>   else if temp < 0 then
>> ?belowZeroMessage
>>  else
>> ?catchAllMessage
>>
>> In the above example, we declared two holes using the syntax
>> `?holeName`.  The theoretical output of the type checker may be something
>> like:
>>
>> Type Checking Succeeded!
>>
>> You have 2 holes to fill:
>>
>> 8| ?belowZeroMessage
>>^
>> belowZeroMessage : String
>>
>> 10| ?catchAllMessage
>> 
>>
>> catchAllMessage : String
>>
>>
>> The example is simple and contrived, so it's not necessarily
>> representative of a scenario where it would be useful, but for more complex
>> applications where you want to build things iteratively, with
>> type-checking, without resorting to returning dummy values or things like
>> `Debug.crash`, this would be very useful!
>>
>> I'd be curious to know what everyone else thinks.
>>
>> Brian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Implementing a protocol on top of WebSocket: should I build a effect module ?

[Aaron VonderHaar]

I think another question worth asking is what Tasks should to official
WebSocket package expose to be useful to protocol module authors?

Originally, someone was going to implement a Phoenix channels package on
top of websockets as a real-world example of a websockets protocol, but
afaik that never needed up happening.  So your package may be the first to
try to modularize a websockets protocol.  I expect you'll probably run into
things that could be motivating use cases for changes/additions to the
websockets package.



On May 16, 2017 8:32 AM, "Christophe de Vienne" <christo...@cdevienne.info>
wrote:

>
>
> Le 16/05/2017 à 17:17, Christophe de Vienne a écrit :
> > Thank you for the feedback.
> >
> > I am still trying to find a non-effect based API. Did not find anything
> > satisfying so far.
> >
> > The WebSocket.LowLevel module is interesting for send batches, but my
> > main issue is how to associate a custom message translator to each
> > subscription in a global protocol state.
>
> Plus the WebSocket module provides very useful behavior I would prefer
> not to reimplement.
>
> >
> > Le 16/05/2017 à 17:02, Aaron VonderHaar a écrit :
> >> Hi, I haven't played much with WebSockets, but I have been building a
> >> protocol on top of HTTP.  I haven't yet run into an issue that made me
> >> think to try an effects module.
> >>
> >> Instead of having custom subscriptions, my package has an `update`
> >> function that takes any msgs resulting from its commands and returns
> >> some appropriate stuff (in my case, that is an optional output value
> >> that the caller can do something with, and also another Cmd to run).
> >>
> >> For the Cmds, I do have to use the Tasks portion of the HTTP API so that
> >> I can compose and chain things together (though I do in the end return a
> >> Cmd for most functions in my protocol's API).  For WebSockets, I see
> >> there's http://package.elm-lang.org/packages/elm-lang/websocket/1.0.
> 2/WebSocket-LowLevel
> >> which provides Tasks instead of Cmds, so it's likely you could use that
> >> for what you need.
> >>
> >> I don't know if those things will address all the needs of your
> >> WebSockets protocol, but those approaches have worked for what I've been
> >> building.  (Sorry, it's not open-source, so can't share the code.)
> >>
> >> --Aaron V.
> >>
> >> On Tue, May 16, 2017 at 7:30 AM, Christophe de Vienne
> >> <christo...@cdevienne.info <mailto:christo...@cdevienne.info>> wrote:
> >>
> >> Hi everyone,
> >>
> >> I am attempting to implement the pub/sub NATS (https://nats.io)
> protocol
> >> on top of the WebSocket API as a TEA component.
> >>
> >> I have a hard time finding an API for subscriptions: for each
> >> subscription some context must be kept, a unique subscription ID
> >> generated and in some case a unique reply subject too, and I would
> like
> >> each subscription to generate custom messages for the component
> which
> >> made it.
> >>
> >> I suspect it would be a lot more natural with an effect module, with
> >> which I could (hopefully) write, in any part of the application:
> >>
> >> subscriptions : Model -> Sub Msg
> >> subscriptions model =
> >> Nats.Subscribe model.endpoint "some.subject" MyMessage
> >>
> >> or, for req/rep (a pub + a short-living sub expecting a result):
> >>
> >> myrequest : Model -> Cmd Msg
> >> myrequest model =
> >> Nats.request model.endpoint "a.request.subject" MyReply
> >>
> >>
> >> Another difficulty I have is that in some cases I need to send 2 or
> 3
> >> messages through the websocket, in the right order, but
> WebSocket.send
> >> returns a Cmd. So I have to concat the 3 commands in 1 message,
> which
> >> works but oblige
> >>
> >> Am I wrong being tempted by using an effect module for this kind of
> >> module ?
> >> If so how can I mimick such an API with a TEA approach  ?
> >> If not is there any documentation I can read to get familiar with
> them ?
> >>
> >> Is there any existing module that does this kind of thing for
> another
> >> protocol ?
> >>
> >> Thanks!
> >>
> >> --
> >> Christophe de Vienne
> >>
> >>

Re: [elm-discuss] Implementing a protocol on top of WebSocket: should I build a effect module ?

[Aaron VonderHaar]

Hi, I haven't played much with WebSockets, but I have been building a
protocol on top of HTTP.  I haven't yet run into an issue that made me
think to try an effects module.

Instead of having custom subscriptions, my package has an `update` function
that takes any msgs resulting from its commands and returns some
appropriate stuff (in my case, that is an optional output value that the
caller can do something with, and also another Cmd to run).

For the Cmds, I do have to use the Tasks portion of the HTTP API so that I
can compose and chain things together (though I do in the end return a Cmd
for most functions in my protocol's API).  For WebSockets, I see there's
http://package.elm-lang.org/packages/elm-lang/websocket/1.0.2/WebSocket-LowLevel
which provides Tasks instead of Cmds, so it's likely you could use that for
what you need.

I don't know if those things will address all the needs of your WebSockets
protocol, but those approaches have worked for what I've been building.
 (Sorry, it's not open-source, so can't share the code.)

--Aaron V.

On Tue, May 16, 2017 at 7:30 AM, Christophe de Vienne <
christo...@cdevienne.info> wrote:

> Hi everyone,
>
> I am attempting to implement the pub/sub NATS (https://nats.io) protocol
> on top of the WebSocket API as a TEA component.
>
> I have a hard time finding an API for subscriptions: for each
> subscription some context must be kept, a unique subscription ID
> generated and in some case a unique reply subject too, and I would like
> each subscription to generate custom messages for the component which
> made it.
>
> I suspect it would be a lot more natural with an effect module, with
> which I could (hopefully) write, in any part of the application:
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
> Nats.Subscribe model.endpoint "some.subject" MyMessage
>
> or, for req/rep (a pub + a short-living sub expecting a result):
>
> myrequest : Model -> Cmd Msg
> myrequest model =
> Nats.request model.endpoint "a.request.subject" MyReply
>
>
> Another difficulty I have is that in some cases I need to send 2 or 3
> messages through the websocket, in the right order, but WebSocket.send
> returns a Cmd. So I have to concat the 3 commands in 1 message, which
> works but oblige
>
> Am I wrong being tempted by using an effect module for this kind of module
> ?
> If so how can I mimick such an API with a TEA approach  ?
> If not is there any documentation I can read to get familiar with them ?
>
> Is there any existing module that does this kind of thing for another
> protocol ?
>
> Thanks!
>
> --
> Christophe de Vienne
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Noticeable lag when working with a model that contains large dataset

[Aaron VonderHaar]

Hi!

The first thing I'd check is whether your view or update functions end up
doing O(n) operations (like iteration) with the large list.  (Perhaps
searching through it for some reason to do validation as the form changes?
If that's the problem, then you'll want to consider alternate data
structures to instead store the data in the list in a way that optimizes
the access you need.

If you've ruled that out, then it's likely that your view function is
taking a long time.  The entire virtual dom will be recomputed from your
model after every update, even though the real dom will be update
incrementally.  To improve this, isolate the largest piece of your view
that depends on the large list but doesn't depend on the form data, and
wrap that piece in Html.lazy.

Let us know if any of that helps.

--Aaron V.

On Apr 3, 2017 6:32 AM, "Jais Cheema"  wrote:

> Hi,
>
> I am currently working on a SPA which stores a list of records (~ 2500)
> with 4 fields in the model. One of those fields is another list which
> contains 2 items on average but can be more.
>
> I am implementing a form component to create a new item, and the issue I
> am seeing is that there is a very noticeable lag after every action. Form
> does not deal with the previous mentioned list, but updates another record
> which is a part of the list. Below is simplified version of my model code.
>
> type alias Parent =
> { id: Int
> , title: String
> , children: List Child
> }
>
> type alias Child =
> { id: Int
> , title: String
> }
>
> type alias Form =
> { title: String }
>
> type alias Model =
> { rootNodes: List Parent
> , rootNodeForm: Maybe Form
> }
>
>
> Can someone please recommend how can I overcome this issue? Or even
> pointers on what actions are expensive in Elm and I should be avoiding when
> dealing with large amount of data in your model?
>
> Thank you in advance :)
>
> Cheers
> Jais Cheema
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Flags vs Ports

[Aaron VonderHaar]

Ahoy! :)

Yes, everything you've said is correct, including avoiding unnecessary
maybes.

On Sun, Apr 2, 2017 at 11:41 PM, Richard Wood  wrote:

> Sounds like some nautical adventure!
>
> When is it appropriate to bring in data through flags vs through using
> ports.
> At the moment I'm thinking:
>
> Flags:
> * When needed immediately on initialisation
> * When it won't change
>
> Ports:
> * Dynamic data
> * Data not available at the start
>
> Is another reason to use a flag to avoid a perhaps unnecessary maybe? This
> came up when trying to have a time variable. I don't want a maybe time
> variable as then I have to handle the maybe every time I use it. So I'm
> thinking to pass the time in as a flag to begin with then keep it update
> through ports.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] 'Native' -> 'Kernel': a msgpack example

[Aaron VonderHaar]

Thanks for sharing your impressions.  Is there a particular question you're
hoping to have answered or a proposed or attempted solution that you'd like
to discuss?



On Thu, Mar 23, 2017 at 1:15 PM, Simon  wrote:

> On elm-dev I get the impression that bigger barriers are being built to
> towards javascript interop.
>
> I think building the barriers before the webapi is provided in Elm is the
> wrong way around, but that's not the only case where practical needs are at
> risk.
>
> Consider msgpack - a sort of compressed json. It's well specified but
> today not much used. No one has written a library for it in Elm, but there
> is a well-tested JS one. The encoding is simply calculations, so in the
> normal run of things this should be a synchronous operation. If ports
> returned Tasks this would not be a huge issue, but they return Commands and
> thus force you back around the update loop (and the creation of an extra
> Msg, which makes code intent less transparent).
>
> The work around is a native file along the lines of (or see this NoRedInk
> library 
> ):
>
> ```
> var _user$project$Native_Msgpack = function() {
>
> function encode(k) {
> return msgpack.encode(k.kwd);
> }
> }
> ```
>
> It's pretty clear that these practices are frowned upon, but the shift to
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options
> further. I hope that's not the case.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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 create a circular reference in Elm?

[Aaron VonderHaar]

Note, however, that it is not difficult to implement the following, even
without circular references:

```
reader : Library -> Book -> Maybe Reader
borrowing : Library -> Reader -> List Book
checkOut : Reader -> Book -> Library -> Maybe Library
checkIn : Reader -> Book -> Library -> Library
```

On Thu, Mar 16, 2017 at 10:06 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> I am guessing the answer is no.
>
> type alias Reader { borrowing : List Book }
> type alias Book { reader : Maybe Reader }
>
> newBob = { bob | borrowing = [ warAndPeace ] }
> newWarAndPeace = { warAndPeace | reader = Just newBob }
>
> but the book that bob is borrowing will not have the link back to himself,
> as it was only added to the new version.
>
> Is the Elm heap therefore always cycle free?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] JSON decode/encode fails on the object with key name starting as a number :(

[Aaron VonderHaar]

The name of the field in the Elm record does not need to match the name of
the field in the JSON, so you can fix the code generated by json-to-elm by
renaming the "1Sa" field in the type alias to something that doesn't start
with a number.

On Thu, Dec 29, 2016 at 8:28 PM, Jaroslaw Zabiello 
wrote:

> How to decode/encode JSON object which has some keys starting as a number?
> Eg:
>
> {
>   "1Sa": {
> "name": "1Sm",
> "label": "1 Samuela"
> },
>   "Ezr": {
> "name": "Ezd",
> "label": "Ezdrasza"
> }
> }
>
> The code generated by http://noredink.github.io/json-to-elm/ is *invalid*
> because Elm's Record cannot habe key name started with the number. :(
>
> type alias Books =
> { *1Sa* : Books1Sa
> , ezr : BooksEzr
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Tuple indexing?

[Aaron VonderHaar]

Sorry for being unclear.  Your point that it should be unnecessary to name
unimportant things is a valid one.  Can you share the specifics of
scenarios where you have 3-tuples and larger where it doesn't make sense to
give names to each part?  Elm's design is based on finding clean solutions
to real-world problems, so more examples of that are valuable to inform
Elm's future development.

You also mentioned that you ran into this when using 3rd-party packages.
Can you point out some of the packages where you've needed to use functions
that returned 3-tuples and larger where you only cared about one of the
values in the tuple?



On Tue, Dec 27, 2016 at 10:55 AM, Mike MacDonald <crazym...@gmail.com>
wrote:

> I can't think of a use case where defining an intermediary type wouldn't
> solve the immediate issue; philosophically I dislike naming things which
> are unimportant.
>
> On Tuesday, December 27, 2016 at 1:08:03 PM UTC-5, Aaron VonderHaar wrote:
>>
>> One reason `first` and `second` are only defined for 2-tuples is that
>> it's usually a better choice to use records if you have more than a couple
>> fields.
>>
>> If defining a record type alias and giving names to you're fields doesn't
>> work for your situation, can you give more details about why?
>>
>> On Dec 27, 2016 7:09 AM, "Mike MacDonald" <craz...@gmail.com> wrote:
>>
>>> On a somewhat regular basis, I end up needing to extract a single field
>>> from a tuple provided from a third-party function. At the moment, I have to
>>> write a boilerplate function just to pattern match it out. If I need the
>>> second field of tuple of a different size, I need to write more boilerplate.
>>>
>>> Seeing as record filed names cannot start with digits, and the language
>>> only allows up to Tuple9, it would be nice to have `.0` through `.8` as
>>> accessors to the tuple. This is symmetric with record field access
>>> "methods", and seems like a moderate ergonomic gain.
>>>
>>> Thoughts?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Tuple indexing?

[Aaron VonderHaar]

One reason `first` and `second` are only defined for 2-tuples is that it's
usually a better choice to use records if you have more than a couple
fields.

If defining a record type alias and giving names to you're fields doesn't
work for your situation, can you give more details about why?

On Dec 27, 2016 7:09 AM, "Mike MacDonald"  wrote:

> On a somewhat regular basis, I end up needing to extract a single field
> from a tuple provided from a third-party function. At the moment, I have to
> write a boilerplate function just to pattern match it out. If I need the
> second field of tuple of a different size, I need to write more boilerplate.
>
> Seeing as record filed names cannot start with digits, and the language
> only allows up to Tuple9, it would be nice to have `.0` through `.8` as
> accessors to the tuple. This is symmetric with record field access
> "methods", and seems like a moderate ergonomic gain.
>
> Thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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 can I iterate over the list of records to apply a function

[Aaron VonderHaar]

Hello, the answer depends a bit on what you intend to do with the Bools
after you have them...

But if, as you describe, you just want to end up with a List of Bools, then

List.map (\r -> r.age >= 21) yourRecords

But I expect you may also be interested in one of `List.filter`,
`List.all`, or `List.any`.
http://package.elm-lang.org/packages/elm-lang/core/5.0.0/List


On Mon, Dec 26, 2016 at 5:40 AM,  wrote:

> Hello,
> I am new to elm syntax. I have a list of records with name and age. I want
> to apply a test function to each record. The function takes one record as
> input and returns a boolean value. Depending on True or false, I want to
> take a specific action for each record. How can I implement this in elm? If
> it was Python, I will just iterate over each item in the list and pass it
> as a parameter to the 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.
>

-- 
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: Transducer.transduceList, stateful transducers, and foldr

[Aaron VonderHaar]

Hello, I'm the author of elm-transducers, and I will note that I haven't
used in an actual project, nor have I heard of many people using it.  So
it's certainly possible that there could be bug in the elm-transducers
package.

The code you mentioned:

transduceList = transduce List.foldr (::) []

does look unexpected; on reading that, I would expect foldl to be used
there instead.  Unfortunately I don't remember if there was a reason I used
foldr.  But I do remember that the test cases I used when developing it
were pretty thin since my focus at the time was getting the types to work.

On Sun, Dec 18, 2016 at 7:06 PM, Marshall handheld Flax <
m.droid.f...@gmail.com> wrote:

> Here's code that has a working "transduceList" variant that uses
> "List.foldl", but all of the List.reverse calls doesn't smell nice.  (Full
> context at https://github.com/marshallflax/lexical-elm/blob/
> master/src/BowlingScore.elm).  Any suggestions welcome!
>
> transduceListL : Transducer a b (List b) s -> List a -> List b
> transduceListL xform list =
> (transduce List.foldl (::) []) xform list |> List.reverse
>
> partitionBy : (List a -> Bool) -> Transducer a (List a) r (List a)
> partitionBy pred =
> { init =
> \reduce r -> ( [], r )
> , step =
> \reduce input ( hold, r ) ->
> let
> merged =
> input :: hold
> in
> if (pred merged) then
> ( [], reduce (List.reverse merged) r )
> else
> ( merged, r )
> , complete =
> \reduce ( hold, r ) ->
> if (List.isEmpty hold) then
> r
> else
> reduce (List.reverse hold) r
> }
>
> Thanks again!
>
> Marshall
>
>
>
> On Sunday, December 18, 2016 at 9:06:37 PM UTC-5, Marshall handheld Flax
> wrote:
>>
>> Suppose I have a *stateful* transducer
>>
>> partitionBy : (List a -> Bool) -> Transducer a (List a) r (List a)
>> partitionBy pred =
>> { init =
>> \reduce r -> ( [], r )
>> , step =
>> \reduce input ( hold, r ) ->
>> let
>> merged =
>> input :: hold
>> in
>> if (pred merged) then
>> ( [], reduce merged r )
>> else
>> ( merged, r )
>> , complete =
>> \reduce ( hold, r ) ->
>> if (List.isEmpty hold) then
>> r
>> else
>> reduce hold r
>> }
>>
>>
>> that "chunkfies" an input stream input into lists, where the supplid
>> predicate (List a -> Bool) determines when to start the next sublist.  (My
>> particular toy application is the standard "Bowling Kata" in which I need
>> to partition a stream of bowling throws into frames, but I think it could
>> be generally useful.)
>>
>> However, the "foldr" in the standard
>>
>> transduceList : Transducer a b (List b) s -> List a -> List b
>>
>> transduceList =
>>
>> transduce List.foldr (::) []
>>
>> means that the stateful processing occurs from the end, which is exactly
>> the opposite from what I need. (Since I need my state to be dependent upon
>> *earlier* messages, rather than *later* messages).
>>
>>
>> Am I making too much of this (i.e. should just use transduceArray and be
>> done with it)?  Or is there something problematic about stateful
>> transducers, in that different "folder" can result in different semantics?
>>
>>
>> Thanks!
>>
>> Marshall
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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

[Aaron VonderHaar]

What's confusing here is how currying works with infix operators.  It's
idiomatic in Elm to have your accumulator be the last argument, and, for
instance, if you were writing your own data type, you would want to write
your functions so that they can be chained together easily:

myMatrix
|> scale 2
|> subtract 5
|> subtractMatrix myOtherMatrix
|> normalize


But as an infix operator (-) is not able to follow that convention;

5
|> (-) 3
|> (-) 1

is confusingly equivalent to `(1 - (3 - 5))` rather than to `5 - 3 - 1`


If you had a function `subtract` such that

5 |> subtract 3 |> subtract 1 == (5 - 3 - 1)

then you could use that function with fold as you intend

List.foldl subtract 0 [1, 2, 3, 4]  ==  -10

You can achieve the same result with

List.foldl (flip (-)) 0 [1, 2, 3, 4]  ==  -10


Another way to put it is, in Elm, folds expand in the following way:

List.foldl f x [b, c, d]  ==  x |> f b |> f c |> f d
List.foldr f x [b, c, d]  ==  f b <| f c <| f d <| x


On Thu, Dec 8, 2016 at 7:50 PM, Kasey Speakman  wrote:

> (deleted and corrected original post with proper expansion of Elm's foldl)
>
> I know this is a really old thread, but I ran into this precise question
> and thought I would add a perspective.
>
> The form a -> b -> b is not left-building, regardless of the direction you
> are traversing the list.
>
> An example: Starting from zero, subtract the numbers 1, 2, and 3. The
> expected answer is -6.
>
> List.foldl (-) 0 [1, 2, 3]
> -> returns -6 in Haskell (well, actually tested in F# which uses same
> order as Haskell)
> expands to: ((0 - 1) - 2) - 3 = -6
> -> returns 2 in Elm
> expands to: 3 - ((1 - 0) - 2)
>
> Elm's expansion is wonky for this. It appears to be center-building:
> List.foldl (-) 0 [1] -- returns 1, expands 1 - 0
> List.foldl (-) 0 [1, 2] -- returns -1, expands (1 - 0) - 2
> List.foldl (-) 0 [1, 2, 3] -- returns 2, expands 3 - ((1 - 0) - 2)
> List.foldl (-) 0 [1, 2, 3, 4] -- returns -2, expands (3 - ((1 - 0) -
> 2)) - 4
>
> When a and b are the same type it will only return the correct answer if
> the fold operation is also commutative or if flip is used to correct the
> ordering. When a and b are not the same type, the compiler will provide an
> error for wrong ordering of course.
>
> I started out on the side that a -> b -> b was correct as that feels like
> proper "reduction" or chainable syntax. But after exploring it, it is
> clearly not left-building. Makes sense when you consider this form is used
> with pipe to convert right-building operations into left-reading code. e.g. a
> |> f |> g |> h instead of h (g (f a))
>
> On Tuesday, July 16, 2013 at 6:13:01 AM UTC-5, Evan wrote:
>>
>> Gotcha, I definitely see the reasoning :)
>>
>>
>> On Tue, Jul 16, 2013 at 12:54 PM, Balazs Komuves 
>> wrote:
>>
>>>
>>> I was not engaging in debate, religious or not (though I tend to have
>>> very strong opinions about these questions). I was explaining why I think
>>> Haskell uses the order it uses (because it is distinguished from a
>>> mathematical viewpoint). Of course you are not required to follow that
>>> convention, I was just pointing out that it is not simply an ad-hoc choice.
>>>
>>> Balazs
>>>
>>>
>>>
>>> On Tue, Jul 16, 2013 at 12:21 PM, Evan Czaplicki 
>>> wrote:
>>>
 I think this might be a religious debate on some level. My first
 functional languages were Scheme
 
 and Standard ML . The
 libraries I just linked both use the same argument order for foldl and
 foldr as in Elm. I was raised a certain way and it just stuck in my mind. I
 suspect that everyone prefers the order they learned first because it
 matches their mental model.

 I wrote up a bunch of "reasoning", but really, I am just engaging in
 the religious debate. I'd feel bad deleting it all though, so here is some
 of it:

 OCaml's list library
  does it
 the way you suggest. I find this order offensive on some level.

 The big questions for "physical" argument order are as follows:

- What is the type of `fold` or `reduce`? When you fold an
unordered thing, is it from the right or the left?
- What is the type of `foldp`? Which way does time go? Is this
cultural?

 I don't find these questions particularly useful, and I don't think
 programmers should have to wonder about them to use fold and foldp.

 At the end of the day, I chose the types on purpose. I find them easier
 to use, easier to teach, easier to understand. I want to keep them this 
 way.


 On Tue, Jul 16, 2013 at 10:40 AM, Balazs Komuves 

[elm-discuss] Getting functions out of the model

[Aaron VonderHaar]

As mentioned in some recent threads [1] [2], easing functions for
animations have been an example of where functions in the model are
currently used.  An alternative approach is to use a union type to indicate
the easing, but a suggested shortcoming of that approach is that there
would then be no way for downstream developers to use their own custom
easings.

I was just thinking that this could be achieved as follows:

```
type AdvancedEasing a
= Linear | InQuad | OutQuad | ...
| CustomEasing a

type alias Easing = AdvancedEasing Never

apply : Easing -> Float -> Float

applyAdvanced : (a -> Float -> Float) -> AdvancedEasing a -> Float -> Float
```

In this way, the custom easing functions (a -> Float -> Float) are moved
from the model to configuration.

I was curious if anyone has experimented with this approach yet.


[1]: https://groups.google.com/d/topic/elm-discuss/bOAHwSnklLc/discussion
[2]: https://groups.google.com/d/topic/elm-discuss/9qV9iDcv-c8/discussion

-- 
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] Making tangram logos

[Aaron VonderHaar]

For anyone who's been wanting an easy way to make nice-looking tangram
logos for their own Elm projects, I did a short livestream last week where
I made a small Elm module with some nice helper functions for quickly
assembling SVG tangram shapes.

Code is here: https://github.com/ElmLive/tangram-logo

You can watch me make a camera tangram for my ElmLive logo (takes just
under 10 minutes):  https://youtu.be/eMxwECIC7mc?t=47m56s

And you can watch the full video (~1hr) to see how I built the helper
functions: https://youtu.be/eMxwECIC7mc

(And apologies for the noisy audio in the recordings--I hadn't quite
figured out the best way to do the audio post-processing when I did this.)


Examples of the end results:
[image: Inline image 2]  [image: Inline image 1]

Example of what the resulting code looks like:

```
main : Svg msg
main =
let
big1 =
triangle 2
|> rotate 90

big2 =
triangle 2
|> rotate -90
|> snap 2 (to big1 3)

med =
triangle (sqrt 2)
|> rotate 225
|> snap 1 (to big1 2)
|> add ( 0, 0.5 )

par =
parallelogram
|> rotate 90
|> Pieces.flip
|> snap 3 (to med 1)
in
svg [ viewBox "-4 -5 10 10" ]
[ triangle 1
|> rotate 180
|> snap 2 (to big1 2)
|> draw colors.orange
, square
|> snap 3 (to big2 1)
|> draw colors.green
, triangle 1
|> rotate 0
|> snap 3 (to big2 1)
|> draw colors.orange
, med
|> draw colors.blue
, par
|> draw colors.green
, big1
|> draw colors.gray
, big2
|> draw colors.blue
]
```

-- 
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 to interpret missing fields as Nothing in ports?

[Aaron VonderHaar]

At NoRedInk, if we are passing complex data through a port, we generally
pass it as `Json.Value`, and then use a JSON decoder in Elm to transform it
into the appropriate type.  That way, you can write a decoder to handle
missing fields in whatever way you'd like.

On Thu, Oct 6, 2016 at 11:18 AM, Ed Ilyin  wrote:

> Hi,
>
> When you send record with Maybe fields to a port - Nothing values are
> converted to nulls.
> When you send json with null properties to firebase - firebase removes
> such properties (by design)
> When you try to receive record from port - how to force Elm to interpret
> missing fields as Nothing?
>
> I have seen old https://github.com/elm-lang/elm-plans/issues/17 and
> https://github.com/elm-lang/elm-compiler/issues/1007 issues
>
> What can I do except making conversion of each object in javascript?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Installing Elm Packages while Offline

[Aaron VonderHaar]

Yes, you can just copy the relevant packages in the `./elm-stuff/packages/`
folders of your projects.

On Thu, Oct 6, 2016 at 9:36 AM, Duane Johnson 
wrote:

> I'll be taking a long flight tomorrow and I'm curious if there's an easy
> way to install packages without the `elm package install` tool, which seems
> to require internet access.
>
> For instance, if I have a new project, and a "package" installed in
> another project that I've previously worked on, is there a way to install
> the package using the other directory as the "source" (rather than the
> internet)?
>
> Duane
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Problem with beginnerProgram

[Aaron VonderHaar]

Hello,

The error is saying that your view is producing messages that are
functions.  This is because your `onClick` is using `UpdateModel`, but
`UpdateModel` itself is not a message: `UpdateModel` needs a String value
to become a Msg.

Possible fixes would be:

1) Change UpdateModel to not take any parameters:

type Msg = UpdateModel

2) Pass a string to UpdateModel in your onClick:

button [ onClick (UpdateModel "ValueToSend") ] [ text "Ajouter" ]



On Thu, Oct 6, 2016 at 4:50 AM, Did  wrote:

> Hi there,
>
> I'm pretty new to elm and I'm facing an issue I can't resolve by myself...
>
> I would like to display a text entered in a textbox by clicking on a
> button. But elm detects an error with the definition of view. It says :
>
> -
>
> Detected errors in 1 module.
>
>
> -- TYPE MISMATCH --
> -
>
> The type annotation for `view` does not match its definition.
>
> 26| view: String -> Html a
>   
> The type annotation is saying:
>
> String -> Html a
>
> But I am inferring that the definition has this type:
>
> String -> Html (String -> Msg)
>
> Hint: A type annotation is too generic. You can probably just switch to
> the type
> I inferred. These issues can be subtle though, so read more about it.
>  hints/type-annotations.md>
>
> ---
>
> I really don't know what to do. If you can please explain how to resolve
> this, because I can't find anything that helps... Thanks for your time!
>
> Here is the code I wrote in http://elm-lang.org/try :
>
> import Html exposing (..)
> import Html.App as App
> import Html.Attributes exposing (..)
> import Html.Events exposing (..)
>
> main =
>   App.beginnerProgram {
> model = init "",
> update = update,
> view = view
>   }
>
> init : String -> String
> init str =
>   str
>
> type Msg = UpdateModel String
>
> update: Msg -> String -> String
> update action model =
>   case action of
> UpdateModel newModel ->
>   newModel
>
> view: String -> Html a
> view model =
>   div[]
>   [
> input[type' "text", placeholder "Please enter a name..."][]
>,button [onClick UpdateModel][text "Ajouter"]
>,div[][text model]
>   ]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Does CSS model the right problem?

[Aaron VonderHaar]

You may be interested in looking at Auto Layout for Mac and iOS apps.
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/AutolayoutPG/index.html

It uses a system of linear equations to solve the defined layout
constraints.

On Sep 25, 2016 4:47 PM, "Duane Johnson"  wrote:

> Cascading Style Sheets are a way of selecting elements of a document and
> describing their properties.
>
> At a high level, as a designer (be gentle as I pretend to be a designer),
> I want to precisely articulate certain requirements of the properties of a
> website, while playing with (i.e. allowing variability) in another set of
> properties.
>
> For instance, it may be important to require that the contrast ratio
> between adjacent colors is high--whether for minimal legibility or for
> older eyes. Perhaps what the actual colors are will matter less, but it's
> also possible that the colors should adhere to various rules of Color
> Theory--triadic schemes, compound schemes, or analogous schemes for
> instance.
>
> As another example, I may want to require that a certain amount of space
> exists between columns, or between major components such as a navbar and
> main block. The style of the elements doesn't matter as much as the
> relationship between or among elements.
>
> Many times, when I'm developing a website, the concept of a CSS "class
> name" isn't really useful until development nears the end. The reason for
> this is that the structure of pages and knowledge about what styles are
> repeated and conserved among elements is being developed *simultaneously*.
>
> I think if we were to extend the Elm-esque way of incremental and
> rewarding development into the world of CSS, we would need to take a step
> back from what CSS models and ask what we should be modeling.
>
> Right now, I'm thinking that in an ideal world, I would be able to specify
> the important requirements of a website's styles, and then allow it to
> automatically generate the rest. As I go, I'd like to tweak the
> requirements and play with the autogenerated values until I arrive at a
> desirable structure and visually appealing website.
>
> As I develop the HTML side of the website, I'd like Elm to automatically
> "constrain" the new HTML's styles to those of the existing requirements.
>
> It sounds like what I want is a constraint solver.
>
> Has there been any research into this area in other languages?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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 and contenteditable

[Aaron VonderHaar]

Peter, I'd guess the decoder in your onChange is failing, causing the event
not to send a Msg. The decoder is going to get an event object, not a DOM
node, which is probably why decoding an "innerHTML" property is failing.
(Did your comment mean that your event handler does work for
non-contentEditable divs?)

On Aug 30, 2016 2:46 AM, "Peter Damoc"  wrote:

> I've tried a naive implementation in Elm but, for some reason, it doesn't
> work (events are not fired for divs that have content editable)
>
> import Html exposing (..)
> import Html.Attributes exposing (..)
> import Html.App exposing (beginnerProgram)
> import Html.Events exposing (on)
> import Json.Encode as JE
> import Json.Decode as JD exposing ((:=))
>
>
> main =
>   beginnerProgram { model = "", view = view, update = update }
>
>
> onContent tagger =
>   on "input" (JD.map tagger ("innerHTML" := JD.string))
>
> view model =
>   div []
> [ div [property "innerHTML" (JE.string model), onContent OnChange,
> contenteditable True][]
> ]
>
>
> type Msg = OnChange String
>
>
> update msg model =
>   case (Debug.log "msg:" msg) of
> OnChange str -> str
>
>
>
>
>
>
> On Tue, Aug 30, 2016 at 12:03 PM, Vincent Jousse 
> wrote:
>
>> Hello,
>>
>> I'm writing an application where the user needs to edit some HTML
>> content. When I first wrote this application in JS, I was using some
>> contenteditable fields to do so.
>>
>> How should I handle this with Elm? My problem is that if I set a div with
>> contenteditable=true in elm, and that the content of this div depends on my
>> model state, when an user edits the HTML, my model is now out of sync.
>> Maybe getting the innerHTML field when the user is changing the content
>> of the div and set this to a field in my model? But how would I do to
>> convert this string back to some Html.div/Html.span/whatever code in Elm?
>> The tricky part is that I need to handle events on spans that are in the
>> div with contenteditable=true.
>>
>> I tried to do it using Ports and Draft-js but the problem is that I now
>> have 2 states in my application: one in Elm and one in JS/React. Then, all
>> the beauty of "my application just depends on my Elm model state" is not
>> true anymore, as I know need to sync the 2 states…
>>
>> Not sure if I'm really clear, but thanks for reading this anyway ;-)
>>
>> --
>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Dependency problems building elm-make from source

[Aaron VonderHaar]

(also, cabal version 1.22)

On Mon, Aug 15, 2016 at 10:27 PM, Aaron VonderHaar <gruen0aer...@gmail.com>
wrote:

> I believe you will need to use ghc 7, not ghc 8.  (elm-compiler's CI uses
> ghc-7.10.1, but ghc-7.10.3 should probably work fine as well.)
>
> On Sun, Aug 14, 2016 at 8:04 PM, Kofi Gumbs <h.kofigu...@gmail.com> wrote:
>
>> I came across this thread
>> <https://github.com/elm-lang/elm-platform/issues/63> which was very
>> insightful. I was building on a Mac, but everything is fine after spinning
>> up a vagrant box and following this blog post
>> <https://alphydan.svbtle.com/elm-lang-on-ubuntu-14-04>. Hope this helps
>> some potential contributor in the future!
>>
>>
>> On Sunday, August 14, 2016 at 4:46:38 PM UTC-6, Kofi Gumbs wrote:
>>>
>>> Hello all,
>>>
>>> I've tried to build the elm tools locally in a couple of ways, but I am
>>> having trouble resolving the dependency graph. I am really only interested
>>> in elm-make, but I've tried the recommended BuildFromSource.hs script
>>> <https://github.com/elm-lang/elm-platform/blob/master/installers/BuildFromSource.hs>
>>>  as
>>> well. Here are the results from both approaches (cabal-install version
>>> 1.24.0.0, GHC version 8.0.1):
>>>
>>> *1) Just elm-make – OUTPUT
>>> <https://gist.github.com/hkgumbs/9c5bd3efc8cec8d51a643864621ee25a>*
>>> # ~/Workspaces/elm-make (git)-[0.17.1]-
>>>
>>> $ cabal sandbox delete
>>> $ cabal sandbox init
>>> $ cabal sandbox add-source ../elm-compiler  # both of these are also on
>>> 0.17.1
>>> $ cabal sandbox add-source ../elm-package
>>> $ cabal install -j --only-dependencies --ghc-options="-w"  # these
>>> flags are from the BuildFromSource.hs script (I've also tried without them)
>>>
>>>
>>> *2) BuildFromSource.hs – OUTPUT
>>> <https://gist.github.com/hkgumbs/fe48186e72f1c1357441f1185543662b>*
>>>
>>> # ~/Workspaces
>>>
>>> $ rm -rf Elm-Platform BuildFromSource.hs
>>> $ wget https://raw.githubusercontent.com/elm-lang/elm-platform/mast
>>> er/installers/BuildFromSource.hs
>>> $ runhaskell BuildFromSource.hs 0.17.1
>>>
>>>
>>>
>>> I am not very familiar with cabal dependency management but I suspect I
>>> am missing some --constraint. Has anyone seen / resolved this problem
>>> before? I haven't had success googling this particular issue, but I have a
>>> nagging feeling that it's documented somewhere.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to 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: Dependency problems building elm-make from source

[Aaron VonderHaar]

I believe you will need to use ghc 7, not ghc 8.  (elm-compiler's CI uses
ghc-7.10.1, but ghc-7.10.3 should probably work fine as well.)

On Sun, Aug 14, 2016 at 8:04 PM, Kofi Gumbs  wrote:

> I came across this thread
>  which was very
> insightful. I was building on a Mac, but everything is fine after spinning
> up a vagrant box and following this blog post
> . Hope this helps
> some potential contributor in the future!
>
>
> On Sunday, August 14, 2016 at 4:46:38 PM UTC-6, Kofi Gumbs wrote:
>>
>> Hello all,
>>
>> I've tried to build the elm tools locally in a couple of ways, but I am
>> having trouble resolving the dependency graph. I am really only interested
>> in elm-make, but I've tried the recommended BuildFromSource.hs script
>> 
>>  as
>> well. Here are the results from both approaches (cabal-install version
>> 1.24.0.0, GHC version 8.0.1):
>>
>> *1) Just elm-make – OUTPUT
>> *
>> # ~/Workspaces/elm-make (git)-[0.17.1]-
>>
>> $ cabal sandbox delete
>> $ cabal sandbox init
>> $ cabal sandbox add-source ../elm-compiler  # both of these are also on
>> 0.17.1
>> $ cabal sandbox add-source ../elm-package
>> $ cabal install -j --only-dependencies --ghc-options="-w"  # these flags
>> are from the BuildFromSource.hs script (I've also tried without them)
>>
>>
>> *2) BuildFromSource.hs – OUTPUT
>> *
>>
>> # ~/Workspaces
>>
>> $ rm -rf Elm-Platform BuildFromSource.hs
>> $ wget https://raw.githubusercontent.com/elm-lang/elm-platform/mast
>> er/installers/BuildFromSource.hs
>> $ runhaskell BuildFromSource.hs 0.17.1
>>
>>
>>
>> I am not very familiar with cabal dependency management but I suspect I
>> am missing some --constraint. Has anyone seen / resolved this problem
>> before? I haven't had success googling this particular issue, but I have a
>> nagging feeling that it's documented somewhere.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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: Record update syntax

[Aaron VonderHaar]

Can you give more details about an example of where doing nested record
updates is useful?  When I've run into nested records in real projects,
usually it's a better choice to remove the nested update.  Here are two
ways to do that:

1) flatten the record

This is appropriate when a single module is dealing with a bunch of things
that don't actually need to be nested:

Instead of this:
type alias Course =
{ teacher : { id : Int, name : String } }

Try this:
type alias Course =
{ teacherId : Int
, teacherName : String
}


2)  make the nested thing into a module

This is appropriate when it makes sense to have functions that manipulate
the nested thing.

Instead of this:
moveSpaceshipEast ship =
let
oldPosition = ship.position
newPosition = { oldPosition | x = oldPosition.x + 1 }
in
{ ship | position = newPosition }

Try this:
moveSpaceshipEast ship =
{ ship | position = Position.addX 1 ship.position }

module Position
addX dx position =
{ position | x = position.x + dx }



On Sun, Aug 14, 2016 at 11:28 AM, OvermindDL1  wrote:

>
> Lists/Dicts/Records do have different interfaces, however if Elm had HKT's
> it would not need to, you could have a generic 'map' function that works
> over all of them, a generic fold, etc... and so forth (See Haskell).
>
> However note the List Access is what would define the required structure
> of the thing that would be passed in, that is resolvable in the type system
> quite easily (at least with HKT's, unsure otherwise).
>
> However, ignoring other types and just doing it for records you could do
> it with the current Elm type system 'if' we get some kind of way to set a
> record value via an argument, I.E. we could create all the proposed
> getters/setters 'now' on just records if we get a function that acts
> something like:
> ```elm
> Record.set : RecordID record id -> id_type -> { record | id : id_type }
> Record.set id val rec = 
> ```
> That allows type-safe enforcement of a key ID.
> Where you could use it like:
> ```elm
> model = { something=0 }
> newModel = Record.set 42 model
> newModel == { something=42 }
> ```
> Basically Elm needs something like Ocaml's Field(s) functions:
> ```ocaml
> Field.t # Type declaration for following inputs/outputs
> Field.name # Get the name of a record field
> Field.get # Get the value of a record field
> Field.fset # Functionally set the value of a record field, returning the
> new record with the new field value
> ```
> Which can be used like (remember Ocaml's type system is exceedingly strict
> with no HKT support, it's type system is not as advanced as, say,
> Haskell's):
> ```ocaml
> module Model = struct
>   type t =
> { something : int
> };;
> end
> module Model :
>   sig
> type t =
>   { something : int;
>   }
>   end
>
> let model = { Model.
>   something = 42;
> };;
>
> let name = Field.name Model.Fields.something model;; # Returns a string of
> "something"
>
> let val = Field.get Model.Fields.something model;; # Returns an int of 42
>
> let newModel = Field.fset Model.Fields.something 3 model # Returns the
> structure of { something = 3 }
> ```
>
> So yes it is very possible in the normal Elm type system as Ocaml's is
> similarly restricted.  As I recall Ocaml is using the functional idiom
> called Lenses in its field work to do that (lot of packaging access up in
> functions, but does require a record to have more data, like adding an
> implicit RecordName.Fields thing or so, or make better syntax for it).
>
> With proper HKT's, like with Haskell, then fully type-safe we could have
> very powerful, generic, and simple syntax such as this:
> ```haskell
> -- Given these simplified types:
> data Model = Model { something :: SomeSubData }
>
> data SomeSubData = SomeSubData { moreThing :: Integer }
>
> -- And given this value
> where
>   model = Model (SomeSubData 42)
>
>
> -- You could do the way that Elm does now (although elm has the existing
> record inside the {} and haskell has it outside, so this is how haskell
> does it):
> newModel = model {
>   something = (something model) {
> moreThing = moreThing (something model) + 1
> }
>   }
>
>
> -- The above set newModel as { something = { moreThing = 43 } } in Elmish
> parlance, and is very similar to how it is done in Elm itself, however
> Haskell has HKT's, which allow for a variety of other methods such as:
>
>
> -- references+lenses (not possible to do anything even remotely like this
> in Elm right now due to not being able to operate over types, but it is the
> most succinct):
> $(mkLabels [ 'Model, 'SomeSubData ]) -- Only need to do this once
>
> newModel = modify (+1) (moreThing . something) model
>
>
> -- SYB (A generic library that handles tasks like this with is, it comes
> bundled with Haskell
> incMoreThing v s@(SomeSubData moreThing) = s { moreThing = moreThing + v
> } -- Per change you want to make anywhere in the record path
>
> 

Re: [elm-discuss] How do I organize "inheritance" between my data types?

[Aaron VonderHaar]

To restate my previous post, I think you should spend some time considering
whether you actually have a case where you need to write code that deals
with both Customers and Employees, or whether you are just asking because
you would use inheritance if you were using an OO language.  Making a
"generic" Person type won't necessarily help you because you still have to
create all the values.  If they are coming from a database, then it's
likely that employees and customer will be coming from different tables and
possibly from different backend APIs.  I'd also be curious about what UI
you are trying to implement that needs customers and employees to be
handled in the same way.  At NoRedInk, we have several different user
types: teachers, students and admins, but most pages in our app treat
teachers and students completely differently in the UI, so there's no need
for a "Person" type.  We do have an admin page that shows a list of all
users, but for that page we have a "User" model and there's no need for the
Teacher and Student types on that page.


But if you do really need a Person type, if you had independent Person,
Customer, and Employee modules with `toPerson` functions as I suggested
before, then you can reuse any functions in the Person module with
Customers and Employees by using function composition.  If you are still
concerned about duplicating code, you may also choose to implement Customer
and Employee such that `toPerson` is as simple as `toPerson customer =
customer.person`.  I believe having small, composable functions and
independent modules is preferable to having an interconnected system of
types.


Another way to consider is this:

type alias Person =
{ name : String
, address : String
, employeeInfo : Maybe EmployeeInfo
, customerInfo : Maybe CustomerInfo
}

(Note that modeling this way allows for a person to be both a customer and
an employee at the same time, which may be something you need.)  This is
similar to what you originally proposed, but I think it will probably lead
to a bit cleaner code because you don't need `PersonType`.


You can also use extensible records as others noted, but it's unlikely that
you actually need that much complexity for whatever you are trying to do
with Employees and Customers.


On Sun, Jul 17, 2016 at 5:37 PM, Leonardo Sá <leolim...@gmail.com> wrote:

> I think the idea is that both Employees and Customers are Persons - as in,
> they have shared fields such as name and address. So potentially we could
> write functions that operate directly on Person without caring whether the
> person is an employee or a customer, and we'd write functions that operate
> directly on Employee or Customers without losing the context that they are
> in fact Persons. Just as you'd have in OO, where Person is the base class
> for Employee and Customer.
>
> Or maybe I am just too stuck on my OO ways.
>
> Sorry I can't provide more details (the lawyers would kill me)! That, and
> the schema I'm trying to work with is really convoluted.
>
> But what it boils down to is: how does one emulates a traditional OO
> inheritance with ADTs, in such a way that I can write functions that
> operate on the base class, and functions that operate on child classes, and
> it's all type safe?
>
> On Sunday, July 17, 2016 at 7:13:33 PM UTC-5, Aaron VonderHaar wrote:
>>
>> Can you give more details about what you are trying to do that requires a
>> Person type that can be either an employee or a customer?  As you noted,
>> `nameAndDepartment` would only apply to Employees, so why do you need to
>> use it on Customers?  Can you simply deal with employees and customers
>> independently?
>>
>> If you do really need to have a Person type, my first thought would be to
>> have Person be an independent module, and have Employee.toPerson and
>> Customer.toPerson.  That way all the modules can be independent w/r to the
>> way the data is modeled and will have more stable interfaces than if you
>> try to have a Person type that depends on both the Employee and Customer
>> types.
>>
>> On Sun, Jul 17, 2016 at 4:06 PM, Leonardo Sá <leol...@gmail.com> wrote:
>>
>>> Short question:
>>>
>>> What is the best way to create relationships between my types so it is
>>> easy to access data present in both types?
>>>
>>> Long question:
>>>
>>> Suppose I have the following types:
>>>
>>> type alias Person =
>>>   { name : String
>>>   , address : String
>>>   , personType : PersonType
>>>   }
>>>
>>> type alias Employee =
>>>   { department : String }
>>>
>>> type alias Customer =
>>>   { itemsPurchased : Int }
>>

Re: [elm-discuss] How do I organize "inheritance" between my data types?

[Aaron VonderHaar]

Can you give more details about what you are trying to do that requires a
Person type that can be either an employee or a customer?  As you noted,
`nameAndDepartment` would only apply to Employees, so why do you need to
use it on Customers?  Can you simply deal with employees and customers
independently?

If you do really need to have a Person type, my first thought would be to
have Person be an independent module, and have Employee.toPerson and
Customer.toPerson.  That way all the modules can be independent w/r to the
way the data is modeled and will have more stable interfaces than if you
try to have a Person type that depends on both the Employee and Customer
types.

On Sun, Jul 17, 2016 at 4:06 PM, Leonardo Sá  wrote:

> Short question:
>
> What is the best way to create relationships between my types so it is
> easy to access data present in both types?
>
> Long question:
>
> Suppose I have the following types:
>
> type alias Person =
>   { name : String
>   , address : String
>   , personType : PersonType
>   }
>
> type alias Employee =
>   { department : String }
>
> type alias Customer =
>   { itemsPurchased : Int }
>
> type PersonType = EmployeeType Employee | CustomerType Customer
>
> Then I think it's not straight forward to write a function that retrieves
> me the department and name for an employee:
>
> nameAndDepartment : Person -> (String, String)
>
> It seems to me this function would be a Maybe (String, String) and return
> Nothing if the Person is not an Employee. But in that case, I am relying on
> the runtime to type check things for me, which tells me there is probably a
> better way to structure this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Markdown library

[Aaron VonderHaar]

Did you try deleting your `elm-stuff` directory and building again?

On Wed, Jul 13, 2016 at 9:07 AM, Esteban Manchado Velázquez <
emanch...@gmail.com> wrote:

> Hi,
>
> I'm trying to use the Markdown library (evancz/elm-markdown) and I cannot
> seem to be able to make it work. I ran:
>
>elm-package install evancz/elm-markdown
>
> and got version 3.0.0, apparently the only one that works with Elm 0.17,
> what I'm using. However, when I try to compile the project, it complains:
>
>elm-make:
> elm-stuff/build-artifacts/0.17.1/evancz/elm-markdown/3.0.0/Markdown.elmo:
> openFile: does not exist (No such file or directory)
>
> The directory exists, but only has a file graph.dat. However, in
> elm-stuff/packages I can see what seems to be the whole distribution, with
> Markdown.elm and Native/Markdown.js.
>
> Is that a bug somewhere, did I do something stupid?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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] Newbie question: having trouble using the Focus library

[Aaron VonderHaar]

To do this without focus, you’d write something like:

updateCanvas : (Canvas -> Canvas) -> Model -> Model
updateCanvas fn  model =
{ model | canvas = fn model.canvas }

updateScale : (Int -> Int) -> Canvas -> Canvas -- probably put this in
Canvas module
updateScale fn canvas =
{ canvas | scale = fn canvas.scale }

inc x = x + 1

-- then in update...
newModel = updateCanvas (updateScale inc) model

Another technique to avoid using focus is to have a flatter data structure
using extensible records (as described here
https://groups.google.com/d/msg/elm-discuss/g_hxu-tjzUQ/ah30ic4zHTQJ )

Finally, to answer your question, when using Focus, you have to define
canvas and scale yourself—they are not generated automatically. You would
write something like this (note the similarity to the updateCanvas and
updateScale functions in my first suggestion above):

canvas : Focus Model Canvas
canvas =
Focus.create
.canvas
(\fn model -> { model | canvas = fn model.canvas })

scale : Focus Canvas Int
scale =
Focus.create
.scale
(\fn canvas -> { canvas | scale = fn canvas.scale })

​

On Sun, Jun 19, 2016 at 3:58 AM,  wrote:

> I want to use the focus library to update a nested property per this
> example from the docs
> :
>
> set (physics => velocity => x) 0 object
>
>
>
> My model is like this:
>
>   0 { canvas =
>   1 { width = 800
>   2 , height = 600
>   3 , scale = 1
>   4 , ratioToWorld = 10
>   5 }
>   6 , player = player
>   7 , enemy = enemy
>   8 }
>
>
> My update code is this:
>
>   0 update : Msg -> Model -> (Model, Cmd Msg)
>   1 update action model =
>   2   case action of
>   3 Step time ->
>   4   let
>   5 newScale = model.canvas.scale + 1
>   6 newModel = Focus.set (canvas => scale) newScale model
>   7   in
>   8 (newModel, Cmd.none)
>   9 NoOp ->
>  10   (model, Cmd.none)
>
> Initially I had a great deal of trouble with the compiler complaining
> about the "=>" operator but I got lucky and found a code example in github
> somewhere that showed me how to import it from the module with this:
>
>   0 import Focus
>   1 import Focus exposing ((=>))
>
>
> But I'm still getting syntax errors where it complains that it doesn't
> know what canvas, scale etc are:
> Detected errors in 1 module.
>
>
>
> -- NAMING ERROR - ././
> Update.elm
>
> Cannot find variable `canvas`
>
> 17| newModel = Focus.set (canvas => scale) newScale model
>   ^^
>
> -- NAMING ERROR - ././
> Update.elm
>
> Cannot find variable `scale`
>
> 17| newModel = Focus.set (canvas => scale) newScale model
> ^
> Maybe you want one of the following?
>
> List.scanl
>
>
> Any help with what I'm doing wrong would be appreciated.  I could work how
> to do it without using Focus but I plan/hope to use Focus a lot.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 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.