Re: [elm-discuss] Re: elmvm (Elm Version Manager)

[Rehno Lindeque]

> Looks very clever, not something I had ever looked into before. Do you 
> have to run NixOS or is nix something that you can run on top of any 
> distribution? (I'm a long time Debian user). 
>

Nix itself is just a cross-platform package manager, independent of the 
operating system NixOS. (Though, NixOS is pretty amazing by itself.)

https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html is 
one of the best known introductions I think (but note that Ollie wrote this 
in 2014). 
http://ebzzry.io/en/nix/#developmentenvironment might also be a good spot 
to start. 
 

-- 
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: elmvm (Elm Version Manager)

['Rupert Smith' via Elm Discuss]

On Thursday, April 6, 2017 at 6:34:09 PM UTC+1, Rehno Lindeque wrote:
>
> I'm a little surprised that more people haven't tried nix for pinning 
> their Elm tools... E.g. pop a shell.nix file like this into your project 
> root and you'll have it pinned to elm 0.18 indefinitely:
>

Looks very clever, not something I had ever looked into before. Do you have 
to run NixOS or is nix something that you can run on top of any 
distribution? (I'm a long time Debian user). 

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

[elm-discuss] Re: Is there a way to get a compile-time error when a field is added to a record type but its corresponding JSON encoder is not?

[Ian Mackenzie]

Also, not a compile-time check, but one other thing I like to do is add fuzz 
tests 
 
that verify that my encoders and decoders are actually inverses of each 
other. I create fuzzers for all of my types, and have a generic jsonRoundTrips 
test 
that takes a fuzzer, an encode function and decode function. It checks that 
for every value produced by the fuzzer, encoding the value and then 
decoding succeeds and gives you back the original value. Then the compiler 
can tell you about any problems in your decoder (since it will force you to 
provide a value for each field in your record when constructing it), and 
the tests will tell you about any problems in your encoder (since if you 
forget a field when encoding, then decoding will fail). Not to mention that 
the test will also catch other silly errors like Encode.object [ ( 
"firstName", Encode.string person.firstName ), ( "lastName", Encode.string 
person.firstName ) ].

On Friday, 7 April 2017 10:24:23 UTC-4, Ian Mackenzie wrote:
>
> You could change the signature instead of the definition:
>
> accountToJson : { id : Int, name : String } -> Json.Encode.Value
> accountToJson act = Json.Encode.object
>   [ ("id", Json.Encode.int act.id)
>   , ("name", Json.Encode.string act.name)
>   ]
>
> For example, https://ellie-app.com/RcvWmTyWFga1/0 triggers a compile 
> error but if you remove the address field then the encoder compiles again.
>
> On Friday, 7 April 2017 08:48:25 UTC-4, Andres Riofrio wrote:
>>
>> For example, I have the following code:
>>
>> type alias Account =
>>   { id : Int
>>   , name : String }
>>
>> -- ... in another module ...
>>
>> accountToJson : Account -> Json.Encode.Value
>> accountToJson act = Json.Encode.object
>>   [ ("id", Json.Encode.int act.id)
>>   , ("name", Json.Encode.string act.name)
>>   ]
>>
>> If I add a field to Account, I'd like the compiler to make sure it won't 
>> be skipped in the output JSON. The way I have written the encoder, the 
>> compiler will happily let me skip the field in the serialized version of my 
>> data.
>>
>> I thought about using destructuring like so:
>>
>> accountToJson : Account -> Json.Encode.Value
>> accountToJson {id, name} = Json.Encode.object
>>   [ ("id", Json.Encode.int id)
>>   , ("name", Json.Encode.string name)
>>   ]
>>
>>
>>
>> But according to the documentation 
>> , this will compile 
>> fine even if Account gains a new record.
>>
>> Any ideas on how to add this bit of type-safety to my application?
>>
>

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

[elm-discuss] Re: Is there a way to get a compile-time error when a field is added to a record type but its corresponding JSON encoder is not?

[Ian Mackenzie]

You could change the signature instead of the definition:

accountToJson : { id : Int, name : String } -> Json.Encode.Value
accountToJson act = Json.Encode.object
  [ ("id", Json.Encode.int act.id)
  , ("name", Json.Encode.string act.name)
  ]

For example, https://ellie-app.com/RcvWmTyWFga1/0 triggers a compile error 
but if you remove the address field then the encoder compiles again.

On Friday, 7 April 2017 08:48:25 UTC-4, Andres Riofrio wrote:
>
> For example, I have the following code:
>
> type alias Account =
>   { id : Int
>   , name : String }
>
> -- ... in another module ...
>
> accountToJson : Account -> Json.Encode.Value
> accountToJson act = Json.Encode.object
>   [ ("id", Json.Encode.int act.id)
>   , ("name", Json.Encode.string act.name)
>   ]
>
> If I add a field to Account, I'd like the compiler to make sure it won't 
> be skipped in the output JSON. The way I have written the encoder, the 
> compiler will happily let me skip the field in the serialized version of my 
> data.
>
> I thought about using destructuring like so:
>
> accountToJson : Account -> Json.Encode.Value
> accountToJson {id, name} = Json.Encode.object
>   [ ("id", Json.Encode.int id)
>   , ("name", Json.Encode.string name)
>   ]
>
>
>
> But according to the documentation 
> , this will compile 
> fine even if Account gains a new record.
>
> Any ideas on how to add this bit of type-safety to my application?
>

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

Re: [elm-discuss] Is there a way to get a compile-time error when a field is added to a record type but its corresponding JSON encoder is not?

[Peter Damoc]

To my understanding, the only way to add that kind of safety is to
implement a build plugin that analyzes your encoders.

The encoder code is perfectly valid because you might not want to encode
everything from a record so, Elm will allow you to do that just like it
will allow you to name those JSON field whatever you like (even misspelled
names of your record fields)




On Fri, Apr 7, 2017 at 8:37 AM, Andres Riofrio  wrote:

> For example, I have the following code:
>
> type alias Account =
>   { id : Int
>   , name : String }
>
> -- ... in another module ...
>
> accountToJson : Account -> Json.Encode.Value
> accountToJson act = Json.Encode.object
>   [ ("id", Json.Encode.int act.id)
>   , ("name", Json.Encode.string act.name)
>   ]
>
> If I add a field to Account, I'd like the compiler to make sure it won't
> be skipped in the output JSON. The way I have written the encoder, the
> compiler will happily let me skip the field in the serialized version of my
> data.
>
> I thought about using destructuring like so:
>
> accountToJson : Account -> Json.Encode.Value
> accountToJson {id, name} = Json.Encode.object
>   [ ("id", Json.Encode.int id)
>   , ("name", Json.Encode.string name)
>   ]
>
>
>
> But according to the documentation
> , this will compile
> fine even if Account gains a new record.
>
> Any ideas on how to add this bit of type-safety to my application?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

[elm-discuss] Is there a way to get a compile-time error when a field is added to a record type but its corresponding JSON encoder is not?

[Andres Riofrio]

For example, I have the following code:

type alias Account =
  { id : Int
  , name : String }

-- ... in another module ...

accountToJson : Account -> Json.Encode.Value
accountToJson act = Json.Encode.object
  [ ("id", Json.Encode.int act.id)
  , ("name", Json.Encode.string act.name)
  ]

If I add a field to Account, I'd like the compiler to make sure it won't be 
skipped in the output JSON. The way I have written the encoder, the 
compiler will happily let me skip the field in the serialized version of my 
data.

I thought about using destructuring like so:

accountToJson : Account -> Json.Encode.Value
accountToJson {id, name} = Json.Encode.object
  [ ("id", Json.Encode.int id)
  , ("name", Json.Encode.string name)
  ]



But according to the documentation 
, this will compile fine 
even if Account gains a new record.

Any ideas on how to add this bit of type-safety to my application?

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