[elm-discuss] Re: On Intl/CLDR

[Ian Mackenzie]

Exposing window.Intl directly also ties Elm more tightly to the 
browser/JavaScript environment, which Evan mentioned in that second linked 
thread that he is trying to avoid:

Elm is designed to be 100% independent of JS. It happens to compile to JS 
> now because that was the right thing to do, but in a decade, I expect we'll 
> be compiling to something more efficient. There is a small set of "native" 
> stuff for now, but that means supporting the entire ecosystem on a new 
> platform is fairly easy.
>

So Elm could currently use window.Intl, but that would mean its 
functionality would have to be replicated exactly if Elm ever compiles to a 
non-browser environment. Even now that would make life a bit more difficult 
for people using Elm code within Node applications - it's possible, but you 
have to do things like hook up a third-party XMLHttpRequest implementation 
like xhr2 . If it's not too hard, it's 
probably better to reimplement the functionality in pure Elm so that it can 
be used on any platform that Elm compiles to in the future.

On Saturday, 9 September 2017 10:49:31 UTC-4, Vlad GURDIGA wrote:
>
> Hey everybody! 
>
> The other day I found myself writing a function to format numbers 
> .
>  
> The first question was: What is the right way to format a number? There 
> should be a standard or something. 樂 Googled a bit and found about the 
> Unicode CLDR Project . They have a huge amount 
> of structured data, and I surely found the data I was looking for. 邏
>
> Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an 
> Elm library that’l hold all that? elm-cldr?  Oh, it’d be enormous… What 
> if I only need number formatting? Oh, I know: elm-cldr-numbers! 
> and elm-cldr-dates! and elm-cldr-localenames! and… Ooooh yeah!! 鸞
>
> Then I remember that the CLDR website was saying that they provide data 
> for apps and operating systems. Hm… shouldn’t it be there already somewhere 
> in the OS? 樂 Googled a bit more and found that browsers already have that 
> as window.Intl 
> 
>  and 
> MDN says it has quite good support, down to IE11. Couldn’t believe that 
> one, so spun up my Windows VM and pasted a snippet into IE11’s console: it 
> worked! 
>
> Hm… OK… Now, it’d really be quite cool to build all those elm-cldr-* 
> things that I imagined, wouldn’t it make more sense to reuse what’s already 
> there? What would it be like to use that? OK, let’s go native! A couple 
> hours later I got myself Native.Intl 
> .
>  
> 
>
> Now, looking at all this I begun wondering what would it be like to have 
> it in the Elm standard library, and inevitably found Evan’s 2 threads (one 
>  and two 
> ) about the 
> philosophy around native in Elm, and I kind of see his point about keeping 
> Elm high-quality, but how about cases like this where we’re not talking 
> about JS libraries but about browser’s native APIs like Intl? 樂
>
> It’d probably be not that hard to get that data 
>  packaged into a few Elm 
> libraries, hopefully not-that-large each, but it’d still end up growing the 
> final app bundles, and probably some compilation time during the hundreds 
> of refreshes a day that a dev does… So I’m not entirely sure it’s a 
> constructive idea. 
>
> So although for my little toy-project I can just use Elm native, how about 
> long-term? What would make more sense? I mean these two options:
>
>1. implement Elm libraries using the CLDR data 
>
>2. hope that window.Intl will some day become part of Elm standard 
>library
>
> What are some pros and cons? Are there any other options people have 
> considered? 樂
>

-- 
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] Strange compiler error - cannot find a field that is obviously there.

[Ian Mackenzie]

Have you added type annotations to all top-level functions/values? My first 
guess would be some sort of type inference issue that's propagating across 
files, which can usually be narrowed down by explicitly annotating 
top-level stuff so that any discrepancies are caught as soon as possible.

On Saturday, 9 September 2017 04:54:28 UTC-4, Vlad GURDIGA wrote:
>
> Hey Rupert! 
>
> If I try to pull out just an isolated example to make an SSCCE out of... 
>> the problem goes away.
>
>
> Hm… this is interesting! 樂
>
> I’m wondering what are other factors that could lead to that issue, which 
> you have in the production context but not in SSCCE?
>
> I haven’t seen mentioned your environment: Elm version? Operating System? 
> The IDE or text editor? Could you please enumerate those? 邏
>

-- 
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: Json file size

[Ian Mackenzie]

I suspect there will be a way of making this work without dropping into JS. It 
looks like you're hitting some sort of very deep recursion which is causing a 
stack overflow - try seeing if you can isolate which of your function calls is 
triggering the stack overflow, and see if you can change some function from 
recursive to non-recursive (or tail recursive). If you have example code, that 
would also be helpful...

-- 
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] Discovering Elm packages

[Ian Mackenzie]

This is great! Already discovered a few interesting packages I didn't know 
about. Twitter feed followed =)

-- 
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] ADT: How to know whether two values have the same constructor?

[Ian Mackenzie]

I think I would opt for the very literal

type Bla
= A Int
| B Int


type BlaConstructor
= AConstructor
| BConstructor


blaConstructor : Bla -> BlaConstructor
blaConstructor bla =
case bla of
A _ ->
AConstructor

B _ ->
BConstructor


haveSameConstructor : Bla -> Bla -> Bool
haveSameConstructor firstBla secondBla =
blaConstructor firstBla == blaConstructor secondBla

The compiler will remind you to add a new case to the blaConstructor function 
when you add a new Bla constructor, and that in turn will prompt you to add 
a case to the BlaConstructor type - no tricky tuple matching required. I'm 
also guessing you can come up with a more meaningful name than 
'constructor' (perhaps 'kind' or something) that better indicates what it 
actually means for an object to have a particular constructor.

On Monday, 17 July 2017 13:22:56 UTC-4, David Andrews wrote:
>
> Similar code, with new cases enforced by the compiler
>
> haveSameConstructor : Bla -> Bla -> Bool
> haveSameConstructor first second =
> case (first, second) of
> (A _, A _) -> True
> (B _, B _) -> True
> (A _, _) -> False
> (B _, _) -> False
>
> On Jul 17, 2017 3:34 AM, "Birowsky"  
> wrote:
>
>> That's not so bad. But the compiler wouldn't be able to nudge me to add a 
>> new comparison when I add a new constructor in the Bla union.
>>
>> Thanx anyways.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[elm-discuss] Re: Linear algebra for 2d geometry?

[Ian Mackenzie]

On Tuesday, 9 May 2017 05:25:11 UTC-4, Rupert Smith wrote:
>
> Thanks for this explanation. Also, I did say in my OP that performance was 
> not such an important issue for me, as I am only rendering a relatively 
> static diagram that does not have a huge number of elements in it. I should 
> also concede that there is no guarantee that using 3x3 matrices would be 
> faster anyway, it depends on the implementation and the only real way to 
> know would be to set up a benchmark and measure and compare.
>
> So I decided to go with OpenSolid as it is a very nice library and has a 
> lot of features.
>

Great! Let me know if you run into anything. There are definitely lots of 
places where the implementation could be made more efficient - to start I 
implemented everything in the cleanest/simplest way I could think of, but 
over time I'm planning to go back and do some optimizations to avoid 
unnecessary object allocations and function calls. I've already done this 
in a few places, but if you do run into any performance bottlenecks let me 
know so I know where to focus next. (Apologies for the late reply, I was at 
a conference for the last couple of days...)
 

> I also cloned OpenSolid/svg and made a version that renders to 
> elm-community/typed-svg. Once I have finished converting the docs, tests 
> and examples you might like to clone it back again and publish it under 
> OpenSolid/typed-svg? I'll let you know once I get to that stage anyway.
>

I confess I'm still not sure exactly why a separate typed-svg version is 
necessary...since the TypedSvg.Core.Svg and TypedSvg.Core.Attribute are 
still just aliases for VirtualDom.Node and VirtualDom.Property respectively 
(instead of being new opaque types or something), you can already mix 
typed-svg and opensolid/svg elements/attributes freely without any kind of 
conversion or anything - see https://ellie-app.com/39pwNnwDzcqa1/2 for an 
example. To me the only difference is that a typed-svg version of 
opensolid/svg would depend on elm-community/typed-svg instead of 
elm-lang/svg and the internal implementation would be slightly different - 
but the exposed APIs would have exactly the same types. Am I missing 
something?

-- 
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: Linear algebra for 2d geometry?

[Ian Mackenzie]

You're exactly right - if you construct a function like the following, I 
think it will almost certainly result in four separate transformations 
every time it's called:

compositeTransformation1 : Point3d -> Point3d
compositeTransformation1 =
Point3d.scaleAbout Point3d.origin 5 >> Point3d.rotateAround Axis3d.z 
(degrees 
90) >> Point3d.translateBy (Vector3d ( 1, 2, 3 )) >> Point3d.mirrorAcross 
Plane3d.xy

In many cases that's fine (if you're only doing it for a handful of points, 
for instance), but if you need a more efficient version you can do it using 
frames:

transformedFrame : Frame3d
transformedFrame =
Frame3d.xyz |> Frame3d.rotateAround Axis3d.z (degrees 90) |> 
Frame3d.translateBy 
(Vector3d ( 1, 2, 3 ) |> Frame3d.mirrorAcross Plane3d.xy

compositeTransformation2 : Point3d -> Point3d
compositeTransformation2 =
Point3d.scaleAbout Point3d.origin 5 >> Point3d.placeIn transformedFrame

You still need to apply the scaleAbout separately since you can't scale a 
Frame3d, but at least scaling is a relatively cheap operation.

In general, yes, using matrices would likely be a bit more efficient, but 
you can get pretty close using techniques like the above, and I think the 
expressiveness/clarity/flexibility is better. Precision should also be 
improved - even disregarding the fact that the linear-algebra package uses 
single-precision floats internally (via Float32Array), specialized 
transformation functions like scaleAbout can do things like subtract the 
given center point, then scale, then re-add the given center point. This 
has better numerical stability than the equivalent transformation matrix, 
which will effectively scale everything about the origin and then apply a 
(potentially large) translation to drag everything back to where it should 
be. (Several of these tradeoffs are probably affected by my own goals - I 
want opensolid/geometry to be a great general-purpose geometry library, but 
I'm personally more focused on stuff like computer-aided design apps where 
precision is critical than things like games that have much more strict 
performance requirements.)

By the way, the interop package I mentioned earlier has now been published: 
http://package.elm-lang.org/packages/opensolid/linear-algebra/latest.

On Monday, 8 May 2017 05:22:05 UTC-4, Rupert Smith wrote:
>
> On Sunday, May 7, 2017 at 10:02:43 PM UTC+1, Rupert Smith wrote:
>>
>> On Friday, May 5, 2017 at 7:55:22 PM UTC+1, Ian Mackenzie wrote:
>>>
>>> So, nice library with lots of features, missed chance to work with a 
>>>> better abstraction.
>>>>
>>>
>>> Ouch =) I've done lots of work with matrix-based libraries, and I've 
>>> personally found matrices (and related stuff like quaternions) very 
>>> powerful and flexible but also confusion- and error-prone. The OpenSolid 
>>> libraries are my attempt to provide a better, more geometrically meaningful 
>>> abstraction that still allows you to get good performance.
>>>
>>
>> Sorry, my bad and thanks for the explanation. I guess I was a little 
>> fixated on the matrix approach, but with your explanation it is clear that 
>> your approach is at least as good.
>>
>
> There is potentially an advantage with matrices versus functions. A matrix 
> could be thought of as a function, in the sense that its values capture a 
> particular function that can be applied by multiplying by it. So you have 
> captured the function as a lambda. Lambdas are opaque though, and when 
> chained together to produce a new function, there is no way to guarantee 
> that they will combine in such a way that they reduce to the simplest or 
> most efficient representation; the compiler may do a good job though.
>
> Suppose you have a complex chain of transformations like: scale, rotate, 
> translate (requires 3x3 matrix for 2d work), mirror. Represent this with 
> matrices M1, .., M4. The entire transformation can then be captured as a 
> single matrix Mt = M1 . M2 . M3 . M4. As lambdas, my assumption is the 
> compiler will not be smart enough to reduce it so neatly, and it will 
> always be applied as 4 separate operations.
>
> I guess you already know 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.

[elm-discuss] Re: Linear algebra for 2d geometry?

[Ian Mackenzie]

On Friday, 5 May 2017 03:59:48 UTC-4, Rupert Smith wrote:
>
> On Thursday, May 4, 2017 at 5:53:36 PM UTC+1, Matthieu Pizenberg wrote:
>>
>> I definitely recommend looking at https://github.com/opensolid/geometry 
>> (with it's svg counterpart : https://github.com/opensolid/svg).
>> I've been using it a bit and it's awesome for what I understand you want.
>>
>
> This is nice and quite fully featured.
>

Thanks!
 

> It seems a shame that it is not Matrix based though. For example suppose I 
> want to do a rotation of a shape, ultimately this comes down to mapping 
> this vector rotation function over all points defining the shape:
>
> rotateBy : Float -> Vector2d -> Vector2d
> rotateBy angle =
> let
> cosine =
> cos angle
>
> sine =
> sin angle
> in
> \(Vector2d ( x, y )) ->
> Vector2d ( x * cosine - y * sine, y * cosine + x * sine )
>
> Which means calculating sin and cos again for the same input values for 
> each point.
>

Actually, that implementation is designed specifically to avoid 
recalculating sin and cos values. For example, calling Vector2d.rotateBy 
someAngle will compute sin and cos values, then return a lambda that 
captures those computed values so they don't have to be recomputed every 
time the lambda is called. As a result, things like List.map (Vector2d.rotateBy 
someAngle) myListOfVectors will only result in sin and cos values being 
calculated once (I've tested this with Debug.log calls). (Also, fine point: 
OpenSolid distinguishes between points and vectors, so the rotateBy 
function above can only be applied to Vector2d values, not Point2d ones.)
 

> If it was Matrix based, you'd calculate the rotation matrix once and then 
> do just the matrix multiplication part for each point. Due to the 
> properties of linear algebra, you can combine transformation matrices by 
> multiplying them all together to capture a more complex transformation in a 
> single operation.
>

The equivalent in OpenSolid is to apply a series of transformations to a 
Frame2d 

 
or Frame3d 
,
 then 
use Point2d.placeIn frame 

 
or Point3d.placeIn frame 

 for 
each point you care about. Building up a transformed frame by applying 
multiple transformations to it is equivalent to building a combined 
transformation matrix by multiplication, and calling placeIn is equivalent 
to using the final transformation matrix to transform the point, but I 
think every individual step is easier to reason about geometrically (you 
can visualize moving and rotating frames around, and 'placing' a point 
inside a given reference frame). I've explained all this in more detail in a 
reply to a GitHub issue 
.
 

> So, nice library with lots of features, missed chance to work with a 
> better abstraction.
>

Ouch =) I've done lots of work with matrix-based libraries, and I've 
personally found matrices (and related stuff like quaternions) very 
powerful and flexible but also confusion- and error-prone. The OpenSolid 
libraries are my attempt to provide a better, more geometrically meaningful 
abstraction that still allows you to get good performance.

For what it's worth, I'm just finishing up a small package to allow interop 
between OpenSolid and elm-community/linear-algebra - so if you want to 
you'll be able to transform OpenSolid points and vectors using a Mat4.

-- 
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: Linear algebra for 2d geometry?

[Ian Mackenzie]

On Thursday, 4 May 2017 16:15:38 UTC-4, Rupert Smith wrote:
>
> I also notice that opensolid/svg is a small library. Would not be hard to 
> re-implement it over elm-community/typed-svg and remove all those 
> 'toString's.
>

True - although when I initially wrote opensolid/svg, typed-svg didn't 
exist so that wasn't an option. I may switch to it at some point to clean 
up the internal implementation code a bit, but it doesn't seem like a 
pressing concern since I don't think it would change the external interface 
at all. You could certainly already mix and match if you want, e.g. 
construct SVG attributes using typed-svg that you can then pass to the 
geometry construction functions in opensolid/svg.

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

[elm-discuss] Re: view function to call other view function with different Msg type

[Ian Mackenzie]

Shouldn't that be Html.map, not Html.Attributes.map? itemView returns a Html 
msg, not an Html.Attribute msg...

On Saturday, 22 April 2017 21:53:47 UTC-4, Erik Lott wrote:
>
> view : Model -> Html Msg
> view model =
> div []
> (model.items
>   |> List.map itemView 
>   |> List.map (Html.Attributes.map ItemMsg)
> )
>
>
>
>
> On Saturday, April 22, 2017 at 5:25:41 PM UTC-4, Vardhan wrote:
>>
>> [ Pardon if this appear twice ]
>>
>> hi,
>>   this is my  toy 1st elm app.
>>i'm trying to keep the 'item' of the list as a seperet module.
>>
>> so i have in module Item:
>> -
>> type alias ItemModel= { ... }
>> type ItemMsg = .. | .. | ..
>> itemView : ItemModel -> Html ItemMsg
>> -
>>
>> And in the top level App  module:
>> -
>> type alias Model = { items: List ItemModel }
>> type Msg = ItemMsg ItemMsg | ...
>> view : Model -> Html Msg
>> view model =
>> div []
>> (List.map itemView model.items )
>> --
>>
>> Well, the problem is itemView can't be used , as it is 'Html ItemMsg', 
>> and not 'Html Msg'
>> However, the Item module doesn't have access to 'Msg' ( which is top 
>> level ),
>>
>> How should I use itemView in the view function ?
>>
>> -Regards
>> Vardhan
>>
>>
>>

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

[elm-discuss] Re: Elm-reactor and static files (images & videos)

[Ian Mackenzie]

You should be able to use the debugger outside of elm-reactor if you 
compile with the --debug flag, for example

elm make --debug Main.elm --output main.js

You should then be able to use whatever you want to serve the HTML/JS and 
you'll still get the debug overlay.

On Saturday, 22 April 2017 18:33:29 UTC-4, Fernando Martinez wrote:
>
> Hello All! 
>   I'm new to Elm and trying to build a small 
> "playlist/carousel app"  (basically, a list of videos and images that 
> passes one after the other) to learn elm and try some ideas about ports. 
>
> I think I'm having a newie problem but I could not found a solution or 
> leads to a solution (or I couldn't undestand them :P), so I'm writing here.
>
> I'm using the elm-reactor to develop and like very much the debbugger and 
> the automatic building.
>
> So, my first question is:  is it posible to serve static files (images and 
> videos) from the elm-reactor?
> (From what I could observe, it returns an empty response. perhaps I'm 
> missing something?)
>
> As a work around, I tried using a common http server to serve the app and 
> was able to have hotreloading using a file system watching library to 
> automatically build and reload the browser. But I lost the debugger :(
>
> So, the second question, depending on how the first one goes. is: is there 
> any way to open the debugger outside of elm-reactor?
>
>
> Thanks you very much!
> Fernando.
>

-- 
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 
<http://package.elm-lang.org/packages/elm-community/elm-test/latest/Test#fuzz> 
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 
<https://github.com/opensolid/geometry/blob/master/tests/Generic.elm#L22>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 
>> <http://elm-lang.org/docs/records#pattern-matching>, 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.

[elm-discuss] Re: Noticeable lag when working with a model that contains large dataset

[Ian Mackenzie]

Is the issue specific to when running in debug mode (when using Elm Reactor 
or compiling with --debug), by any chance? I recently encountered an issue 
where the debugger will scan through the entire model after every update, 
which is quite slow if there are large data structures in the model. I 
posted about the issue and my workaround on Reddit 

.

On Monday, 3 April 2017 09:32:22 UTC-4, 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.

Re: [elm-discuss] Linear algebra (matrix, vectors, ...) in the context of image processing

[Ian Mackenzie]

I also wonder how memory efficient a pure Elm solution could be, as currently 
there's no support for binary or packed data representation. That alone might 
argue for keeping the image data itself on the JavaScript side where you (or 
the libraries you use) can pull all sorts of tricks with typed arrays and stuff 
like that. I think ultimately Elm could be a great language for working with 
binary data but it's not there yet.

Glad you're finding OpenSolid useful! Certainly happy to discuss feature 
requests - for the initial release I was concentrating on getting the data 
types and overall structure/'grammar' of the package right, but that means 
there are lots of places where useful individual bits of functionality are not 
yet implemented.

-- 
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] Linear algebra (matrix, vectors, ...) in the context of image processing

[Ian Mackenzie]

For your second question, I know there's work being done currently on 
supporting the Canvas API in Elm (https://github.com/elm-community/canvas), 
which may be more appropriate for visualizing bitmap data than SVG, but it's 
still very experimental.

-- 
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] ANN: opensolid/geometry, a comprehensive 2D/3D geometry package for Elm

[Ian Mackenzie]

Thanks Duane! You have have already noticed this in the README, but there's 
also an associated opensolid/svg 
<http://package.elm-lang.org/packages/opensolid/svg/latest> package...so if 
you used an OpenSolid Triangle2d value to define the shape of one of your 
HCCB triangles, you could then use OpenSolid.Svg.triangle2d to draw it as 
SVG (and supply whatever additional fill/stroke etc. attributes you want).

(By the way, what part of Canada are you from? I'm currently living in New 
York but I'm a Toronto native...)

On Wednesday, 1 February 2017 15:47:47 UTC-5, Duane Johnson wrote:
>
> Nice work! I hope to use this in some of my projects (like the HCCB 
> package <http://package.elm-lang.org/packages/canadaduane/elm-hccb/latest> 
> I just released perhaps...)
>
> On Wed, Feb 1, 2017 at 10:31 AM, Ian Mackenzie <ian.e.m...@gmail.com 
> > wrote:
>
>> Just posted this to Reddit, but thought I should mention it here as well: 
>> http://package.elm-lang.org/packages/opensolid/geometry/latest
>>
>> I'd love to get feedback, and I'm happy to answer any questions!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[elm-discuss] ANN: opensolid/geometry, a comprehensive 2D/3D geometry package for Elm

[Ian Mackenzie]

Just posted this to Reddit, but thought I should mention it here as well: 
http://package.elm-lang.org/packages/opensolid/geometry/latest

I'd love to get feedback, and I'm happy to answer any questions!

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

[Ian Mackenzie]

I agree with the point about adding helper functions for your data type so you 
can treat it as opaque in most places. For the rest, though, you can also use 
the slightly obscure 'as' syntax 'foo ((Foo s) as f) = ...' which allows you to 
use both 's' and 'f' in your function body (with the additional bonus of 
avoiding an extra object allocation).

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

[elm-discuss] Re: Why is "port" forbidden as field name inside record?

[Ian Mackenzie]

Well, it certainly seems easier to make a robust parser if keywords are not 
context-dependent. Yes, perhaps you could tell that { port = "foo" } is a 
record with a 'port' field, but what about port = "foo"? Is that a record 
missing its opening and closing braces, or a messed-up declaration of an 
Elm port? What sort of error should the compiler report?

In any case, I can't speak for Evan but I rather suspect that tweaking the 
parser to allow context-sensitive keywords (even if that was agreed to be a 
good idea in general) would be way, way down the list of priorities for at 
least the next few years.

On Thursday, 15 December 2016 17:15:00 UTC-5, Paul Dijou wrote:
>
> Both solutions are valid (I'm actually using both depending on the 
> situation) but my main question is why is there such a limitation? Reserved 
> keywords could (should?) depend on the context. You cannot define a real 
> port inside a record, you just want a string to name a property.
>
> For example, in JavaScript, you can create an object with any property you 
> want, including reserved keywords, because, at the end of the day, it's 
> just string names. Some old browsers required to wrap the key inside quotes 
> so I would be fine with writing { "port" = 80 } in Elm if that would solve 
> the problem.
>
> Le jeudi 15 décembre 2016 16:20:25 UTC+1, Paul Dijou a écrit :
>>
>> Hi,
>>
>> I understand that "port" is a reserved keyword when writing Elm code but 
>> is there a reason to fail compilation when used as the name of a record 
>> field? It's a bummer when sending records through a port (a real one) and 
>> the JavaScript is expecting the property "port" (in the record).
>>
>> 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.

Re: [elm-discuss] Why is "port" forbidden as field name inside record?

[Ian Mackenzie]

You should also be able to switch to ports based on Json.Encode.Value, which 
gets passed through ports directly as JSON. You'll have to write your own 
encoders and decoders but you should then be able to use arbitrary field names 
(since you'll end up specifying them as string literals in your Elm 
encoders/decoders). So you can use some non-reserved name in your Elm code and 
then encode/decode it to/from a 'port' field.

-- 
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] Probably a *very* basic question ...

[Ian Mackenzie]

Is the button inside a  that is causing it to trigger a form submission 
when clicked?

-- 
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 any way to use a type instead of a string for the value of an option

[Ian Mackenzie]

I've been slowly working on a small library 
 to make working with the basic 
input widgets like  more pleasant to work with - I'd be interested 
to see what you think. The implementation 

 handles 
the mapping between selected index and strongly-typed values; check out 
examples/ComboBox.elm 
 to 
see a simple usage example.

On Tuesday, 25 October 2016 23:45:26 UTC+11, James Hamilton wrote:
>
> Hello!
>
> I suppose this really only applies to instances of , but there may 
> be other examples. 
>
> When using  with , it's necessary to set a value on the 
>  using  which accepts a String. However, I usually actually 
> want to refer to a Type which I have to represent as a String and marshal 
> it back to its correct type when updating the model. 
>
> Is there a way of doing this using a type, and if not could it be done? I 
> think it's a reasonable thing to expect to be able to do with an , 
> but then again I'm pretty new to this so please tell me if I'm asking for 
> something complicated!
>
>

-- 
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, Objects and Components

[Ian Mackenzie]

Peter, you may be interested in (and I'd appreciate your feedback on) a 
little library I've been working on for composable input widgets: 
https://github.com/kintail/input-widget

It seemed to me that in many cases of 'little bits of local state', the 
widget in question is an input widget of some sort like a fancy dropdown, a 
date picker, a small form with a few fields + validation etc. where it has 
some transient internal state to keep track of but all the higher-level 
code really cares about is the output value produced. As a result I created 
the input-widget package to experiment with combinators (map, map2 etc.) 
for input widgets and I think so far it's worked out pretty well; you can 
pretty easily do things like add validation or decoration to widgets, 
combine a 'first name' and a 'last name' widget to produce a 'person' 
widget, etc. You can also define custom input widgets using TEA functions 
(which can then be composed etc. just like any other input widget) or 
easily embed input widgets into a normal TEA program. Right now the only 
primitive widgets I've implemented are 'checkbox' and 'lineEdit', and 
there's no documentation yet, but you should be able to check out the 
examples directory to see how things work.

Internally this does a couple dirty-ish things (the 'State' type includes a 
bunch of functions which is generally frowned upon, and messages are all 
passed around as JSON to avoid an explosion of types) but from the outside 
it should be quite type safe (I'd love to hear about any holes people find).

Ultimately I'd like to create a parallel output-widget package for 
composable output widgets following the sortable-table example (internal 
state handled internally, current value to display passed into 'view').

On Tuesday, 20 September 2016 10:13:43 UTC+10, Nick H wrote:
>
> The  way I view it, the core idea behind Components is the closure 
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of 
>> thing that can then be used to combine with other things.
>
>
> Abelson is just defining and combining functions. Adjusting for syntax, 
> you could write code in Elm that looks essentially the same.
>
> (DEFINE P (BESIDE G (ROT-180 (FLIP G)) .5))
>
> What is conspicuously absent in this example is anything that looks like 
> an object or a component. All of the old state is in "G". All of the 
> behavior is in the functions. All of the new state is in "P".
>
> Abelson did not show in his slides here the code for rendering the view. 
> But this would just be a function that takes P (or G) as input. In Elm, it 
> would just return Html.
>
> This has nothing to do with the business objectives of that UI. It is just 
>> a piece of transitory, accidental information.
>>
>
> As far as the view function is concerned, there is no difference. Every 
> bit of information needed to draw the view needs to get passed to the view 
> function as an argument.
>
> That doesn't mean that all of your update functions need to operate on the 
> totality of your state (although in Abelson's example, they do!). You 
> should have separate functions to deal with updating that UI state and 
> aspects of your "business" state, and these can be delegated from your 
> overarching update function.
>
> Scheme is a nice illustration that functions are the only tool you need to 
> manage complexity. If there are pain points in scaling Elm programs, the 
> lack of components aren't the culprit.
>
>
>  
>
> On Mon, Sep 19, 2016 at 2:57 PM, Peter Damoc  > wrote:
>
>> Evan points out that people would consider thinking in terms of Objects 
>> for certain parts of the UI as a bad idea
>> https://youtu.be/LCNs92YQjhw?t=1340
>>
>> he also points that Components are more or less the same thing and that 
>> we should move away from thinking about them. 
>>
>> The  way I view it, the core idea behind Components is the closure 
>> property that professor Abelson speaks about here:
>> https://youtu.be/2QgZVYI3tDs?t=2194
>>
>> Building complexity by combining things and getting the same kind of 
>> thing that can then be used to combine with other things. 
>>
>> The sidebar would be a *thing, a widget, an object, a component. * Now I 
>> could implement it right now by using the components of elm-html and have 
>> that component be a simple function where some elm-html widgets are 
>> combined in a certain way. 
>>
>> The problem is that *some of the components* that are needed in a modern 
>> UI need small state. If these components are implemented in C++ and wrapped 
>> by the virtual-dom, we are lucky, we can use them. If they are not, we are 
>> out of luck. Even a humble dropdown cannot be used as pleasantly as a 
>> radiobox because it needs a small "isVisible" piece of state. This has 
>> nothing to do with the business objectives of that UI. It is just a piece 
>> of transitory, 

[elm-discuss] Re: Announcing elm-test 2.1.0!

[Ian Mackenzie]

Awesome work! Just updated my test code - mapN and constant are great, and 
the new auto-shrinking works beautifully. (I just deliberately 
re-introduced a bug temporarily to try it out and sure enough elm-test 
found three independent, minimal failure cases.)

With 2.0.1 I encountered some stack overflow issues when using a filtered 
generator (Chrome dev tools pointed to andThen from Random.Pcg as the 
culprit), but didn't report it since you hadn't officially announced v2 so 
I figured you were still working on it. I'll see if I can put together an 
SSCCE for 2.1. I really don't think I was filtering out 'almost all' values 
(should have been more like half of them) but I figured out a way to switch 
to a non-filtered generator in the meantime.

On Tuesday, 6 September 2016 12:25:30 UTC+10, Max Goldstein wrote:
>
> Richard and I are proud to announce that elm-community/elm-test version 
> 2.1.0 is now available on elm-package.
>
> This release involved completely changing how Fuzzers are implemented, but 
> the end result is that Fuzzers support new ways of mapping! Specifically we 
> added *map2* (up to *map5* and the equivalent *andMap*), which allow you 
> to combine many fuzzers together. We also added *andThen* which lets you 
> use randomized values to set up other randomized values, which gives you 
> that much more control over your tests. All of these functions, and plain 
> old *map*, will shrink their output values to a minimal failing example. 
> We also added the helper *constant*.
>
> We want to hear from you! If you discover any of the following, please open 
> an issue  (but 
> check for dupes first, there aren't that many):
>
>- Passing tests that got slower
>- Failing fuzz tests which don't shrink as well as before
>- Runtime errors
>- API ideas (for expectations, fuzzers, etc.)
>
> Happy testing!
>

-- 
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: Remove ways of importing except `import exposing (..)`?

[Ian Mackenzie]

Edit: I did some searching after I posted this and realized just how common 
it was to have custom toString functions, so I take back what I said about 
not naming your own functions toString. Switching Basics.toString to 
Debug.toString could be a good solution, although that would be annoying 
for simple cases like converting an Int to a String (which is often needed 
in non-debug situations like setting up HTML/SVG attributes). Maybe there 
should be a specialized Int.toString function instead. I do think it's a 
sufficiently special case that 'always import qualified' is still the best 
strategy though.

On Friday, 19 August 2016 09:28:56 UTC+10, Ian Mackenzie wrote:
>
> It seems to me that the issues you are encountering come from two things:
>
>- Using a mix of qualified and unqualified imports
>- Having a function the same name as one in Basics
>
> One solution is to never use qualified imports, but a better solution is 
> to *always *use qualified imports and just not name any of your own 
> functions toString (or min, or max, or degrees, or anything else in Basics
> ). That way you never have any ambiguity between functions, you never 
> have to switch between qualified and unqualified (if, perhaps, you start 
> using Maybe.map in a file that already uses List.map), and it's always 
> clear where a function (or value) is coming from.
>
> On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote:
>>
>> import ModuleWithToString
>>
>> toString typeFromThatModule
>>
>> Compiles with unexpected results that you have to catch.
>>
>> import ModuleWithToString exposing (..)
>>
>> toString typeFromThatModule
>>
>> Doesn't compile: "use of toString is ambiguous: did you mean 
>> Basics.toString or ModuleWithToString.toString?"
>>
>

-- 
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: Remove ways of importing except `import exposing (..)`?

[Ian Mackenzie]

It seems to me that the issues you are encountering come from two things:

   - Using a mix of qualified and unqualified imports
   - Having a function the same name as one in Basics

One solution is to never use qualified imports, but a better solution is to 
*always *use qualified imports and just not name any of your own functions 
toString (or min, or max, or degrees, or anything else in Basics). That way 
you never have any ambiguity between functions, you never have to switch 
between qualified and unqualified (if, perhaps, you start using Maybe.map in 
a file that already uses List.map), and it's always clear where a function 
(or value) is coming from.

On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote:
>
> import ModuleWithToString
>
> toString typeFromThatModule
>
> Compiles with unexpected results that you have to catch.
>
> import ModuleWithToString exposing (..)
>
> toString typeFromThatModule
>
> Doesn't compile: "use of toString is ambiguous: did you mean 
> Basics.toString or ModuleWithToString.toString?"
>

-- 
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: Design question: using Dict, List with index, or Array (or something I'm not aware of)

[Ian Mackenzie]

My initial reaction is also #3. I think it's totally sensible to do a bit 
of transformation when serializing/deserializing, and more important to 
optimize your model for its use in view and update.

On Friday, 12 August 2016 23:03:34 UTC+10, Robert Walter wrote:
>
> Hello,
>
> following scenario: In my Model, I want to keep track of a collection of 
> items as well as the currently active item. Sounds simple enough, but there 
> are some constraints. I want to serialize my Model (use programWithFlags), 
> so I cannot use a Dict directly to the best of my knowledge. I need to be 
> able to sort the collection and be able to append items at the beginning as 
> well at the end.
> I've come up with the following options and it would be appreciated if I 
> could get some feedback on what the community thinks is best and why.
>
> Option 1: List and explicit Item
> type alias Model = 
>   { collection : List Item
>   , itemActive : Item 
>   }
>
>
> type alias Item =
>   { name : String 
>   }
>
> Downside: I have to manually update the list if the item changes (it's 
> what I have in place currently and it is somewhat obvious to me that this 
> is not best).
>
> Option 2: List with index
> type alias Model = 
>   { collection : List Item
>   , itemActive : Int 
>   }
>
>
> type alias Item =
>   { name : String 
>   }
>
> Downside: accessing a random item in a list is expensive (although in 
> practice my collection is never going to be very long, it could get 
> arbitrarily long).
>
> Option 3: Dict with index
> type alias Model = 
>   { collection : Dict Int Item
>   , itemActive : Int 
>   }
>
>
> type alias Item =
>   { name : String 
>   }
>
> Downside: Dict is not supported by programWithFlags, so I'd have to 
> transform it to a different representation for serialization
>
> Option 4: array with index
> type alias Model = 
>   { collection : Array Item
>   , itemActive : Item 
>   }
>
>
> type alias Item =
>   { name : String 
>   }
>
> Downside: I need to perform some operations that don't seem to be first 
> class array operations, namely sort the array by Item.name and insert items 
> at the front
>
> I think I know how to implement each of these approaches, but maybe I'm 
> missing an even better fit for my use case. Currently I prefer Option 3. 
> Even though it might need a bit more work on the serialization / 
> de-serialization side, I feel like a Dict would be the best fit for my use 
> case.
>
> Thanks in advance,
> Robert
>

-- 
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: What concepts and models did you had to learn in order to be able to write good Elm code?

[Ian Mackenzie]

The most important one I keep coming back to is the design principle of 
rigorously separating functions and data - don't keep functions in your 
model, etc.

In many ways I jumped on Elm just because it felt so immediately *right* 
and natural, as opposed to "I heard Elm was great but now I have to adjust 
to a whole new way of thinking", so there wasn't a lot of mental 
gymnastics. But coming from C++ (and more recently Scala) I still started 
out doing things like creating 'interface types' that were records with a 
couple of function fields and passing those around as arguments to other 
functions.

I guess the other one would be getting used to function signatures and 
currying. Simple examples like plus : Int -> Int -> Int are relatively easy 
to explain as "it can take two Ints and return an Int, or take one Int and 
return a new Int -> Int function" but I still find some cases a bit 
mind-bending especially when type aliases get involved - here's some helper 
code I recently wrote:

type alias Comparator a =
a -> a -> Bool


both : Comparator a -> Comparator a -> Comparator a
both firstComparator secondComparator first second =
firstComparator first second && secondComparator first second

So the both function is declared as taking two comparator functions and 
returning another comparator function, but thinking of it in those terms 
the implementation actually takes the first two functions *and the two 
arguments of the resulting function*, and returns the final result. It all 
makes sense if you mentally 'flatten' the type signature and think about 
partial application a bit, but at first glance it seems odd.

On Thursday, 11 August 2016 19:07:33 UTC+10, Peter Damoc wrote:
>
> "The fundamental fact about learning: Anything is easy if you can 
> assimilate it to your collection of models. If you can't, anything can be 
> painfully difficult.” - Seymour Papert
>
> I'm trying to come up with a sorted list of concepts and models that a 
> prospective Elm user needs to learn in order become proficient in Elm. 
>
> Here is my list (I actively tried to keep it short) : 
>
> - types : the concept that information flowing through an Elm program has 
> a specific type and that the compiler will not accept the wrong type. 
>
> - type composition: the concept that types can be composed into more 
> advanced types using union type syntax and record syntax. 
>
> - type variables : the concept that you can have a type constructor that 
> can take arguments and produce a custom type (List, Maybe, etc) 
>
> - functions as types: the concept that you can give functions to other 
> functions in order to customize their application. 
>
> - currying/closures: the concept that you can take a multi argument 
> function and produce another function that has some of those arguments 
> applied. 
>
> - declarative: the concept that the Elm programs are made of one big 
> function that returns a specific type instead of a series of instructions.  
>
> How does your list looks like? Which one gave you most troubles? Which one 
> did you find most  amazing | useful | mind-blowing ? 
>
>
>
>  
>
> -- 
> 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] Re: My first Elm

[Ian Mackenzie]

Have you looked at the modularity section 
 of 
the Elm guide? It doesn't yet specifically cover nesting components that 
have subscriptions, but points you to examples 3 and 4 here 
. 
You should end up with your main body module having something like

type Msg
= MyTopLevelMessage Int
| SomeOtherTopLevelMessage String
| ClockMessage Clock.Msg

so the main module has one message type that wraps all clock-related 
messages in their own tag (oblivious to whether those clock-related 
messages are time ticks or anything else). If your clock has subscriptions, 
your main module might do something like

subscriptions : Model -> Sub Msg
subscriptions model =
Sub.map ClockMessage (Clock.subscriptions model.clock)

to generate a top-level subscription (perhaps batching that with its own 
subscriptions if necessary). If you can post some of your code we can take 
a look...

On Wednesday, 10 August 2016 01:21:40 UTC+10, Rupert Smith wrote:
>
> On Thursday, August 4, 2016 at 11:30:00 PM UTC+1, Rupert Smith wrote:
>>
>> The next step I think will be to take the navigation bar, and the clock 
>> widget and organize the code in such a way that the widget is a re-usable 
>> component that I can embed in the navigation bar.
>>
>
> Up till now I have mostly messed around with the view - so I can use a 
> functional language to render a view. This is very nice and a lot more 
> powerful than say Handlebars templates. I started using StringTemplate in 
> Java because it claimed to be a functional language that did templating. In 
> fact, it never really lived up to its claim to be a functional language. 
> Elm views do feel like a functional templating language - it is easy to 
> combine the functions that produce output with whatever complex functions 
> you need to structure or calculate the content of the output.
>
> I have followed this guide to structuring the code:
>
>
> http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html#comment-2634825704
>
> Moderately helpful - at least it made the files smaller, I know which file 
> to open to adjust the model, update function or view and there is not too 
> much text in each. It feels more manageable that way.
>
> But this is definitely getting harder... 
>
> I have embedded the clock as a component within another, which is the main 
> body part of the page. What I am struggling a bit with, is how do I attach 
> the 'subscription' that transforms Time into a Tick that then drives the 
> clock 'update' function back to the top-level subscription needed to build 
> the whole application?
>
> I need a Tick Msg at the top-level to do this? This feels a bit strange, 
> surely there is some way I can attach the clock to the timer without 
> needing to be aware of that from outside of that particular component? That 
> is, just add the clock to my view and let it tick away all by itself...
>

-- 
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: about the Keyboard API

[Ian Mackenzie]

I really like this version. It's effectively saying that in the same way 
that most subscriptions/HTML events take map function arguments since you'd 
otherwise almost always want to map the result yourself (using Html.App.map 
or Sub.map), the keyboard functions should take a filter-map function 
argument since you almost always want to filter and map the result. (With 
the slight wrinkle that Sub.filterMap doesn't actually exist, but that's 
getting back into the general subscription-filtering discussion...)

On Tuesday, 9 August 2016 16:01:48 UTC+10, Janis Voigtländer wrote:
>
> To up the proposal, here a revision.
>
> Instead of proposing to *add* new functions, I now propose to *replace*
>
> Keyboard.presses : (KeyCode -> msg) -> Sub msgKeyboard.downs : (KeyCode -> 
> msg) -> Sub msgKeyboard.ups : (KeyCode -> msg) -> Sub msg
>
> by
>
> Keyboard.presses : (KeyCode -> Maybe msg) -> Sub msgKeyboard.downs : (KeyCode 
> -> Maybe msg) -> Sub msgKeyboard.ups : (KeyCode -> Maybe msg) -> Sub msg
>
> It would still be easy to recover the old behavior if wanted in a specific 
> situation, by throwing in Just. But actually I posit that one almost 
> never really wants to capture all keys. Usually, one wants to be selective. 
> That selectiveness has to be expressed somewhere, and doing it with the 
> Maybe type that is designed for such purpose is generally better than 
> going for something like extra NoOp or NothingHappened or NotBound 
> constructors that then need to be handled in a special way in the app’s 
> update logic, without help from the type system. Making consideration of 
> the selectiveness part of the modelling up front would lead to better 
> design. That’s at least the case in the projects/repositories I have 
> pointed to.
> ​
>
> 2016-08-08 14:48 GMT+02:00 Janis Voigtländer  >:
>
>> A while back there was a thread 
>>  
>> about filtering subscriptions. The following is related, but can also (and 
>> probably better) be consumed and discussed independently. For those that do 
>> have that older thread as context in mind, the following differs in two 
>> essential ways:
>>
>>- Earlier, the discussion was about generic filtering of arbitrary 
>>subscriptions. The following involves no genericity whatsoever. It is 
>> only 
>>a proposal about the Keyboard API specifically. 
>>- The earlier thread was not rooted in practice, since very little 
>>stuff had been built yet with subscriptions. In the following, I point to 
>>how things have played out in practice, based on uses students have made 
>> of 
>>the current API in projects. 
>>
>> --
>>
>> So, on to the subject matter:
>>
>> The keyboard package 
>>  currently 
>> contains functions such as:
>>
>> Keyboard.downs : (KeyCode -> msg) -> Sub msg
>>
>> Common uses (I’ll point to several repositories below) are such that only 
>> some keys are relevant for an application. My proposal is to have functions 
>> such as:
>>
>> Keyboard.downsSelectively : (KeyCode -> Maybe msg) -> Sub msg
>>
>> where the semantics is that if a given KeyCode is mapped to Nothing by 
>> the tagger, then no message gets sent along the subscription; otherwise the 
>> Just is peeled off and the message gets sent.
>> --
>>
>> Let’s look at a practical case, https://github.com/arpad-m/dontfall. 
>> It’s a game, where the player uses the keyboard for part of the control. 
>> Important excerpts from the code are:
>>
>> The message type (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/BaseStuff.elm):
>>
>> type GameMsg = NothingHappened | ... several other messages ...
>>
>> The subscriptions definition (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> subscriptions : GameData -> Sub GameMsgsubscriptions d =
>> Sub.batch
>> ([ Keyboard.downs (\c -> if Char.fromCode c == 'P' then PauseToogle 
>> else NothingHappened) ] ++
>> if d.state == Running then
>> [ AnimationFrame.diffs Tick
>> , Keyboard.downs (\c -> if Char.fromCode c == ' ' then 
>> JumpDown else NothingHappened)
>> , Keyboard.ups (\c -> if Char.fromCode c == ' ' then JumpUp 
>> else NothingHappened)
>> ]
>> else
>> [])
>>
>> The main case distinction in the main update function (in 
>> https://github.com/arpad-m/dontfall/blob/master/src/main.elm):
>>
>> updateScene : GameMsg -> GameData -> (GameData, Cmd GameMsg)updateScene msg 
>> d =
>> (case d.state of
>> ...
>> Running -> case msg of
>> MouseMove (x,_) -> { d | characterPosX = min x d.flWidth}
>> Tick t -> stepTime d t
>> PauseToogle -> { d | state = Paused }
>> JumpDown -> { d | jumpPressed = True }
>>   

[elm-discuss] Re: Module communication (state machine)

[Ian Mackenzie]

I do rather like #2 - it seems to me that you could even have the result of 
update be either the usual model/command pair *or* a UserId, i.e. replace 
both return values, not just the second one. Something like:

type State
= Active ( Model, Cmd Msg )
| Finished UserId

update : Msg -> Model -> State
update msg model =
...

which is very explicit - either we're still in the process of logging in, 
so here is the updated model and some more commands to perform, or the user 
has finished logged in so you should use the returned user ID to switch to 
some new state.

On Tuesday, 9 August 2016 10:12:26 UTC+10, Mark Hamburg wrote:
>
> Here is the case I'm looking at: My SPA can be in one of three state — 
> probably more before I'm done but three will be sufficient for this 
> discussion — logging in, active, and logged out. So, here's my model:
>
> type Model
>   = LoggingIn LoggingIn.Model
>   | Active Active.Model
>   | LoggedOut LoggedOut.Model
>
> The message handling has appropriate tag messages and the update function 
> looks fairly nice by casing on (msg, model). All good so far.
>
> Now, for the question: How best to drive state transitions?
>
> For example, when we finish logging in, we should get back a UserId that 
> we can hand to Active.init to get an (Active.Model, Cmd Active.Msg). How 
> should this be reported? The cases I've considered include:
>
> 1. Add an extra Maybe UserId result to LoggingIn.update.
>
> 2. Replace the second result from LoggingIn.update with something that 
> can be either a Cmd LoggingIn.Msg or a LoggedIn UserId.
>
> 3. Add a loggedInUser : Model -> Maybe UserId function to the LoggingIn 
> module and test this after doing the update.
>
> Interesting side question: If we do succeed in logging in, is it ever 
> reasonable to be returning commands (effects) from that update to the 
> logging in model? The results aren't going to get routed back because that 
> model state is going away. On the other hand, if we were just sending off 
> some sort of external effect for which the result didn't matter, then maybe 
> this could come up.
>
> If the answer to the side question says "yes, it is reasonable to send off 
> commands as part of login success", then the second option needs a more 
> complicated type since we can return both a command AND a user id. In that 
> case, the first case probably wins.
>
> On the other hand, returning triples with what in the general case will be 
> arbitrary third parameters feels like the sort of coding pattern that 
> decays into returning quads and quints.
>
> The benefit of the third path is that now one could imagine testing the 
> logging in module by itself with a view case for when logged in. The state 
> machine just drives us from this state to the active state.
>
> The downside to the third path is that now every state implementation 
> needs to include a state for while it is doing what it would ordinarily do 
> and a state for when it is time to move on and that's more plumbing at 
> those levels. For example, the Active module would similarly gain an 
> isLoggedOut 
> : Model -> Bool function and the model within the module would need to 
> handle the logged out case even though it really has nothing to do in that 
> case,
>
> How would more experienced Elm coders handle this? Is there a sense for 
> best practice?
>
> My personal inclination is probably to go for the first option even though 
> it starts to step out onto the slippery slope. I like the second approach 
> because it feels more rigorous but I think that extra rigor just turns into 
> extra code in practice. My first implementation today pursued the third 
> course and I thought it looked nice in my top-level module until I thought 
> about the fact that it would turn everything below it into a state machine 
> as well.
>
> Mark
>
>

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

[elm-discuss] Re: elm-format vs gofmt

[Ian Mackenzie]

For what it's worth, I had the same initial reaction to all the extra 
whitespace added in 'let' blocks - that was by far the biggest change that 
elm-format made to my code when I started using it - but I fairly quickly 
started to like it. Yes, some functions get a lot longer, but that extra 
whitespace and consistent indentation does seem to make code very visually 
scannable.

-- 
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] elm-format vs gofmt

[Ian Mackenzie]

Comment handling can indeed be a bit funny (and elm-format is still under 
active development, so this may change in the future), but the right solution 
in this case is probably to use a proper documentation comment for the function 
instead (one that starts with '{-|' and ends with '-}' - see 
http://package.elm-lang.org/help/documentation-format for details).

-- 
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: Should [ 1..5 ] exist?

[Ian Mackenzie]

Ah, cool, thanks Jonas! I was worried that the 'loading and indexing' step was 
querying current data from package.elm-lang.org but I guess you're just 
periodically downloading and caching that data on your own server instead? I 
look forward to seeing the final version!

-- 
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] Sharing test code

[Ian Mackenzie]

I've been working on a bunch of related geometric packages and one thing I 
haven't quite figured out is the best way to structure test code. So far 
I've been using the fairly common pattern of having a 'test' subdirectory 
with its own elm-package.json that has "../src" in its source-directories 
and dependencies on testing packages (currently elm-test and elm-check) 
above and beyond the dependencies of the base package.

This works, but it means that I can't share testing functionality between 
packages. For example, in one package I define producers (a.k.a. 
generators/fuzzers) for things like Point3d values. In a separate package, 
I'd like to create a Triangle3d producer by combining three Point3d 
producers, but I can't because the Point3d producer is hidden inside the 
first package.

One solution would be to define actual tests in a subdirectory as now, but 
put shared test functionality (producers, comparators etc.) somewhere in 
the base package. This means anyone depending on the root package could 
have access to its defined producers etc., but it also means adding any 
testing libraries as dependencies of the root package instead of the hidden 
testing sub-package.

An alternative I thought of would be to have a separately-published test 
package (e.g. package.elm-lang.org would have both "my-package" and 
"my-package-test"), with the test package depending on the base package. 
The test package would expose shared functionality like producers and 
comparators. During development, you'd have to check out the sources for 
both the base package and the test package, and replace the test package 
dependency on the base package with a relative path to the base package 
checkout in source-directories (so that you could add functionality to the 
base package and immediately add tests for it without having to publish the 
base package first). When it comes time to do a release, you'd publish the 
base package, update the test package to depend on the published version of 
the base package instead of having a relative path in source-directories, 
then publish the test package.

This way anyone could just use the base package without pulling in any 
unwanted testing dependencies, but could also depend on the testing package 
if they wanted to use the exposed producers etc. in their own test code. 
Thoughts? Are there better ways to do 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.

Re: [elm-discuss] Re: Should [ 1..5 ] exist?

[Ian Mackenzie]

Someone actually did implement Hoogle-like search for Elm, and it works 
pretty well, although using it is probably not kind to the 
package.elm-lang.org 
server: http://klaftertief.github.io/package.elm-lang.org/

I'm all for replacing special syntax with List.range or something similar. 
I'd almost be tempted to say that 'range' should only work on Int values - 
I've usually found it more robust to generate float ranges with something 
like List.map on a List Int, where you can very explicitly control the 
number of values produced and the exact start and end. (For example, you 
can divide a float range by a float step and then decide yourself whether 
you want to use floor, ceil or round to choose the number of steps.)

On Friday, 5 August 2016 07:36:42 UTC+10, Joey Eremondi wrote:
>
> If we went crazy with this, most keywords / common functions from other 
>> languages would be listed as keywords for their elm equivalents
>> and it could make life easier, I imagine
>
>
> A far more robust solution is just to have Hoogle-like search, where you 
> put in the type, and it tells you what functions have that type, or similar 
> types. So instead of searching "flatMap" or "concatMap" or "bind", you 
> search ((a -> List b) -> List a -> List b).
>
> This seems simpler than trying to keep track of what each function is 
> called in ML, F#, Scala, Haskell, Lisp, etc.
>
>
> On Thu, Aug 4, 2016 at 2:31 PM, Ambrose Laing  > wrote:
>
>> To be completely honest, I would much prefer to keep the notation, but 
>> suggest a different possible solution.
>> I would not complain if the notation goes away, but I would also like to 
>> hear how you feel about the following possible alternative:
>>
>> Maybe we need a formal way to associate keywords with functions and 
>> notations in elm.  In your specific use case, the way this
>> would work is that "range" is a keyword for [ a .. b ].  So on the elm 
>> documentation page, if you type "range", it will first give you
>> all the functions which contain range as a substring (the way it does 
>> now), and then after that also list all functions and/or notations
>> that contain "range" as a keyword, which should pull up [ a .. b ].
>>
>> Another example that has bitten me personally, coming from scala, is I 
>> want to know how to do a flatMap in elm.  As it turns out, it
>> is called concatMap in elm.  If I were coming from Haskell, I would be 
>> busily searching for "bind" or something similar.  The concepts
>> do not have to match exactly, they just have to be close enough, to make 
>> "flatMap" and "bind" become keywords for "concatMap".
>> So if I go search for "flatMap" in the docs, I should easily find 
>> "concatMap", even when elm itself does not have a flatMap function.
>> If we went crazy with this, most keywords / common functions from other 
>> languages would be listed as keywords for their elm equivalents
>> and it could make life easier, I imagine.
>>
>> What do others think of this?
>>
>> The arguments against this are that we can't list every possible relevant 
>> keyword that might be helpful.  My response is that we just do
>> some of the obvious ones and if possible make it so that the keywords can 
>> be crowdsourced from elm users.
>>
>> The only thing is I feel bad suggesting more work that Evan or someone 
>> else will have to do.
>>
>>
>>
>> On Thursday, August 4, 2016 at 4:21:55 PM UTC-4, Richard Feldman wrote:
>>>
>>> Currently the way you do ranges (like, say, to create the list [ 1, 2, 
>>> 3, 4, 5 ]) is this:
>>>
>>> [ 1..5 ]
>>>
>>> This comes up super infrequently, and whenever it does, it's hard to 
>>> Google for - when you want to know things like "can I use variables in 
>>> there?" "is [1..5] going to give me 1,2,3,4,5 or 1,2,3,4?" etc.
>>>
>>> I'd rather drop this special syntax in favor of a simple function:
>>>
>>> List.range : number -> number -> List number
>>>
>>> It'd make for one less piece of syntax to learn, would simplify the 
>>> compiler, and personally I'd find it more convenient to use than the 
>>> special syntax. This way when I want to know how it works I can look it up 
>>> in the List docs like normal!
>>>
>>> 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.

[elm-discuss] Re: Modifying the DOM with external JS libraries

[Ian Mackenzie]

In this particular case, if you're just using highlight.js to highlight a block 
of code, you might also be able to use evancz/elm-markdown 
(http://package.elm-lang.org/packages/evancz/elm-markdown/3.0.0/). You'll still 
need to load a version of highlight.js in your HTML as described by the 
elm-markdown README, but then you should just be able to render a Markdown 
fragment containing a code block without worrying about weird DOM interactions.

-- 
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: undefined: actually I have expected to never face undefined again with elm

[Ian Mackenzie]

Glad I could help! 

Note, though, that the compiler was giving you a pretty strong hint 
(zeroing in on 'substitute' vs 'substitution' as the difference between the 
expected and actual types), and in general is pretty good at giving useful 
error messages. It won't always figure out exactly what's wrong (I've had 
my share of "I am looking for one of the following things: end of input, 
whitespace"), but it does tend to give more useful error messages than a 
lot of other compilers (I'm looking at you, every C++ compiler ever).

On Tuesday, 19 July 2016 19:18:23 UTC+10, Andreas Kobler wrote:
>
> Thanks a lot! 
> Bad typo... was not really awake this morning :-/ Now it works as expected!
>
> 2016-07-19 10:58 GMT+02:00 Ian Mackenzie <ian.e.m...@gmail.com 
> >:
>
>> Try 'rule.substitution' instead of 'rule.substitute'. It looks like the 
>> compiler sees the 'rule.substitute' line and assumes that the 'rule' 
>> variable is something that has a 'substitute' field (and then gets confused 
>> when you try to pass such an object to the RuleTest constructor), instead 
>> of checking it first against your 'apply' type annotation that says that 
>> the second argument is of type Rule.
>>
>> On Tuesday, 19 July 2016 18:15:16 UTC+10, Andreas Kobler wrote:
>>>
>>> Thanks for your hint! The reason for the re-declaration is: Without that 
>>> line, the compiler yields the following error message. My re-declaration 
>>> line was not well-founded, I just try-n-error'ed it out. Is is a 
>>> record-thing, do I call the RuleTest constructor in a wrong way? Do you 
>>> have an explanation for that compiler error without the rule=rule line? Or 
>>> a pointer in a direction how I can figure it out?
>>>
>>> Many thanks
>>>
>>> Code chunk adapted to:
>>>
>>> apply : String -> Rule -> RuleTest
>>> apply input rule =
>>>   let 
>>> output = replace rule.regex rule.substitute input
>>> matched = input /= output
>>>   in
>>> RuleTest rule input output True
>>>
>>>
>>>  error in test.elm:55:5: 
>>> The 1st argument to function `RuleTest` is causing a mismatch.
>>> Function `RuleTest` is expecting the 1st argument to be:
>>> { ..., substitution : ... }
>>> But it is:
>>> { a | ..., substitute : ... }
>>> 
>>> [Finished in 0.1s with exit code 1]
>>> [Elm says]: To highlight build errors: Install with Package Control: 
>>> Highlight Build Errors
>>>
>>>
>>>
>>> Am Dienstag, 19. Juli 2016 09:07:11 UTC+2 schrieb Ian Mackenzie:
>>>>
>>>> The issue is likely with the rule = rule line, as Elm sees that as a 
>>>> recursive variable definition which has known bugs (
>>>> https://github.com/elm-lang/elm-compiler/issues/873). You should just 
>>>> be able to take that line out, there's no need to re-declare a variable 
>>>> with the same name as an argument.
>>>>
>>>> On Tuesday, 19 July 2016 16:59:04 UTC+10, Andreas Kobler wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>> Just started to play around with elm and very eager to get more fluid. 
>>>>> I picked a silly POC scenario of a rule composer: basically you have 
>>>>> regex 
>>>>> rules and want to edit/test them in a form. When applying a regex and 
>>>>> showing the replace output in an input field, I face an "undefined". 
>>>>> Below 
>>>>> you see the isolated part forcing my observation while applying the rule 
>>>>> directly in init.
>>>>>
>>>>> Unfortunately I could really not trace down to the root of this 
>>>>> happening. Is somebody able to tell me:
>>>>> - What I am doing wrong? Why does there an "undefined" appear? (wenn 
>>>>> executing my own "replace" function in the REPL it works fine as expected)
>>>>> - How do you guys debug such behaviour?
>>>>>
>>>>> Here my silly example:
>>>>>
>>>>>
>>>>> module RuleTest exposing (..)
>>>>>
>>>>>
>>>>> import Html.App
>>>>> import Html exposing (..)
>>>>> import Html.Attributes exposing (..)
>>>>> import Regex
>>>>>
>>>>>
>>>>> main : Platform.Program Basics.Never
>>>>> main =
>>>>>   Html.App.program

[elm-discuss] Re: Scrolling to bottom of div

[Ian Mackenzie]

There isn't yet a pure-Elm way to do it, but there's a bunch of discussion 
going on right now about adding setScrollTop and similar functions 
(see https://groups.google.com/forum/#!topic/elm-dev/ThkWudq7SF0). In the 
meantime the answer is likely 'use ports'.

On Tuesday, 19 July 2016 09:27:58 UTC+10, Wayne Choi wrote:
>
> I want to scroll down to the bottom of a div for, what else, a chat app. 
> Right now I'm using element.scrollTop = element.scrollHeight  and it works 
> fine with just javascript and html. Once I port the div to Elm, however, 
> the function doesn't scroll all the way down. Am I missing something with 
> how javascript interacts with the virtual dom? Is there an alternative 
> solution? 
>

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

[elm-discuss] Re: undefined: actually I have expected to never face undefined again with elm

[Ian Mackenzie]

The issue is likely with the rule = rule line, as Elm sees that as a 
recursive variable definition which has known bugs (
https://github.com/elm-lang/elm-compiler/issues/873). You should just be 
able to take that line out, there's no need to re-declare a variable with 
the same name as an argument.

On Tuesday, 19 July 2016 16:59:04 UTC+10, Andreas Kobler wrote:
>
> Hi all
>
> Just started to play around with elm and very eager to get more fluid. I 
> picked a silly POC scenario of a rule composer: basically you have regex 
> rules and want to edit/test them in a form. When applying a regex and 
> showing the replace output in an input field, I face an "undefined". Below 
> you see the isolated part forcing my observation while applying the rule 
> directly in init.
>
> Unfortunately I could really not trace down to the root of this happening. 
> Is somebody able to tell me:
> - What I am doing wrong? Why does there an "undefined" appear? (wenn 
> executing my own "replace" function in the REPL it works fine as expected)
> - How do you guys debug such behaviour?
>
> Here my silly example:
>
>
> module RuleTest exposing (..)
>
>
> import Html.App
> import Html exposing (..)
> import Html.Attributes exposing (..)
> import Regex
>
>
> main : Platform.Program Basics.Never
> main =
>   Html.App.program
> { init = init
> , view = viewRuleTest
> , update = update
> , subscriptions = \_ -> Sub.none
> }
>
>
> type alias Rule = 
>   { regex : String
>   , substitution : String
>   }
>
>
> type alias RuleTest = 
>   { rule : Rule
>   , input : String
>   , output : String
>   , matched : Bool
>   }
>
>
> type Msg 
>   = StartTest String
>
>
>
>
> -- init
> init : (RuleTest, Cmd Msg)
> init =
>   ( apply "reg1" (Rule "reg1" "sub1")
> , Cmd.none
>   )
>
>
> -- update
> update : Msg -> RuleTest -> (RuleTest, Cmd Msg)
> update msg ruleTest =
>   case msg of
>
>
> StartTest input ->
>   ( apply input ruleTest.rule, Cmd.none )
>
>
>
>
> apply : String -> Rule -> RuleTest
> apply input rule =
>   let 
> output = replace rule.regex rule.substitute input
> matched = input /= output
> rule = rule
>   in
> RuleTest rule input output True
>
>
> replace : String -> String -> String -> String
> replace regex substitute input =
>   Regex.replace Regex.All (Regex.regex regex) (\_ -> substitute) input
>
>
> viewRuleTest : RuleTest -> Html Msg
> viewRuleTest ruleTest =
>   div []
> [ label [] [ text "Pattern" ]
> , input [ Html.Attributes.value ruleTest.rule.regex, disabled True ] 
> []
> , label [] [ text "Substitution" ]
> , input [ Html.Attributes.value ruleTest.rule.substitution, disabled 
> True  ] []
> , label [] [ text "Input" ]
> , input [ Html.Attributes.value ruleTest.input, disabled True  ] []
> , label [] [ text "Output" ]
> , input [ Html.Attributes.value ruleTest.output, disabled True  ] []
> , label [] [ text "matched" ]
> , input [ type' "checkbox", checked ruleTest.matched ] []
> ]
>
>
> Environment: 
> elm repl --version
> 0.17.1
> OSX 10.11.3
>
> {
> "version": "1.0.0",
> "summary": "helpful summary of your project, less than 80 characters",
> "repository": "https://github.com/user/project.git;,
> "license": "BSD3",
> "source-directories": [
> "."
> ],
> "exposed-modules": [],
> "dependencies": {
> "elm-lang/core": "4.0.1 <= v < 5.0.0",
> "elm-lang/html": "1.1.0 <= v < 2.0.0"
> },
> "elm-version": "0.17.1 <= v < 0.18.0"
> }
>
>
> Thanks for any advice!
>
> Best, Andi
>
>
>

-- 
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] recursively generating a tree

[Ian Mackenzie]

Good to know!

By the way, is the original code you were working on part of an open-source 
library, by any chance? I'm working on some 2D/3D geometric libraries for 
Elm myself, including stuff like bounding boxes and spatial trees much like 
the one you describe. Might would be worth seeing if there are places we 
can collaborate (or at least not duplicate work if we don't need to). 

On Wednesday, 13 July 2016 07:15:21 UTC+10, Nick H wrote:
>
> Well, it turns out the bug isn't in my code. It is in elm-lang/core 
> .
>
> List.take fills ups the call stack all on its own:
>
> main = [ 1 .. 5000 ] |> List.take 2500 |> toString |> Html.text
>
> List.drop does not have this problem. If we redefine the partition 
> function solely in terms of List.drop, even the code in the OP works fine!
>
> partition _ foos =
> let
> n = List.length foos // 2
> in
>   ( List.reverse foos |> List.drop (n+1) |> List.reverse, List.drop n 
> foos )
>
> I am happy that I learned how to use trampolines though. Maybe it will 
> come in handy some day :-)
>
> On Tue, Jul 12, 2016 at 11:17 AM, Nick H  > wrote:
>
>> So I felt this 0.16 tutorial 
>> 
>>  
>> helped me understand trampolines better. Then it took a bit of work 
>> rewriting `create` in a way that utilized tail calls. But the new version 
>> is still failing with "too much recursion." Adding or removing the 
>> trampolines doesn't seem to make a difference.
>>
>> Below is a SSCCE, with dummy implementations for wrap and partition. In 
>> anybody has insight into what I am doing wrong, I would really appreciate 
>> it!
>>
>> module Main exposing (..)
>>
>> import Html
>> import Dict exposing (Dict)
>> import Trampoline exposing (Trampoline)
>>
>>
>> main =
>> [1..4500] |> create |> toString |> Html.text
>>
>>
>> create : List Foo -> Tree
>> create foos =
>> Trampoline.evaluate (descend foos [])
>>
>>
>> type Partial
>> = LeftBranch Bar (List Foo)
>> | RightBranch Bar Tree
>>
>>
>> descend : List Foo -> List Partial -> Trampoline Tree
>> descend incomplete stack =
>> case incomplete of
>> [] ->
>> Trampoline.jump (\_ -> ascend (Leaf emptyFoo) stack)
>>
>> foo :: [] ->
>> Trampoline.jump (\_ -> ascend (Leaf foo) stack)
>>
>> _ ->
>> Trampoline.jump
>> (\_ ->
>> let
>> bar =
>> wrap incomplete
>>
>> ( left, right ) =
>> partition bar incomplete
>> in
>> descend left (LeftBranch bar right :: stack)
>> )
>>
>>
>> ascend : Tree -> List Partial -> Trampoline Tree
>> ascend complete stack =
>> case stack of
>> [] ->
>> Trampoline.done complete
>>
>> (LeftBranch parent sibling) :: remainder ->
>> Trampoline.jump
>> (\_ ->
>> descend sibling (RightBranch parent complete :: 
>> remainder)
>> )
>>
>> (RightBranch parent sibling) :: remainder ->
>> Trampoline.jump
>> (\_ ->
>> ascend (Node parent sibling complete) remainder
>> )
>>
>>
>> type alias Bar =
>> String
>>
>>
>> type alias Foo =
>> Int
>>
>>
>> type Tree
>> = Leaf Foo
>> | Node Bar Tree Tree
>>
>>
>> wrap : List Foo -> Bar
>> wrap =
>> toString
>>
>>
>> partition : Bar -> List Foo -> ( List Foo, List Foo )
>> partition _ foos =
>> let
>> n =
>> List.length foos // 2
>> in
>> ( List.take n foos, List.drop n foos )
>>
>>
>> emptyFoo : Foo
>> emptyFoo =
>> 0
>>
>>
>> On Tue, Jul 12, 2016 at 10:08 AM, Max Goldstein > > wrote:
>>
>>> Nah, trampoline takes some mental gymnastics! Hope it's helpful for your 
>>> tree problem.
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@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: Is there a reason Date has no setters?

[Ian Mackenzie]

I think one other thing to keep in mind is that Evan has expressed a lot of 
interest in other (non-JavaScript) compilation targets in the future, so I 
think he would be very cautious about tying core library functionality too 
closely to exactly how JavaScript happens to do things. Especially for 
stuff like date/time manipulation which (correct me if I'm wrong) is 
unlikely to be a performance bottleneck, I think the best long-term 
solution is going to be a well thought out pure-Elm library using common 
Elm patterns and idioms - which would probably look very different than a 
direct wrapper over JavaScript. Perhaps that is something that will be 
implemented as a core library at some point, but right now I'd imagine a 
lot of other things are a higher priority.

On Monday, 20 June 2016 08:00:00 UTC+10, Dan P wrote:
>
> I appreciate the immutability part, but we can make these setters into 
> pure functions by creating new Date objects with each call.
>
> Secondly, when you're rewriting pure functions provided by the JS API 
> itself, the only thing you do is increase the chance of an implementation 
> mistake. The only thing that isn't totally uniform across browsers is 
> Date.parseString(). There are things that can be improved, like how Haskell 
> uses types to distinguish UTCTime and LocalTime, but don't fix what ain't 
> broke.
>
>
> On Sunday, June 19, 2016 at 5:37:15 PM UTC-4, Joey Eremondi wrote:
>>
>>  reproduces working JS APIs
>>
>>
>> This is the goal! Reproducing libraries in pure Elm is much safer and 
>> more desirable than writing wrappers around JS.
>>
>> Make sure that whatever you do, you respect Elm's philosophy: all data is 
>> immutable, and side-effects are always wrapped in a Task or a Cmd.
>>
>> On Sun, Jun 19, 2016 at 1:31 PM, Dan P  wrote:
>>
>>> I realize elm-date-extra  
>>> exists, 
>>> but it's bloated, (apparently) unstable, reproduces working JS APIs, and is 
>>> not likely to be merged to core any time soon[1]. I'm considering making a 
>>> simplified fork of the former, but this rejected pull request 
>>>  gives me pause. Can anyone 
>>> more familiar with the Elm ecosystem please advise?
>>>
>>> [1]: Not to say that it doesn't also provide useful functionality! But 
>>> core.Date is a little spartan, don't you think?
>>>
>>>
>>>
>>> On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote:

 (e.g. Date.setDate() in JS)

 Or would a pull request not be in vain?

 Compare:
 http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date


 https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date

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

Re: [elm-discuss] Any open source elm project example for multi-page app?

[Ian Mackenzie]

You might want to look at the examples from the 'navigation' package 
(http://package.elm-lang.org/packages/elm-lang/navigation/1.0.0/) and the 
related url-parser package 
(http://package.elm-lang.org/packages/evancz/url-parser/1.0.0/).

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

Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System

[Ian Mackenzie]

Just to throw my two cents in, I'd want to be pretty conservative about any 
macro/code gen system if there is an official one at all. One of the things I 
love about Elm is that the restrictive nature of the language makes code very 
easy to follow and understand, and naturally causes libraries to follow similar 
patterns (things like JSON decoders, random generators and elm-check producers 
all follow very similar patterns largely because the constraints of the 
language mean that there's really only one good way to do it).

I'm worried that a macro system will let people get a bit "too creative" with 
their code and we'll end up with indecipherable stuff like injection-based HTTP 
servers with endpoints and parameter names magically deduced from function 
signatures. Like how Evan has said that the Elm Architecture "seems to emerge 
naturally in Elm", I think the current language structure does a great job of 
encouraging good design, and I'm worried that a macro system could hurt that.

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

[elm-discuss] Re: How do you handle module name clashes?

[Ian Mackenzie]

I think some sort of guideline for module names would be good, similar to 
what exists in the Java or .NET worlds - I've been using an 
'Organization.Package.Module' scheme for my (yet to be published) code. 
Easy enough to use 'import as' to shorten things up.

On Saturday, 11 June 2016 06:52:10 UTC+10, Yosuke Torii wrote:
>
> I'm curious about it too.
>
> For library authors, there seems no way to check duplication automatically.
> Is this a new issue, or is there a guideline about module names?
>
>
> 2016年6月10日金曜日 21時55分35秒 UTC+9 Peter Damoc:
>>
>> I want to use 
>>
>> mdgriffith / elm-style-animation / Style
>> and 
>> seanhess / elm-style / Style
>>
>> How does one handles such situations?
>>
>> The modules do something completely different and are complementary 
>> somehow. 
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

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

[elm-discuss] Re: How can I do module level configuration?

[Ian Mackenzie]

I think the first solution (context/options argument) is the clearest and 
simplest. Yes, it's a bit verbose, but:

   - You can use the 'view' and 'viewWithOptions' pattern where the former 
   calls the latter with a default primary color etc., so you can get 
   convenience if you don't care about customizability
   - Users can easily do something like `myView = viewWithOptions 
   myOptions' in their own code and then just use that partially-applied 
   function everywhere (with the advantage that they can control exactly where 
   and how the partial application happens)
   - It's very clear what's going on - one of the things I love about Elm 
   is that it's much easier than other languages to trace the flow of logic 
   and see how things work without having to worry about hidden/implicit state 
   or context. Creating a module-like record seems to move a little ways in 
   the 'magic' direction...

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