[elm-discuss] Re: List of all members of a union type

[OvermindDL1]

OCaml has a set of extension points.  You can write OCaml code, add it to 
an extension point (`derived` is precisely the use case of this) and it 
receives the AST of the expression and can transform it or add new code or 
whatever as you wish.  Like a very common one for auto-json conversion 
works like (example taken from docs):
```ocaml
type geo = {
  lat : float;
  lon : float;
}
[@@deriving yojson]
```
And this generates two functions in the module with the types of:
```ocaml
val geo_of_yojson : Yojson.Safe.json -> (ty, string) Result.result
val geo_to_yojson : ty -> Yojson.Safe.json
```
And they have a set of options so you can override the key names in the 
json or override the variant names or change the encoding of things like, 
oh, integers or specify a default value if it is missing and so forth. 
 Extension points like this in Elm would save on *so* much manually made 
code in so many cases...


On Friday, May 5, 2017 at 11:57:35 PM UTC-6, Simon wrote:
>
> I had a different use case for the same basic idea. With GraphQL we have a 
> sort-of typed query language that returns clearly defined json structures. 
> In an ideal world therefore you should be able to define an Elm data 
> structure (sum or union type) and for library functions to be able to 
> create the query string and the json decoder for you. I may be over 
> optimistic, and such things may not even be possible in other ML-family 
> languages, but it felt like something that should be automatable
>
>
>
> On Thursday, 4 May 2017 04:14:03 UTC+2, Matt Hughes wrote:
>>
>> At first I wondered if a type is really what you need for this 
>> application, as opposed to say a list of strings. Anyway one idea is to 
>> write a function to explicitly convert the type to a string. I think this 
>> is better than simply taking the type name and making it a string because 
>> the string representation may need spaces or other punctuation. Using an 
>> explicit case means the compiler won't let you forget if you add a new 
>> type. 
>>
>> module Main exposing (..)
>>
>> import Html exposing (Html, text)
>>
>> type Province = Alberta | BritishColumbia | Saskatchewan
>>
>> toString : Province -> String
>> toString p =
>> case p of
>> Alberta -> "Alberta"
>> BritishColumbia -> "British Columbia"
>> Saskatchewan -> "Saskatchewan"
>>
>> main : Html a
>> main =
>> text (toString Alberta)
>>
>> mch
>>
>> On Tuesday, May 2, 2017 at 9:44:34 PM UTC-6, Matthew Buscemi wrote:
>>>
>>> I have run into a problematic use case a couple of times, and based on 
>>> Slack discussions earlier today, it seems I'm not alone.
>>>
>>> The situation occurs when, for some reason, I need to maintain a list of 
>>> all constructors of a union type. The example given in Slack by mltsy:
>>>
>>> type State = Alabama | Alaska | Arizona | Arkansas | ...
>>>
>>> allStates = [ Alabama, Alaska, Arizona, Arkansas, ...]
>>>
>>> stateSelectBox : List State -> Html Msg
>>> stateSelectBox states =
>>>   let stateValues = List.map toString states
>>>   in ...
>>>
>>> In the example above, simply turning allStates into a list of strings 
>>> would be fine for this particular use case, but in the context of a larger 
>>> system, it could be inadequate–other functions besides stateSelectBox may 
>>> want to utilize the power of performing a case over the union type. 
>>> However, the above solution is also structurally undesirable–if a new type 
>>> is added to State, then the programmer must also remember to update 
>>> allStates separately. The duplication and tight coupling are disconcerting, 
>>> and yet I can't see a viable alternative that preserves the power of types 
>>> without incurring the duplication.
>>>
>>> I have wondered if a language-level construct that takes a union type 
>>> and returns a list of all constructors for that type would be appropriate 
>>> for Elm. Just a thought.
>>>
>>> - Matt
>>>
>>>
>>>

-- 
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-css with type classes (a response to the Elm Town podcast)

[OvermindDL1]

Yep, that is all trivial with Polymorphic Variants if you want them shared.

In essence, you know how a normal variant is, like this (in OCaml syntax 
since that is what I'm more comfortable with, but it's close enough to Elm, 
'almost' identical)
```ocaml
type Vwoop =
| Infinite
| Int of integer

type Broop =
| Infinite
| Float of float
```
And say you have some functions like (again in OCaml syntax):
```ocaml
let vloo = function
| Infinite -> "infinite"
| Int i -> string_of_integer i

let bloo = function
| Infinite -> "all"
| Float f -> string_of_float f
```
Now this will not compile, there are two Infinite's in scope and so it does 
not know which you want or mean without qualifying them by name.  If 
however we did not have the variant types above and just used polymorphic 
variants:
```ocaml
let vloo = function
| `Infinite -> "infinite"
| `Int i -> string_of_int i

let bloo = function
| `Infinite -> "all"
| `Float f -> string_of_float f
```
And this all works fine, you could use it like this no problem:
```ocaml
let whatever = String.concat [vloo `Infinite; bloo `Infinite]
```
And `whatever` will become the string "infiniteall" as expected.

A Polymorphic Variant is just a 'globally scoped' variant, and it is not 
based on the name but the entire type, so ``` `Int ``` is different from 
``` `Int 42 ```, so this will *not* compile:
```ocaml
let this_does_not_compile = vloo (`Int 42.7)
```
This will give you the error (I just ran this to test):
```
Line 9, 33: Error: This expression has type [> `Int of float ]
   but an expression was expected of type [< `Infinite | `Int of int ]
   Types for tag `Int are incompatible
```
So it is trying to pass in the specific type of `Int of float, yet the 
function only accepts the closed set of polymorphic varianst of `Infinite 
or `Int of int.  It then goes on to clarify that the `Int is fine but the 
type inside the `Int is wrong/incompatible.  For further example if I try 
to past in `Blah it returns:
```
Line 9, 33: Error: This expression has type [> `Blah ]
   but an expression was expected of type [< `Infinite | `Int of int ]
   The second variant type does not allow tag(s) `Blah
```
It is type safe the whole way through.  And of course you can add types to 
it as well if you want, they are exactly as they appear in the error 
messages.


For note, `function` is a keyword in OCaml that is short for a combination 
fn and match, so these are the same:
```ocaml
let tester = function
| `Test1 -> "test1"
| `Test2 -> "test2"

let tester t = match t with
| `Test1 -> "test1"
| `Test2 -> "test2"
```

For note, polymorphic variants are just like normal variants, in the 
generated javascript they get tagged like any normal variant, just with a 
larger number due to their scope.  The above tester/bloo/vloo functions 
compile to this javascript:
```javascript
var Pervasives = require("stdlib/pervasives");

function vloo(param) {
  if (typeof param === "number") {
return "infinite";
  }
  else {
return Pervasives.string_of_int(param[1]);
  }
}

function bloo(param) {
  if (typeof param === "number") {
return "all";
  }
  else {
return Pervasives.string_of_float(param[1]);
  }
}

function tester(t) {
  if (t >= 549646208) {
return "test2";
  }
  else {
return "test1";
  }
}
```

But yes, as you can see polymorphic variants types can be open (accepting 
any) or closed (accepting a limited subset), fully typed and safe the whole 
way down.

A lot of people consider polymorphic variants existence a bit of a wart, 
but I do not see it, they are highly highly useful in specific cases (like 
DSEL's here), but I do agree they can be abused when normal variants are 
better...


On Thursday, April 27, 2017 at 2:26:10 PM UTC-6, Mark Hamburg wrote:
>
> Maybe this is covered in OCaml's polymorpic variants — I couldn't tell 
> from a quick skim — but another feature that would cover this without 
> introducing type classes is support for more arbitrary union/sum types. 
> That way, one could write something like:
>
> type Auto = Auto
>
>
> type alias LengthOrAuto = Int + Auto -- is this a type or a type alias, 
> I'm not sure
>
> margin : LengthOrAuto -> Style
>
> Handwaving type checking rules would require that a type passed to 
> something that was expecting a union type needs to cover a subset of that 
> union type. Case statements would be used to do the discrimination.
>
> The potentially interesting things that come out of something like this 
> are that one could imagine a union of Maybe and Result which would allow 
> for a value or an error or nothing. This has got to have been explored 
> somewhere befor

Re: [elm-discuss] elm-css with type classes (a response to the Elm Town podcast)

[OvermindDL1]

Actually this sounds to exactly like the use-case for OCaml's Polymorphic 
Variants.  In OCaml you could easily use just `Hidden for both of your 
examples, fully type checked, type safe, etc... etc...  Polymorphic 
Variants are just global Variants that are unnamed.  A function can take a 
bounded or unbounded set of them and are perfectly suited for an abstract 
CSS DSL while being readable in both usage and implementation.

And yes, I agree about type classes, they are extremely over-used in 
Haskell where something like OCaml's Implicit Modules would be such a 
significantly better fit for...


On Thursday, April 27, 2017 at 6:21:22 AM UTC-6, Mitchell Rosen wrote:
>
> Hi Joey,
>
> Indeed, basic ADTs are one way to model the DSL. The problem then arises 
> when you want to reuse the name "auto" for another key.
>
> I may not have been clear, so I'll try to summarize my post here. How 
> might elm-css look if there were different features in Elm? As it stands, 
> the library seems to be fighting hard against the language, and the result 
> far from beginner-friendly.
>
> Type classes are one such extension, and I sketched out how one might 
> implement this library using them. As you mentioned, ADTs are another.
>
> In this particular case, type classes, as flawed as they are, seem vastly 
> superior to the row-types approach. But, I'm definitely open to having my 
> mind changed! I'm just not comfortable enough with row types as a language 
> feature to really have an intuitive understanding of when to use them, and 
> when to not.
>
> But, anyways, I totally agree that keeping it simple with ADTs is what you 
> should do most of the time. It's only when you're writing library code to 
> be used by the community that you should start obsessing over the 
> ergonomics.
>
>

-- 
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: Google Places and Elm / Identifying when Elm is mounted

[OvermindDL1]

Elm creates nodes on a screen re-draw, so it does not create and edit nodes 
all the time but only when the browser needs it to for the updated state.

The 'safest' thing is to wait for *2* iterations of requestAnimationFrame, 
1 will 'sometimes' work but it depends on the ordering (register yours 
after elm's), however 2 has always worked for me without issue.


On Monday, April 3, 2017 at 11:33:07 PM UTC-6, Fikse wrote:
>
> Thanks Christian. That does work. Now I'm attempting to translate this 
> into an application using react-elm-components.
>
> I am already using Html.programWithFlags for passing in flags, and I can 
> pass in ports using this method as well. I am now faced with the same 
> problem where it is unclear when all of the DOM nodes are available Elm 
> creates. I have tried using setInterval along with ReactDOMNode.findDOMNode 
> to query for certain DOM nodes with no luck.
>
> On Monday, April 3, 2017 at 6:47:10 PM UTC-6, Christian Charukiewicz wrote:
>>
>> I think what you want to do here is load your compiled Elm js script 
>> followed by your googleapis script.
>>
>> One way to do this would be to use jQuery's getScript() function (or a 
>> vanilla JS equivalent of it ) to 
>> sequence the order of the loading.
>>
>> With jQuery your approach would look something like this (note I have not 
>> tested this code):
>>
>> 
>> 
>>
>> function initElmApp(callback) {
>> var node = document.getElementById('elm');
>> var app = Elm.Main.embed(node);
>> callback();
>> }
>>
>> function initGoogleScript() {
>> $.getScript('path/to/google-places');
>> }
>>
>> initElmApp(initGoogleScript());
>>
>>
>> Someone else may have a better way to do this, but this should work.
>>
>>
>> On Monday, April 3, 2017 at 7:11:09 PM UTC-5, Fikse wrote:
>>>
>>> Is there a way to tell if Elm is mounted in the DOM? I am attempting to 
>>> use Google Places with ports. The Google Places code is trying to attach to 
>>> an HTML element generated by Elm, but it doesn't exist on the page. My code 
>>> is at https://ellie-app.com/Pzg2NLX7W5a1/3 and the error can be found 
>>> in the developer tools console.
>>>
>>>
>>> - fikse
>>>
>>>

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

Re: [elm-discuss] How can you find out why JSON decoding failed?

[OvermindDL1]

Hehe, happens to us all.  ^.^


On Friday, February 17, 2017 at 11:54:47 AM UTC-7, Rex van der Spuy wrote:
>
> Oops!! Ignore the error above!
> It works now completely!!!
>
> I just had another stray Debug.crash in my code that I had forgotten about 
> so I removed it.
>
> Thanks so much Peter, I could not have done this without your help
>
>

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

Re: [elm-discuss] Problem running from .js file

[OvermindDL1]

Well XHTML is XML, and if you mark the webpage as XHTML by having the XML 
DOCTYPE (absolutely required) and have a correct xmlns attribute in the 
 (also absolutely required) then it would likely do what you expected.

However, HTML5 is not even remotely XHTML (much as I wish XHTML took over, 
regular parsing is so much easier than the horror that is HTML4/5) as not 
only does it allow some tags to not have an ending tag, it mandates it in 
some places, and forces you to make explicit ending tags even on things 
that never have content.  Sadly, HTML5 is where all development is being 
done, XHTML is dead and missing features now.


On Tuesday, February 14, 2017 at 11:55:20 PM UTC-7, Fabian B wrote:
>
> Thank you.
> Apparently [X]HTML is not XML.
>
> On Tuesday, February 14, 2017 at 6:26:58 PM UTC+2, Peter Damoc wrote:
>>
>> main_js.html is invalid 
>>
>> you need 
>> 
>> not 
>> 
>>
>>
>>
>>
>> On Tue, Feb 14, 2017 at 1:13 AM, Fabian B  wrote:
>>
>>> I created a github project that shows my problem:
>>> https://github.com/fabian20ro/elm-sample - see the readme links...
>>>
>>> How should I change the main_js.html to properly use what elm-make 
>>> --output main.js produced?
>>> I'm really puzzled since eveywhere I look I see exactly this example. I 
>>> assume since everyone is giving it, it should work for everybody else?!
>>>
>>> Thanks for the help.
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> 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: Seeking feedback: What Elm and Rust teach us about the future

[OvermindDL1]

That is just because Rust has a fairly powerful (but incomplete) macro 
system, that is not something that would really belong in Elm.  ^.^

On Friday, February 10, 2017 at 11:19:49 AM UTC-7, Kasey Speakman wrote:
>
> Largest paint point for me in Elm is not mentioned: JSON. Rust appears to 
> have adequate facilities for this (Serde).
>
> Otherwise, looks good. It was interesting to learn more about Rust and the 
> intersection of features with Elm.
>
> On Wednesday, February 8, 2017 at 2:22:11 AM UTC-6, Martin Cerny wrote:
>>
>> (This is a cross-post from r/elm and r/rust)
>>
>> Hi all,
>> I wrote a blog post about the striking similarities between Elm and Rust, 
>> and why I think it is no coincidence different languages took some similar 
>> design paths. I'll be super happy to receive some feedback on the post to 
>> let me improve it:
>> https://dev.to/martincerny/what-elm-and-rust-teach-us-about-the-future
>>
>> Thanks
>> Martin
>>
>

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

[OvermindDL1]

I'm not certain as I've not looked in the compiler, but based on how it 
works it seems to me that Elm's partial records in functions is a form of 
row-typing on traditional Hindley-Milner types.


On Friday, February 10, 2017 at 5:30:22 AM UTC-7, Rupert Smith wrote:
>
> For my undergraduate project (20+ years ago), I implemented a language 
> called Ob<: (or ObSub) from "A Theory of Objects" by Abadi and Cardelli. 
> This language is related to the functional language F<: (functional 
> calculus with sub-typing), which is somewhat related to F#. My project 
> supervisor worked for Microsoft Research and was involved in the .Net 
> project.
>
> One thing about Ob<: is that due to the sub-typing relation in the 
> language, typing became semi-decideable. Given a type and a program, you 
> can decide if the program fits the type (checking), but given a program you 
> cannot work out what its type is (inference). This meant that you had to 
> give the type in full of every program you wrote - sometimes the type was 
> longer than the program!
>
> As I understand it, Elm uses a different extensible record type to that of 
> OO languages with full-blown sub-typing? Does anyone have a reference to 
> the paper this is based on? 
>
> And am I right in thinking that this version of extensible records is 
> fully decideable and all types can always be infered?
>
> I am just trying to understand what exactle extensible records are and 
> what their limitations are. As far as I can tell, sub-typing cannot really 
> be represented in Elm - the concrete type of something must be known fully 
> in advance? Makes sense I suppose, there is no dynamic loading and linking 
> of code at runtime, and allowing it would need runtime type checks (uuughh).
>
> 
>
> I added this example here to one of the compiler issues:
>
> https://github.com/elm-lang/elm-compiler/issues/1504
>
> type alias Record1 =
> { field : String, otherField : String }
>
>
> type alias Record2 =
> { otherField : String }
>
>
> type Grouping
> = R1 Record1
> | R2 Record2
>
>
> extract : (a -> String) -> Grouping -> String
> extract selector grouping =
> case grouping of
> R1 record ->
> selector record
>
> R2 record ->
> selector record
>
> What I am trying to do here is to write a general function that will let 
> me select a field from a record type out of a choice of several different 
> record types. I also tried recently to reformulate this using extensible 
> records but just ended up in a mess.
>
> This came about because I was trying to map a data model which on the 
> server side in Java does use sub-typing. I suspect that what I need in 
> order to be able to extract an arbitrary field at runtime from a set of 
> fields is to use a Dict...
>

-- 
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: Possible performance bug when using SVG xlink:href?

[OvermindDL1]

Hmm, I saw no difference between them in rendering times in Firefox, maybe 
it is a Chrome bug with xref then?  Maybe try making a pure 
html/svg(/javascript) version and see if the same issue occurs?


On Thursday, February 9, 2017 at 4:53:07 AM UTC-7, Julian wrote:
>
> On Thursday, February 9, 2017 at 1:07:27 AM UTC+9, OvermindDL1 wrote:
>>
>> It is not strictly be design (that might be a bug if you can come up with 
>> a simple descriptive example that we can copy into elm-try or so), but it 
>> is easy to work-around.
>>
>
> Did you try my gist? I updated it to make it easier to work with elm-try. 
> https://gist.github.com/Shump/bd778bde23af0dd3f8c95f92ec45fc33 If you run 
> each of them and enable "Paint Flashing" in chrome's devtools (open console 
> -> click "three dots" option menu -> click "Rendering" -> check 
> "Paint Flashing"), you'll see that the version with *use* tags repaints 
> the whole board (bad performance), and the one using "normal" shapes only 
> repaints the hovering tile (good performance).
>  
>
>> What I do is make just an integer (some primitive value), and just 
>> increment it whenever the view should be updated (gotta be careful to catch 
>> all cases though), then use that as the key in a `lazy` call that then 
>> wraps the rest of the view, that way the view only updates when the integer 
>> key is incremented (I wrap it around at 2 billion just-in-case that ever is 
>> hit).
>>
>> However that makes the diff compare only the key before checking 
>> everything else, and if the key integer is unchanged then the entire view 
>> is skipped for diffing, thus making it very fast.  :-)
>>
>> You can add more keys and more lazy's for sections of the board as well 
>> if you need to get more fine grained.  Just always try to use a primitive 
>> as the key or a record that is passed verbatim from model update to model 
>> update.
>>
>
> I feel like it shouldn't be necessary to look into adding keys for 
> performant rendering with *use* tags when it is not needed for "normal" 
> shapes... This is why I'm wondering if this might be a bug... or if it 
> turns out that this is intentional, and *use* tags are performance 
> killers, it should probably be mentioned in the documentation...
>
> I'm sorry if this wasn't clear in my original post... I hope this makes 
> things clearer.
>

-- 
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: Possible performance bug when using SVG xlink:href?

[OvermindDL1]

It is not strictly be design (that might be a bug if you can come up with a 
simple descriptive example that we can copy into elm-try or so), but it is 
easy to work-around.

What I do is make just an integer (some primitive value), and just 
increment it whenever the view should be updated (gotta be careful to catch 
all cases though), then use that as the key in a `lazy` call that then 
wraps the rest of the view, that way the view only updates when the integer 
key is incremented (I wrap it around at 2 billion just-in-case that ever is 
hit).

However that makes the diff compare only the key before checking everything 
else, and if the key integer is unchanged then the entire view is skipped 
for diffing, thus making it very fast.  :-)

You can add more keys and more lazy's for sections of the board as well if 
you need to get more fine grained.  Just always try to use a primitive as 
the key or a record that is passed verbatim from model update to model 
update.


On Wednesday, February 8, 2017 at 5:43:26 AM UTC-7, Julian wrote:
>
> Hi all!
>
> I've been working on a board game using elm and I'm using svg for 
> rendering. I render the game by first drawing the board in the background, 
> and then I render one square for each tile that can hold a game piece. When 
> implementing this, I created a svg symbol for every variation of the tiles 
> (empty, filled, mouse over,...) and for each tile rendered, I reference the 
> symbol to use with the *use* tag and *xlink:href* attribute.
>
> To start with, for unknown reason, chrome fires an event every time the 
> mouse moves over a tile even if I only register for mouseover events on the 
> tiles. This would be fine if it wasn't for the fact that the whole board is 
> being re-rendered on *every* mouseover event, even though the underlying 
> model never changes (mouse is only moving inside a tile, so ideally I 
> wouldn't have to redraw anything).
>
> When digging into the javascript code, I noticed that the diff mechanism 
> always marks the whole model as being changed, and therefor force a full 
> re-render. However, when I manually diff json representations of the model, 
> I see that they are identical. I noticed that when *diffFacts* is being 
> called with the use tags' attributes object (containing the *xlink:href*), 
> it always marks it as a change even if they are identical.
>
> For comparison, I made an isolated version where I compared rendering two 
> tiles using symbols vs just simply rendering rect tags directly (switching 
> the fill color). And as expected, for the non-symbol version, re-render is 
> only triggered when the model actually changes, and always triggered when 
> using symbols.
>
> Here is a gist for the isolated version 
> https://gist.github.com/Shump/bd778bde23af0dd3f8c95f92ec45fc33
>
> Any idea if this is expected behavior? Or is this a bug with the virtual 
> dom code?
>

-- 
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: Fire an event when a div changes size?

[OvermindDL1]

Yeah that is hard to do in Elm, best method would be to get the CSS to do 
it for you if at all possible, else fall back to a port.


On Tuesday, January 31, 2017 at 9:54:16 AM UTC-7, Rupert Smith wrote:
>
>
>
> On Tuesday, January 31, 2017 at 4:32:47 PM UTC, OvermindDL1 wrote:
>>
>> Probably the easier way would be to just get its new size when its 
>> content changes, you can Json.Decode it out of a custom event if you can 
>> somehow get it to fire an event, any event
>>
>
> Yes, I can easily get its size if I can get it to fire an event. I just 
> wondered if someone knows a trick to make that happen? 
>
> Otherwise its a port or rethinking the DOM or CSS a bit.
>  
>
>> (a port, or just grab it from the port?).
>>
>> Would it not be easiest to finagle the CSS to do what you want instead, 
>> or are you needing to know the size explicitly in code?
>>
>
>

-- 
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: Fire an event when a div changes size?

[OvermindDL1]

Probably the easier way would be to just get its new size when its content 
changes, you can Json.Decode it out of a custom event if you can somehow 
get it to fire an event, any event (a port, or just grab it from the port?).

Would it not be easiest to finagle the CSS to do what you want instead, or 
are you needing to know the size explicitly in code?


On Tuesday, January 31, 2017 at 9:16:26 AM UTC-7, Rupert Smith wrote:
>
> On Tuesday, January 31, 2017 at 4:14:51 PM UTC, Rupert Smith wrote:
>>
>> If I can get an event to fire then I can use debois/elm-dom to get its 
>> size.
>>
>> I am rendering some markdown into a div, and I want to pick up the new 
>> size of the div as its contents change. The markdown is being edited 
>> elsewhere, so I can't just use onInput. It is possiblt to walk around the 
>> DOM tree with elm-dom, but that is something I would rather avoid. Can 
>> anyone think of a way of getting an event to trigger on the div having its 
>> contents changed?
>>
>> Looking through the list of DOM events, I didn't figure out yet which 
>> event I can make use of...
>>
>> http://www.w3schools.com/jsref/dom_obj_event.asp
>>
>
> I should also add that the div where the content being edited is not the 
> parent/child/sibling of the one showing the markdown, which is why walking 
> the DOM tree from the input div to the output div is going to be tricky. 
>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

I use browserify for some code via brunch, rollup for others, I run both of 
those through uglify + closure when building a 'prod' release.  browserify 
and rollup and both blazing fast in compile time with very large bases of 
code, but rollup prunes based on functions called (meaning it can break on 
dynamic name access, but that is rare) and browserify just prunes based on 
module importing (which can break on dynamic module name access, but that 
is also rare).  uglify is just a minimizer but it does few optimizations 
but runs fast, however Google's closure runs *very* slow, but optimizes 
well, however higher optimization levels will ruin any code that does any 
kind of dynamic key access that is not dict-like (it breaks elm pretty hard 
last I tried it, but it works on my bucklescript code 'so far').


On Wednesday, January 25, 2017 at 8:45:12 AM UTC-7, GordonBGood wrote:
>
>
>
> On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote:
>>
>> Sent too soon.
>>
>> Also, uglify is a minimizer, it does a *lot* more than tree shaking.
>>
>>
>> On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>>>
>>> Tree Shaking as implemented by Brunch and Webpack default setups at 
>>> least only prune based on if a module is accessed or not (which is also why 
>>> it is easy to fool if you use a non-static string for the name).  I've not 
>>> seen any tree shaking yet that does otherwise.  Although the fascinating 
>>> rollup.js does a lot better by pruning functions very effectively, I need 
>>> to try that one with Elm.  :-)
>>>
>>>
>>> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund 
>>> Hansen wrote:
>>>>
>>>>
>>>> Actually tree shaking will do absolutely nothing for Elm code as Elm 
>>>>> compiles everything into a single module that all highly indirectly 
>>>>> references itself.  It would help with bucklescript as it outputs 
>>>>> modules, 
>>>>> but bucklescript already tree-shakes as part of its compiler 
>>>>> optimizations 
>>>>> anyway.
>>>>>
>>>>
>>>> This is false. You are correct that Elm compiles everything into a 
>>>> single module, but this means that tree-shaking becomes *easier*, not 
>>>> harder. It also makes name-mangling much easier, as everything is 
>>>> local-scope. With Elm code, tree-shaking can be done with Uglify.js. Just 
>>>> tell uglify to warn you when it removes a function, and you'll see it 
>>>> removes *a lot* of code.
>>>>
>>>
> I see there is the old Google Web Compiler, Browserify, Uglify, Rollup and 
> I don'e know how many others.  Has anyone compared them all and has any 
> recommendations on which to use?  If some such as Uglify and Rullup do so 
> much more than just Tree Shaking, what are the disadvantages in their use, 
> speed of "compilation"?
>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

Sent too soon.

Also, uglify is a minimizer, it does a *lot* more than tree shaking.


On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote:
>
> Tree Shaking as implemented by Brunch and Webpack default setups at least 
> only prune based on if a module is accessed or not (which is also why it is 
> easy to fool if you use a non-static string for the name).  I've not seen 
> any tree shaking yet that does otherwise.  Although the fascinating 
> rollup.js does a lot better by pruning functions very effectively, I need 
> to try that one with Elm.  :-)
>
>
> On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund Hansen 
> wrote:
>>
>>
>> Actually tree shaking will do absolutely nothing for Elm code as Elm 
>>> compiles everything into a single module that all highly indirectly 
>>> references itself.  It would help with bucklescript as it outputs modules, 
>>> but bucklescript already tree-shakes as part of its compiler optimizations 
>>> anyway.
>>>
>>
>> This is false. You are correct that Elm compiles everything into a single 
>> module, but this means that tree-shaking becomes *easier*, not harder. It 
>> also makes name-mangling much easier, as everything is local-scope. With 
>> Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn 
>> you when it removes a function, and you'll see it removes *a lot* of code. 
>>
>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

Tree Shaking as implemented by Brunch and Webpack default setups at least 
only prune based on if a module is accessed or not (which is also why it is 
easy to fool if you use a non-static string for the name).  I've not seen 
any tree shaking yet that does otherwise.  Although the fascinating 
rollup.js does a lot better by pruning functions very effectively, I need 
to try that one with Elm.  :-)


On Wednesday, January 25, 2017 at 2:55:18 AM UTC-7, Robin Heggelund Hansen 
wrote:
>
>
> Actually tree shaking will do absolutely nothing for Elm code as Elm 
>> compiles everything into a single module that all highly indirectly 
>> references itself.  It would help with bucklescript as it outputs modules, 
>> but bucklescript already tree-shakes as part of its compiler optimizations 
>> anyway.
>>
>
> This is false. You are correct that Elm compiles everything into a single 
> module, but this means that tree-shaking becomes *easier*, not harder. It 
> also makes name-mangling much easier, as everything is local-scope. With 
> Elm code, tree-shaking can be done with Uglify.js. Just tell uglify to warn 
> you when it removes a function, and you'll see it removes *a lot* of code. 
>

-- 
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: Html.Attributes.none

[OvermindDL1]

Yes, for precisely the same usage.  It is much easier to swap between 
something and `none` then it it to do list building with if conditions.  I 
made my own by using a dummy attribute name that should 'never be used' 
(*cough*) of "nonenonenone".

A side effect is the vdom checking is a little more efficient if more than 
1 set of things change at once since the overall 'shape' of the vdom does 
not change.  ^.^


On Tuesday, January 24, 2017 at 3:21:31 PM UTC-7, Robert Lee wrote:
>
> Would anyone else find --Html.Attributes.none-- useful?
>
> none : Html.Attribute a
>
> Use cases look like the following. 
>
> 
>
> view: Model -> Html.Html Msg
>   let 
> onClickButton = 
>   case model.isClickedAlready of
> True -> 
>   Html.Events.onClick Submit
>
>  False ->  
>Html.Attributes.none
>   in 
> Div [onClickButton] 
>
> .
>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:
>
> The reason is that BuckleScript proves that Arrays are faster than 
> "string" tagged objects and I have tried benchmarking it myself.  In fact, 
> I have gone further and manually substituted the use of Arrays rather than 
> the string tagged objects in the generated Elm code to show that is the 
> reason.  The problem isn't so much the use of Array's versus 
> objects/records, but the string tags, which as the Elm JS output doesn't 
> preserve type information except by these tags, are continuously requiring 
> string processing to determine the type of object at run time.  Elimination 
> of these strings by using the type information the compiler already has 
> would greatly speed things even if objects are used, with the further 
> advantage of Arrays being that their indices are numeric for slightly less 
> processing (depending on the browser engine used).
>

That should not actually be a big difference.  String comparisons in 
javascript on V8 (and I think Firefox's and Edge's) javascript engine(s) 
using `===` are pointer comparisons, and as strings are interned that makes 
it very fast, a pointer comparison in the general post-JIT case, which 
should be equal to integer comparisons.  What is different is using an 
array instead of an object, most JIT's will allocate it a tiny bit faster, 
but again in the general case there is not much difference.


On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:

> Yes, Elm is fast enough for many purposes.  Tree shaking programs such as 
> the Google Compiler reduce code size.  Compile time is currently adequate 
> for many uses, although slow compared to something like OCaml/BuckScript 
> that has been expressly optimized for compile speed.
>

Actually tree shaking will do absolutely nothing for Elm code as Elm 
compiles everything into a single module that all highly indirectly 
references itself.  It would help with bucklescript as it outputs modules, 
but bucklescript already tree-shakes as part of its compiler optimizations 
anyway.


On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:

> I am not really promoting the use of OCaml/BuckleScript which has its own 
> warts (currently) although Hongbo has done an incredible job with it:  I 
> dislike Ocaml except as it closely resembles Elm/Haskell/F#.  My point is 
> that for those of us that need speed - at least a few that have chimed in 
> on this thread - if it isn't addressed with the Elm compiler then Elm might 
> migrate to a front end to OCaml which would schism development efforts and 
> possibly hurt the language.
>

Well, as a language I like a lot of things in OCaml, doing a 'plugin' 
system, as was in my old project, in it is trivial and simple by using 
things like polymorphic variants, where-as doing the same in Elm was... 
highly painful and excessive in code.  ^.^

Overall Elm's simplicity is nice, and for example I'd never want OCaml's 
object system in it, although having OCaml's module system (with built-in 
implicit module support) would be fantastic for abstracting things better 
(and it compiles significantly faster than typeclasses or HKT's).  :-)


On Monday, January 23, 2017 at 6:41:55 PM UTC-7, GordonBGood wrote:
>
> On Tuesday, 24 January 2017 01:26:49 UTC+7, OvermindDL1 wrote:
>>
>> Bucklescript de-curries as much as possible, however you can also force 
>> it in the type system explicitly by adding the annotation type of `[@bs]` 
>> to a function (type) definition, that enforces uncurrying at the type level 
>> and will even propagate in usage as expected to make sure accidental 
>> currying of it is not done (though you can still explicitly curry it by 
>> wrapping it in a curried type).  In most cases it de-curries very well and 
>> you never need to use `[@bs]` (the only real time I've used it is on DOM 
>> callback registrations with more than one argument to make sure I do not 
>> accidentally pass a curried version to one, never used it in 'user' code as 
>> of yet).
>>
>
> Yes, I've used the {@bs} notation, usually on very low-level code to force 
> no currying (or passing of any arguments); as you say BuckleScript is very 
> good of determining an appropriate use of currying.  If one were to use an 
> Elm front end to OCaml/BuckleScript, it would be nice to add the ability to 
> inject these macro-type annotations into the code, probably as a specially 
> formed comment, so that in effect we could write all the Native code 
> modules in the high level environment, which works very well in 
> BuckleScript.
>

It would not be hard, however I'd think it would also be entirely 

[elm-discuss] Re: Techniques for text input in elm-lang/svg

[OvermindDL1]

Might be easier to let them click on an element and you pop out an 
'attributes' pane of it or something, that way they can edit the caption in 
there or potentially other editable attributes that you may add over time 
too?


On Monday, January 23, 2017 at 2:55:01 PM UTC-7, Eelco Hoekema wrote:
>
> Hi,
>
> I am trying to create an interactive diagram in Svg, in which it should be 
> possible to edit captions of diagram elements. It's the first time i use 
> Svg, so everything is new to me. 
>
> I need this dialog in which two diagram text attributes can be edited. As 
> far as i can tell i will need to send the keyboard events to the right 
> input field, or rather, filter the events out if an input field is not 
> active. It is somewhat basic. 
>
> Does anyone know of examples, patterns and best practices for handling 
> text input when using Elm with Svg?
>
> thanks,
>
> eelco 
>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote:
>
> I think everyone hangs around this and other Elm discussion forums because 
> we love the Elm concept of a simple functional language that promises to 
> eliminate the need to deal with JavaScript; but unfortunately, due to the 
> compiler shortcomings, that promise is not delivered other than for the 
> most basic of programs.  I'm glad to see that Evan resists adding 
> everyone's favourite feature to the language and actually continues to 
> reduce syntax to a bare core of functionality.
>

Entirely yeah, TEA is a fantastic architecture .


On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote:

> Ideally, the Elm compiler would get completely re-written to both deal 
> with the compilation speed issues (hopefully this work on "asset 
> management" will handle that), but also to use the available static type 
> information in the back end to generate much more efficient JS code as does 
> BuckleScript (in most cases).  This will be even a larger project as in 
> order to get real JS code speed improvements for some cases, the memory 
> model will have to be completely changed to something (or exactly) that of 
> the BuckleScript back end.  Come now, test tagged JS records as the primary 
> data structure?  So (as Even said) this is a big project as changes will 
> have to be made to pass the type information to the code generator back end 
> ***and*** completely re-write the back end to use that type information and 
> while we are at it may as well change the JS code memory model to use JS 
> Array's (no text tags) as the primary data structure as does BuckleScript. 
>  This may make the resulting JS code less debuggable, but that that isn't 
> why we want to use Elm - we hope that all debugging can be done within the 
> Elm environment.
>

One of Elm's big things is 'never needing to debug the javascript' though, 
so I could see it doing that.


On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote: 

> Unfortunately and realistically, there seems to be only one major 
> contributor to the Elm compiler and build system - Even himself - and he is 
> under increasing pressure to do more timely updates in a variety of areas, 
> not only as to code efficiency.  Also, the plan as proposed above requires 
> changes in at least two major parts of the compiler:  the AST code builder 
> and the back end Code Generator, so either one person needs to do both or 
> there will be co-ordination involved.  This work would precede any other 
> necessary work on further compiler optimization passes a la BuckleScript.
>

That is why I think having Elm compile to another target would save Evan a 
tremendous amount of work.  A translation layer is quite a lot easier than 
a full compiler (especially the more similar the semantics already are, 
like Elm and OCaml very much are).  He'd be free to design the language 
much more easily.  OCaml already has fantastic error reports, although not 
'quite' up to Elm's standards (but pretty close in many ways), and adding 
better error messages to the OCaml compiler would benefit a lot more people 
outside of Elm as well (plus the OCaml compiler is oddly fun to hack on, it 
is really well designed).


On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote:

> As you say, the easiest thing to do would be just write an Elm2OCaml stand 
> alone program which could then easily become the "pp" front end to produce 
> an alternative Elm compiler to so much more efficient JS code through 
> BuckleScript, with even more BuckleScript optimizations promised in the 
> near future (or a native code alternative back end).  Again as you say, it 
> is very easy to write minimal JS interfaces in OCaml so that there then 
> almost needs no Native code modules at all.
>

Bucklescript can already compile to OCaml.  Bucklescript adds some 
extensions (the OCaml language is extendable via ppx's as well) to do 
things like platform testing, so you can make code that compiles for the 
web do something else when on native (like output html or no-op for event 
registrations), and that ppx can be added to a normal OCaml compiler via 
the normal `-ppx` flag to add those extensions to a native compile as well, 
so you get free platform detection to write platform-specific code.


On Monday, January 23, 2017 at 10:52:12 AM UTC-7, GordonBGood wrote:

> Unfortunately, if we do that in as short a time as you say is possible, 
> work on the Elm compiler will likely never catch up to that effort, and 
> Elm, the language, will become nothing but a language specification for an 
> alternate front end to OCaml just as ReasonML is.  In a way, I'd be sorry 
> to see that happen as Elm could be an independent language force in its own 
> right.  Once Elm's core Native libraries have been re-written into the 
> OCaml environment, the ease of use of the resulting combination will likely 
> mean that most seri

[elm-discuss] Re: Elm doesn't seem to do do TCO in my case. Bug?

[OvermindDL1]

On Friday, January 20, 2017 at 11:17:32 AM UTC-7, mrbackend (Roy Brokvam) 
wrote:
>
> Consider:
> type Nat
> = Zero
> | Succ Nat
>
>
> nat : Int -> Nat
> nat n =
> nat_ n Zero
>
>
> nat_ : Int -> Nat -> Nat
> nat_ n curr =
> if n <= 0 then
> curr
> else
> nat_ (n - 1) (Succ curr)
>
> Using tail recursion, this should be stack safe in Elm (as far as I 
> understand). But I get a stack overflow for large values of n (>= 5000). Is 
> my function really tail recursive, or might there be a bug in Elm?
>
 
It compiles into this:
```elm
var _user$project$Temp1484937158714761$Succ = function (a) {
return {ctor: 'Succ', _0: a};
};
var _user$project$Temp1484937158714761$nat_ = F2(
function (n, curr) {
nat_:
while (true) {
if (_elm_lang$core$Native_Utils.cmp(n, 0) < 1) {
return curr;
} else {
var _v0 = n - 1,
_v1 = _user$project$Temp1484937158714761$Succ(curr);
n = _v0;
curr = _v1;
continue nat_;
}
}
});
var _user$project$Temp1484937158714761$Zero = {ctor: 'Zero'};
var _user$project$Temp1484937158714761$nat = function (n) {
return A2(_user$project$Temp1484937158714761$nat_, n, 
_user$project$Temp1484937158714761$Zero);
};
```
So it does look TCO'd, what is the exact stack trace that you got?

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Wednesday, January 18, 2017 at 9:53:31 AM UTC-7, Rupert Smith wrote:
>
> In my view, this also provides very good justification for not allowing 
> native code into packages.elm-lang.org. Porting Elm to another platform 
> in this way is manageable.
>

Entirely yeah, native code even in core elm is buggy.  In my translations I 
wrote very thin FFI calls to the base-most javascript calls (mostly DOM 
stuff), fully typed, then built everything on those typed interfaces (it is 
very typescript'y/purescript'y at that point), but I've had no undefined's, 
no oddities like that at all, and the old 'native' parts were entirely in 
OCaml this time, just bound to those very few fully typed FFI calls (which 
I need to clean them up too, newer versions of bucklescript has simplified 
making them since I wrote this file).  For example, here is the web element 
node interaction FFI l made (slightly older version as the one at work has 
a bit more and is a bit more clean), these are the kind of things user code 
should not write, and indeed an Elm->OCaml compiler should not have such 
functionality exposed but rather should call to things exposed from OCaml 
that may use things like this: 
 
https://github.com/OvermindDL1/bucklescript-testing/blob/master/src/web_node.ml 
(and ignore the polyfill at the bottom, I later converted that to pure 
OCaml/Bucklescript as well)

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Saturday, January 14, 2017 at 3:13:40 PM UTC-7, GordonBGood wrote:
>
> I saw that over on elm-dev, but haven't tried it because compilation speed 
> isn't a problem for the Elm code I have written so far.  The only reason I 
> brought it up is OvermindDL1's comment 
> <https://groups.google.com/d/msg/elm-discuss/Um7WIBTq9xU/JpNNGv1JAgAJ> that 
> compiling a Ocaml/BucketScript code (that presumably did the same thing as 
> the Elm code) took about 0.1 seconds as compared to 40 seconds with the Elm 
> compiler - a 400 times speed-up!  We weren't given details of the code or 
> test conditions and whether one was an incremental compilation, but that 
> sounds quite serious and would affect the usability of Elm.  If that data 
> is verifiable, a speed up of double or even quadruple doesn't begin to 
> touch the difference and should be investigated.
>

It was a rewrite of a messaging system at work, it was in elm but we had 
issues that necessitated the use of too many ports, the new one written in 
OCaml (transpiled to javascript by Bucklescript) does the same thing in 
about the same lines of code, except no javascript was used at all.  The 
lines of code is hovering around 6k for both versions, a compile for both 
is done just by calling elm-make or bsb respectively and those are the 
output times for a clean compile (no cache for either) with both spread 
across about 31 source files.  I'm not sure why the elm compilation is so 
slow, the compilation is happening on Windows so that could be a factor. 
 And sadly no, cannot release work code without consent.  ;-)

A note though, the elm code was severely hampered by the type system in Elm 
(lack of HKT's or HPT's) so had to get creative with use of records and 
unions, so it is entirely possible we hit a very slow case, in the OCaml 
code we used some GADT's and polymorphic modules so as to not resort to 
those hacks.


On Saturday, January 14, 2017 at 9:14:55 PM UTC-7, Richard Feldman wrote:
>
> If only there were a binary posted somewhere, based on a compiler that had 
> just been rewritten to improve build times, so that someone could post a 
> benchmark instead of speculation! ;)


I might be able to test out the new compiler, still have the old elm code 
in the repo (just that chunk is unused, we are still using other parts of 
Elm that are not as large and not as full-of-ports) if really curious? 


On Sunday, January 15, 2017 at 8:21:28 PM UTC-7, Richard Feldman wrote:
>
> you need recompile that module and regenerate a monolithic js file, the 
>> larger project it gets , the worse compilation time you get in elm mode. If 
>> you have experience in C++, you know the bottle neck used to be linking, it 
>> is quite common for a c++ project to spend 20minutes in linking.
>
>
> Considering Evan is working on asset management for the next release, I 
> doubt "compile everything to one file" will be true after it lands. (That 
> release is presumably still several months away; this is just speculation 
> on my part.)
>

Ooo, now that would be awesome.  :-)


On Tuesday, January 17, 2017 at 4:25:08 AM UTC-7, Rupert Smith wrote:
>
> Yes, that is what I thought. I probably missed some context out when 
> quoting, but my question was in response to OvermindDL1's suggestion that 
> moving to OCaml would open up the possibility of compiling to different 
> back-ends other than javascript.
>
> An alternative might be to re-write the Native modules in the Elm core in 
> OCaml. There isn't a huge amount of it.
>

Precisely this, I've already done quite a large chunk of it as a test and 
it translates very easily (and becomes type safe, which Elm's is not as 
I've hit 'undefined's in pure elm code before (already in the bug tracker, 
but why did they happen at all?!)).  I kept it identical to the Elm API as 
well, though if I broke Elm's API in a couple of minor ways then I could 
*substantially* reduce the number of allocations done...  But yes, I've 
rewrote most of Elm's native Core code as well as some third-party 
libraries like navigation, all without a touch of javascript and all of it 
type safe the whole way, mostly playing around but we ended up using a lot 
of it at work anyway (I still need to get around to cleaning it up and 
releasing it...).  An Elm->OCaml transpiler is entirely possible and I've 
no doubt it would take substantially less than a year to do (if I could get 
my work to pay for it I'd guess probably two weeks at most, though if 
everything goes well I'd guess two days for the language conversion and the 
rest on filling out the rest of the API that I've not yet done so as to 
remove all javascript, which would make it compileable to native code as 
well once system checks w

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Friday, January 13, 2017 at 10:10:28 AM UTC-7, Joey Eremondi wrote:
>
> Even a direct Elm to OCaml translation wouldn't be too hard. Elm is not 
> the same as OCaml, but my understanding is that most of its features are 
> included in Elm (row polymorphism, strict evaluation, 
> first-class-functions). OCaml has lots of features Elm doesn't want (like 
> mutable references) but that's not a problem, and could even allow for some 
> nice backend optimizations.
>
> This would also provide a really nice way to do Elm on the backend. The 
> big question is, how to write such a translator? Are the Haskell libraries 
> for generating OCaml? Or would the compiler need to be written in OCaml?
>

No clue about Haskell libraries, but at the very least you could just do a 
textual translation from Haskell.  However by using the OCaml compiler 
libraries you'd save time and it would save a lot of code regardless.

And yep, OCaml has everything that Elm uses and a lot more that could be 
used for some optimizations, but to start a direct translation would be 
easy.

Even the direct OCaml code is 'almost' identical to Elm.  You know the 
normal ELM Form example at http://elm-lang.org/examples/form?  Here is the 
same thing in OCaml:
https://github.com/OvermindDL1/bucklescript-testing/blob/master/src/main_form.ml
'Almost' identical, and some of the non-identical parts are just minor API 
changes in this example.

But yes, translating Elm to OCaml/Bucklescript would not at all be a hard 
task.  :-)

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Friday, January 13, 2017 at 8:40:07 AM UTC-7, Rupert Smith wrote:
>
> All that this would take would be to write an Elm parser into the first 
> stage of the OCaml pipeline? You'd also need to compile the Native modules, 
> is there already some way to feed them into the Ocaml pipeline?
>

There are 2 first stages depending on how you look at it.

The real first-first stage is not so much as a compiler plugin as it is 
just a generic pre-processor, things like Caml4p(sp?) are this, in a high 
level over-view:
```sh
ocamlc -pp myPP ...
```
Although using a normal build system (bucklescript 'bsb' is fantastic!), 
but think of `myPP` just as a normal binary, you pass in file contents 
(source code) via STDIN and it passes back out changed text via STDOUT.  It 
is basically the same as preprocessing each file to another directory then 
compiling 'those' with ocamlc (except faster since ocamlc gets information 
from it and keeps it loaded.

A 'ppx' is an actual compiler plugin, passed the same way:
```sh
ocamlc -ppx myPPX
```
It is also basically a binary that operates in the same way as above, 
except it operates on the OCaml AST at various stages in the pipeline 
(whatever hooks you register, you can have multiple), it translates the AST 
and returns the altered AST so the compiler continues on.

Bucklescript plugs late in the compiler to take the AST and output it to 
javascript for example.  Reason is a preprocessor only as it uses non-ocaml 
syntax (it outputs OCaml syntax).  Elm on OCaml would just be a 
preprocessor as well (potentially with some ppx's as well if you want to 
add some compilation pass stuff), all of which would be handled by the 
build system of course.  Basically bucklescript as an example has a few 
files like 'bsc' and 'bsdep' and 'bsppx' and such, the bsppx is the actual 
ppx that handles some pass transformation, bsc is the actual compiler 
(which just wraps the ocaml compiler while adding bucklescript 
transformers), etc...  The file 'bsb' is the build system (built using the 
fast Ninja build system) that handles the json file that defines a 
bucklescript project to automatically handle everything as a build system 
should (its version of elm-make you can think of it as).

Elm could comparatively easily become a preprocessor with its own wrappers 
to handle its building, the interaction with elm would remain the same, it 
would just become significantly faster in compilation and execution speed 
while opening it up to native compilation as well (or if you use node just 
compile out via bucklescript to node as normal there as well).  This way 
elm remains the tight, highly focused language specific for this purpose, 
but you could even make normal OCaml code that calls into Elm or vice-versa 
(an elm layer could enforce that any function that elm code calls out to is 
'pure' for example, or not, whatever).

-- 
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: Emphasizing /r/elm more

[OvermindDL1]

I'd still not recommend reddit, it has no mailing list support.  Here or 
Discourse both act well as a forum (though discourse more so) and as a 
mailing list both, so either works.


On Friday, January 13, 2017 at 12:34:47 AM UTC-7, Håkon Rossebø wrote:
>
> I would also prefer a solution like Discourse or similar as this seems to 
> work very good for elixirforum.com. Anyway, if the focus should be moved 
> to /r/elm, I would suggest we change the elm-discuss group heading to 
> include a link to /r/elm with some description.
>
>
> fredag 6. januar 2017 00.18.28 UTC+1 skrev Joey Eremondi følgende:
>>
>> My main hesitation about reddit is that, even on the best-case subs like 
>> /r/rust, newcomer posts tends to get downvoted or ignored.
>>
>> Here, if a newcomer posts a basic question, many people will ignore them, 
>> but the poster doesn't know that. Someone will post a solution, or a link 
>> to one, and they will be on their way. On /r/elm, they see their post 
>> sitting at 1,0 or -1 votes, and and up feeling like newcomer questions 
>> aren't welcome, and are more likely to try to find a tool with a more 
>> friendly community.
>>
>> My vote would be for Discourse or something similar. I think being able 
>> to sticky posts would remove a lot of the redundant messages we see on this 
>> list, and being able to sort by subject would make it easier for people to 
>> see what they're most interested in.
>>
>>
>>
>> On Thu, Jan 5, 2017 at 3:14 PM, 'Rupert Smith' via Elm Discuss <
>> elm-d...@googlegroups.com> wrote:
>>
>>> On Wednesday, January 4, 2017 at 7:00:34 PM UTC, Martin DeMello wrote:

 I'm a heavy reddit user, and I think it simply lacks the features 
 necessary to support mailing-list-style discussions:

>>>
>>> You can't quote when replying.
>>>
>>> I like newsgroups so much better then /r/elm. I like the old fashioned 
>>> feel of them, the anarchic style, the freedom to be conversational or 
>>> express myself however I like within the confines of ASCII. There is still 
>>> something of the old attitude of usenet alive in them that just seems to be 
>>> lacking on the alternatives. I take great pride in quoting carefully, 
>>> replying to multiple questions with responses in-line underneath, not top 
>>> posting and so on. In other words newsgroups or mailing lists take bit of 
>>> work and manners to operate successfully and that all contributes to making 
>>> a community.
>>>
>>> A few thoughts for you:
>>>
>>> Having a split community might actually be a good thing. For one, there 
>>> are enough people interested that >1 splinter of this community is alive 
>>> concurrently. That in itself is an achievement because something needs to 
>>> reach a certain size for that to happen. Also it makes the community as a 
>>> whole more resilient - if one splinter dies out, others may carry on.
>>>
>>> Removing duplication is a good thing for code - but for community growth 
>>> and engagement, perhaps it isn't.
>>>
>>> So I'm just going to keep on posting here, because it is the best place 
>>> for me and I've had plenty interesting and helpful responses.
>>>
>>> Also, what about this:
>>>
>>> http://elm-news.com/
>>>
>>> Perfect for keeping up-to-date with multiple channels. All it needs is 
>>> user accounts or to use local storage so it can keep track of what you have 
>>> read or not.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

That is actually why I think Elm should compile to a a different back-end, 
like ocaml/bucklescript or so.  The syntax is uniform enough that making an 
elm->ocaml/bucklescript transpiler would be just a matter of re-using most 
of the existing parser in OCaml, which is already beyond blazing fast in 
comparison.  It would significantly reduce elm's compiling time, it would 
get it to a back-end that has far far more optimizing passes than elm 
itself does while being substantially better tested, and it would give a 
method of being able to compile elm to bare-metal for very fast server-side 
page generation.  I'm actually using my elm'y library that I built on 
bucklescript in my work project (recompilations taking ~100ms compared to 
the elm project taking over 40s for the same code was the big reason why, 
reduced turn-around time substantially), but it would be much nicer just to 
use elm itself built on such a better compiler instead.

And for note, OCaml's compiler is pluggable, you can plug in to many steps 
during compilation, bucklescript just plugs in to part of that pipeline, 
reason plugs into a higher part.  The highest part is called a 'pp' 
(pre-processor, bucklescript is a 'ppx' for comparison, reason is a 'pp'), 
and elm could easily be such an OCaml pre-processor, taking the elm code 
and massaging it to OCaml's, the whole infrastructure is built for such 
things, and that combined with elm's versioning (the ocaml compiler can 
even output interface definitions for files to make calculating this to be 
trivial) and packaging system would absolutely blow everything else away, 
especially if you could fall back to OCaml code for things that are 
difficult or impossible to do on the Elm side.  ^.^


On Thursday, January 12, 2017 at 9:25:34 PM UTC-7, GordonBGood wrote:
>
> On Thursday, 12 January 2017 22:42:05 UTC+7, OvermindDL1 wrote:
>>
>> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote:
>>>
>>> On your advice, I've reread the ReasonML documents as I got mislead by 
>>> looking at ReasonML/Rebel and that is at too early a stage for me to 
>>> consider (also support for BuckleScript is currently broken).  I liked the 
>>> ReasonML syntax much better than OCaml as it is more consistent, although 
>>> it still has curly brackets and semicolons instead of white space delimited 
>>> block, I can live with that as long as I have before as long as it is 
>>> consistent.  Unfortunately, I can't get the ReasonProject to install on my 
>>> machine (Windows 10 64-bit) and I am not likely to pursue it at this time 
>>> as it isn't *that* important to me.
>>>
>>
>> I'm actually not a fan of the Reason syntax myself, I consider it 
>> horribly verbose and noisy, but then again I've been comfortable with 
>> OCaml/SML syntax for over a decade now.  However correct, Reason has no 
>> Windows support 'yet' (it is on their roadmap), however bucklescript works 
>> perfectly with its HEAD right now elsewhere (most of the windows issues 
>> are, oddly enough, because of npm stupidity actually).  Bucklescript itself 
>> supports windows absolutely perfectly though (I was noisy about it at first 
>> when it was not  ^.^).
>>
>
> Thanks for the input on ReasonML - that explains why I wasn't able to 
> install it on Windows, and if it is so "noisy" then I probably don't really 
> want it anyway.  Unlike you, I don't have 10 years with OCaml, although I 
> do have many years with F# pretty much since its beginning which I likely 
> why I find Ocaml a bit archaic as F# modernized it.  Anyway, 
> Ocaml/BuckleScript is usable to me, and as Hongbo says, will get better.
>  
>
>> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: 
>>
>>> BTW, I see one of the reasons that BuckleScript produces JavaScript that 
>>> is so much faster than that produced by Elm:  you use JavaScript Array's as 
>>> the base for almost all of the data structures whereas Elm uses tagged 
>>> objects, which are very slow (at least on Google Chrome V9/nodejs); it 
>>> almost seems like the Elm compiler just outputs dynamically typed code with 
>>> the "all data is just one type - an object with tags" model, although it 
>>> does recognize that numbers, characters, and strings will be picked up by 
>>> JavaScript and don't need to be wrapped in a tagged wrapper object.
>>>
>>
>> That is one reason, but not the only one.  A bigger reason is that 
>> bucklescript 'types' the javascript code, such as by putting `| 0` on 
>> integer o

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote:
>
> On your advice, I've reread the ReasonML documents as I got mislead by 
> looking at ReasonML/Rebel and that is at too early a stage for me to 
> consider (also support for BuckleScript is currently broken).  I liked the 
> ReasonML syntax much better than OCaml as it is more consistent, although 
> it still has curly brackets and semicolons instead of white space delimited 
> block, I can live with that as long as I have before as long as it is 
> consistent.  Unfortunately, I can't get the ReasonProject to install on my 
> machine (Windows 10 64-bit) and I am not likely to pursue it at this time 
> as it isn't *that* important to me.
>

I'm actually not a fan of the Reason syntax myself, I consider it horribly 
verbose and noisy, but then again I've been comfortable with OCaml/SML 
syntax for over a decade now.  However correct, Reason has no Windows 
support 'yet' (it is on their roadmap), however bucklescript works 
perfectly with its HEAD right now elsewhere (most of the windows issues 
are, oddly enough, because of npm stupidity actually).  Bucklescript itself 
supports windows absolutely perfectly though (I was noisy about it at first 
when it was not  ^.^).

However, I can see how you'd like the Reason syntax better, but do not 
discount the OCaml syntax.  The nice thing about the OCaml raw syntax is it 
is not only blazing fast for the compiler to parse, but also for a human to 
parse as well, you know what things will be once you learn it, and it is 
very simple.

 
On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote:

> I understand that if I were able to install it, by "working seamlessly 
> with BuckleScript", you mean that the "bsb" command will just take the 
> output of the previous ReasonML build as its input to produce JavaScript?
>

Actually Reason's build system can choose bucklescript as its output 
directly, it has first-class support.  However you could indeed translate 
reason -> ocaml -> bucklescript pretty easy anyway. 


On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: 

> BTW, I see one of the reasons that BuckleScript produces JavaScript that 
> is so much faster than that produced by Elm:  you use JavaScript Array's as 
> the base for almost all of the data structures whereas Elm uses tagged 
> objects, which are very slow (at least on Google Chrome V9/nodejs); it 
> almost seems like the Elm compiler just outputs dynamically typed code with 
> the "all data is just one type - an object with tags" model, although it 
> does recognize that numbers, characters, and strings will be picked up by 
> JavaScript and don't need to be wrapped in a tagged wrapper object.
>

That is one person, but not the only one.  A bigger reason is that 
bucklescript 'types' the javascript code, such as by putting `| 0` on 
integer operations and such, which allow most javascript VM's (V8 and 
especially Firefox's) to pre-JIT them significantly more efficiently. 
 However it has more 'typing' that it can do, which I expect over time. 
 However yes the array's are more efficient, and it matches what OCaml 
itself does (array's of bytes to store data).
 
 
On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote:

> Its too bad you can't apply your compiler optimizations to Elm.  Perhaps 
> they could be, as Elm does produce an AST and is a very simple language so 
> presumably the AST is fairly simple too.
>

Bucklescript does not do the optimizations itself (well it does some 
javascript-specific one like higher arity functions and so forth), most of 
it is OCaml.  *However*, you could write an Elm compiler that compiles to 
OCaml (which then could be compiled to native or to 
javascript-via-bucklescript), but the syntax's are so close as it is that 
it would be easier to just write an elm-like library for OCaml instead.
 

On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote:

> As an aside, have you ever looked at using an asm.js back end as current 
> mainline browsers mostly support it, and if so did it make any different to 
> speed?
>

Actually that is what the typing stuff I mentioned above is, it is the 
asm.js decorations (though not full asm.js, things like '|0' is pretty 
universally supported, plus it is all backwards compatible).  I could 
imagine OCaml compiling directly to webassembly later anyway, but for 
working with javascript being able to see the (very readable) output 
javascript via bucklescript is unmatched in usefulness.

-- 
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] Cannot find module "String"...

[OvermindDL1]

On Tuesday, January 10, 2017 at 11:10:31 AM UTC-7, Rex van der Spuy wrote:
>
> On Tuesday, January 10, 2017 at 9:35:16 AM UTC-5, Peter Damoc wrote:
>>
>> Have you tried deleting ~/.elm ?
>>
>  
> Thanks Peter, I've just done this based on your suggestion but the effect 
> is the same.
> Maybe I should re-install Elm? 
>

Yes, you really should at this point, and make sure to purge all old elm 
data as well. 

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

[elm-discuss] Re: Task.perform in 0.18?

[OvermindDL1]

Ahh, see that there, the return type of `Scroll.toTop` is `Task.Task 
Dom.Error ()`, this in this case also change `Task.perform` to 
`Task.attempt`.  :-)


On Friday, January 6, 2017 at 1:59:06 PM UTC-7, Rex van der Spuy wrote:
>
> Thanks Overmind!
>
> I've done as you suggested and removed one `(always NoOp)` - that's makes 
> sense to me! 
> The compiler now gives me this error message:
>
> ``
>
> The 2nd argument to function `perform` is causing a mismatch. 215| 
> Task.perform 
> (always NoOp) (Scroll.toTop "questionsContainer") 
> ^ Function `perform` is expecting the 2nd 
> argument to be: Task.Task Never b But it is: Task.Task Dom.Error ()
> ...
>
> `Scroll.toTop` comes from `elm-dom`:
>
> http://package.elm-lang.org/packages/debois/elm-dom/1.2.3/DOM
>
> ... but I now just realized that the API has changed in 0.18.
>
> Hmmm I need to think about this one! :)
>
>

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

[elm-discuss] Re: Task.perform in 0.18?

[OvermindDL1]

Task.perform now takes a task that cannot fail (hence the 'Never' in its 
type).  So I have no clue what your Scroll.toTop call returns as a type, 
but if it cannot fail (Never on the error condition type) then just remove 
one of your `(always NoOp)` calls, else change `Task.perform` call into 
`Task.attempt` while also removing one of the `(always NoOp)` calls as it 
gives you a Result instead.

Docs:
http://package.elm-lang.org/packages/elm-lang/core/latest/Task#perform
http://package.elm-lang.org/packages/elm-lang/core/latest/Task#attempt


On Friday, January 6, 2017 at 1:40:40 PM UTC-7, Rex van der Spuy wrote:
>
> Hi Everyone,
>
> In upgrading an 0.17 app I ran across this line of code:
>
> ```
> Task.perform (always NoOp) (always NoOp) (Scroll.toTop 
> "questionsContainer") 
> ```
>
> I understand that `Task.perform` was re-designed with this signature:
>
> ```
> perform : (a -> msg) -> Task Never a -> Cmd msg
> ```
>
> But, I haven't been able to figure out how to apply this to my old line of 
> code.
> Can anyone suggest what I should try?
>
> Thanks!
>

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

[elm-discuss] Re: Same code generated by BuckleScriptRe: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Saturday, December 31, 2016 at 8:09:28 PM UTC-7, GordonBGood wrote:

> I see that BuckleScript would work fine for JavaScript output and OCaml 
> can be fast, but wouldn't int64 with two int's be a bit slow?  It's just 
> that i prefer Haskell syntax and capabilities more than OCaml as it just 
> feels like a more modern language.  I do like F# (and thus probabably 
> Fable), but it isn't as pure a language as Haskell.  I think I'll see what 
> GHCJS can do for me, once I can get it installed.
>

Unless you know any other way of representing int64 on javascript?  An 
array of two integers is about the best you can do.  Using a native 
javascript integer you get 32-bit.  Using a native javascript number you 
get a 64-bit float (53-bits if I recall correctly of usable integer).

Also, OCaml and Haskell are about the same age, although OCaml is based on 
the older SML, but as for the 'feel' of it there are two things to note:

1.  OCaml's language is designed for fast parsing, like the code that Bob 
Zhang gave above compiles on 0.015 seconds on my machine here.  Even very 
complex programs compile in seconds at most, compared to my 'usual' Haskell 
programs taking multiple minutes (or potentially hours on more complex 
programs that use a lot of HKT's).  But near every decision of OCaml's 
syntax was designed to make for a *very* fast compiler (and elm was modeled 
as a mix of OCaml and Haskell syntax, see 
https://github.com/OvermindDL1/bucklescript-testing/blob/master/src/main_counter.ml
 as 
a working Elm example in OCaml).
2.  There is a PPX (preprocessor 'essentially', but of the AST) called 
ReasonML that is OCaml with a fluffed up, more javascript'y (ew) syntax 
that many like if you want something more modern feeling, but it is still 
just OCaml.


/me uses OCaml as their main static functional language on personal time


What I am most curious in is being able to make self-contained custom 
elements in some functional language to javascript with ease.  'Almost' 
there with elm with that (can make elm into a custom-element, but cannot 
use a custom-element from within elm very well yet).  Elm's subscriptions 
and registration approach would make making custom-elements (webcomponents) 
such a breeze once fixed up!  ^.^

-- 
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: Stance on native APIs for 0.18?

[OvermindDL1]

`opaque type DBConnection` perhaps would be the common way to write such a 
type that can only be passed in and passed out but not created.


On Thursday, December 8, 2016 at 11:28:22 AM UTC-7, Mark Hamburg wrote:
>
> I was talking about this further with my coworkers and we more or less 
> agreed that the key things that could help with Elm's interface to 
> JavaScript were:
>
> * Task ports. Tasks are a building block in a way that commands are not. 
> Forcing all external interactions to be asynchronous makes it more clear 
> that one is stepping outside and code could fail.
>
> * A "foreign" value type that could capture a reference coming from 
> JavaScript to be handed back in other calls. For example, though not a 
> great JavaScript example, this could be a database connection. All 
> operations on the database would occur via tasks. We just need an easy way 
> for Elm to hold the handle to the database connection. This functionality 
> would be better if the foreign types could be distinguished within Elm in 
> their declaration — e.g.
>
> port type DBConnection
>
> ("port" reads wrong but I was avoiding introducing a new keyword.)
>
> That said, one could also just use Foreign as a base type and use Elm code 
> wrap it in more meaning for the type checker:
>
> type DBConnection = DBConnection Foreign
>
> This, however, probably makes it harder to use the types safely in the 
> task APIs.
>
> Would those two features address everything needed? No. In particular, 
> port wireup inhibits creating libraries. But it would make it much more 
> straightforward for any individual project to build interfaces to 
> JavaScript-based functionality.
>
> Mark
>
> On Thu, Dec 8, 2016 at 9:27 AM Vojtěch Král  > wrote:
>
>>
>> Dne úterý 6. prosince 2016 23:14:06 UTC+1 Rupert Smith napsal(a):
>>
>>> The thing about ports for something like this is it feels a bit 
>>> unnatural to invoke the port resulting in a Cmd. Then you'll need a 
>>> subscription port to get the result back in, and have that pass it to your 
>>> update function from where you can take it and place it in the model. That 
>>> doesn't feel like a good way to call a function : String -> Ast.
>>>
>>> I'd say the best solution is to implemented your parser in pure Elm. But 
>>> if that is too much work, just hack together a native module that calls out 
>>> to commonmark.js. You won't be able to publish your native module to elm 
>>> packages, but that's ok, perhaps no-one else really wants your markdown 
>>> with embedded SQL anyway, and if they do there is always 
>>> elm-github-install. Some time down the road when you really need to share 
>>> this amazing library, redo it in pure Elm. 
>>>
>>
>> This resonates with me very much. This is _exactly_ the reason why I made 
>> The Elm Alienation post on Reddit: 
>> https://www.reddit.com/r/elm/comments/5g3540/the_elm_alienation/
>>
>> I also wanted to ask here about the status of the Native API but I'm 
>> seeing you guys already inquired.
>>
>> Forcing people to rewrite everything in Elm is a terrible idea.
>>
>>
>> Dne středa 7. prosince 2016 17:18:37 UTC+1 Mark Hamburg napsal(a):
>>
>>> Would
>>>
>>> it help if there were a standard mechanism to invoke JavaScript code as
>>>
>>> a task (or equivalently to make JavaScript code available as a task)?
>>>
>>
>> Yes! Very much! If this happened, I'd definitely revisit the decision to 
>> leave Elm.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>>
>>
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@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: Race condition in textareas?

[OvermindDL1]

Elm does not use Shady DOM nor Shadow DOM, so that would be unrelated 
unless you are using the Shady or Shadow DOM's outside of elm but within 
the elm application.

For note, updating the defaultValue will only update the textarea if the 
textarea is destroyed and recreated, updating the value will update it in 
real time but that means that you can also desync from a user typing if 
incoming messages overwrite each other if the user types too fast.  I 
tended to only set the 'value' when I wanted to force overwrite and just 
did not set it at all for the rest of the messages to work around it.


On Wednesday, December 7, 2016 at 2:50:59 AM UTC-7, John Watson wrote:
>
> My code seems to fail in Firefox immediately a slider is operated by the 
> user.  After reading this discussion 
>  on shady 
> dom, I'm wondering whether the issue is that Firefox has no 
> implementation of shadow dom 
> whilst both Chrome and Opera do.  Surely this is no coincidence - can 
> anyone enlighten me?
>
> On Monday, 5 December 2016 17:09:06 UTC, John Watson wrote:
>>
>> Maybe I spoke slightly too soon.  I have an application where the 'model' 
>> which is visible to the text area can also be modified by buttons and other 
>> input widgets.  After making the change in the text area from value to 
>> defaultValue, things continue to work as expected with Chrome and Opera, 
>> but no longer with Firefox.  What happens is that things go well for a bit, 
>> but after using the other input widgets, after a little while, the text 
>> area 'freezes' and no longer seems to accept updates from the model.
>>
>> On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:
>>>
>>> Thanks very much, Wil. I was suffering from this and this change fixes 
>>> it I think.
>>>
>>> On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:

 I just ran into this problem. And the work around was pretty simple, 
 and mentioned in a message in this group a while back.

   textarea [
 property "defaultValue" (Json.Encode.string model.body)
   , onInput UpdateBody
   , rows (model.cursorAperture * 2)
   , id "edit-glass"
   , class "form-control"] []
 ]

 I used defaultValue instead of value. I think the textarea and the 
 various frameworks fight each other when 'value' is used, so you get the 
 jumpiness going on. I think it's because Elm is keyed off of 'value' for 
 updates. This way, the textarea maintains its own state, and when it 
 changes, it doesn't trigger a re-render from Elm for the textarea itself.

 On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
 Velázquez wrote:
>
> Hi,
>
> I have a strange, intermittent issue with textareas. It mostly seems 
> to happen in mobile browsers. The issue is that, when editing text *in 
> the 
> middle* of a textarea, as opposed to adding to the end, sometimes the 
> cursor jumps to the end. I assume it's some kind of re-creation of the 
> textarea DOM element.
>
> I have made a simple application with a textarea but that DOES seem to 
> work fine... so I'm wondering if the problem happens because my 
> application 
> is bigger, and I have "subapplications" that use App.map for messages and 
> so on.
>
> Has anyone seen that before? Is it something stupid I'm doing, a bug 
> in Elm, ...? I can make the full source code available if that'll help.
>


-- 
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: Error Repository?

[OvermindDL1]

https://github.com/elm-lang/error-message-catalog is the place to report 
needing better error messages.  It is generally best to talk about it here 
first.  When reporting there be sure it does not already exist in another 
issue (even if closed one as issues can be aggregated together).


On Tuesday, December 6, 2016 at 5:40:39 AM UTC-7, John Orford wrote:
>
> Where do I send an, as a suggestion to improve the error message output?
>
> I accidentally swapped the inputs of a fold lambda,
>
> e.g. 
>
> foldr (\ a c -> ... ) 
>
> instead of
>
>  foldr (\ c a -> ... )
>
> which started complaining about infinite types etc, rather than(in this 
> context at least) nudge me towards having the variables in the wrong order 
> (switching back and forth between languages, does this to you...)
>
>
>

-- 
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 the change in Program type for 0.18?

[OvermindDL1]

Because the prior type could not do inference and type passing based on the 
model and msg type of the program, now it can.


On Monday, December 5, 2016 at 3:49:33 PM UTC-7, Rupert Smith wrote:
>
> I'm curious to know, can anyone explain? Why was the Program type changed 
> from:
>
> Program Never
>
> to 
>
> Program Never model msg
>
> ?
>

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

[elm-discuss] Re: Help with migrating to the new elm-lang/http.

[OvermindDL1]

`withCredentials` is a normal Javascript AJAX argument, it means to pass 
credential information to the remote server if you are connecting to a 
remote server; without it then credentials are not passed, which is better 
for security but without it you may not be able to access things without 
the proper CORS setup.


On Wednesday, November 30, 2016 at 7:56:34 AM UTC-7, Rupert Smith wrote:
>
> On Tuesday, November 29, 2016 at 4:44:01 PM UTC, Rupert Smith wrote:
>>
>> This write up here is proving very helpful in understanding the new 
>> elm-lang/http. Has before and after examples showing how code is changed 
>> between 0.17 and 0.18:
>>
>> http://rundis.github.io/blog/2016/haskel_elm_spa_part6.html
>>
>
> Any idea what 'withCredentials' does? Its a Bool. 
>

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

Re: [elm-discuss] What is the motivation for using google groups?

[OvermindDL1]

Another +1 for reddit here, I don't use the mailing list aspects of things 
but for one who does reddit would be a -1, but there are so many 
aggregators for reddit that I've no doubt a mailing list thing is made by 
someone or a hundred.


On Saturday, November 26, 2016 at 12:09:40 AM UTC-7, Robin Heggelund Hansen 
wrote:
>
> Fine by me. I check Reddit as often as I check this mailing list :)
>
> lørdag 26. november 2016 03.34.07 UTC+1 skrev Richard Feldman følgende:
>>
>> We've talked in the past about moving to https://reddit.com/r/elm - in 
>> part for threaded discussions and voting, but also more to have things more 
>> centralized.
>>
>> After all, /r/elm is still going to exist whether there's additionally a 
>> Google Group, a Discourse forum, etc. It'd be nice to have only one board 
>> to check.
>>
>> What do people think?
>>
>>

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

Re: [elm-discuss] What is the motivation for using google groups?

[OvermindDL1]

I'm curious what those are?  Discourse follows the spec for mailing list 
messages.  For the broken email clients like the usual apple one that one's 
issues are resolved by adding "Re: " to the subject line on the mailing 
template (which elixir forums did just recently since finally found out how 
apple's client was broken).  What else is there?


On Friday, November 25, 2016 at 5:46:43 PM UTC-7, Hassan Schroeder wrote:
>
> On Fri, Nov 25, 2016 at 4:17 PM, OvermindDL1  > wrote: 
> > The Elixir forum (which has an Elm section if anyone wants to give it a 
> try) 
> > has resolved its mailing list oddities fairly well now and can be used 
> 'as' 
> > a mailing list in addition to a forum, so it satisfies both sides quite 
> well 
> > now. 
>
> Allow me to disagree -- the Discourse-based "mailing list" remains 
> an intrinsically horrible design; every interaction with it erodes my 
> will to live a little more... :-) 
>
> Fingers crossed for the success of Josh's kickstarter to develop an 
> Elixir/Elm-based Discourse replacement so we have a chance to do 
> it right. 
>
> -- 
> Hassan Schroeder  hassan.s...@gmail.com 
>  
> twitter: @hassan 
> Consulting Availability : Silicon Valley or remote 
>

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

Re: [elm-discuss] What is the motivation for using google groups?

[OvermindDL1]

The Elixir forum (which has an Elm section if anyone wants to give it a 
try) has resolved its mailing list oddities fairly well now and can be used 
'as' a mailing list in addition to a forum, so it satisfies both sides 
quite well now.  An Elm Forum could do the same.


On Friday, November 25, 2016 at 3:54:17 PM UTC-7, Juan Soto wrote:
>
> In Elixir, we moved to a Discourse forum. Works pretty well though I 
> assume there was some kickback by people who like mailing lists but in 
> general people are happy.
>
> On Friday, November 25, 2016 at 3:45:33 PM UTC-5, W. Brian Gourlie wrote:
>>
>> Ok, so there 's clearly a desire for something better, but some folks 
>> prefer google groups as a mailing list.  Elm makes a deliberate appeal to 
>> ease-of-use and simplicity, which is at odds with using google groups as a 
>> community forum.  
>>
>> Past discussions aside, I think it's worth revisiting.
>>
>> On Friday, November 25, 2016 at 1:21:29 PM UTC-6, Janis Voigtländer wrote:
>>>
>>> Suggestion: Use the google group's search facility to check whether the 
>>> thing you propose has been discussed before. :-)
>>>
>>> Hint: It's the case, and I think that even the "discourse" suggestion 
>>> was made and discussed then. 
>>>
>>> Am 25.11.2016 um 20:04 schrieb W. Brian Gourlie :
>>>
>>> I find google groups to be a poor experience on many different levels, 
>>> and I'm wondering if there is any motivation for using it other than "it's 
>>> free and easy."  If there is any interest in an alternative, I would be 
>>> willing to set up a discourse instance, if only temporarily, to see if 
>>> people may prefer that instead.  It's much better suited for technical 
>>> discussion as it supports markdown and syntax highlighting, and is 
>>> generally a much better UX.
>>>
>>> If you haven't heard of discourse, you can get an idea of what it is by 
>>> checking out the rustlang forums: https://users.rust-lang.org/
>>>
>>> -- 
>>> 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: Using Navigation - is Events.onWithOptions required?

[OvermindDL1]

I actually prefer to have anchor tags around the document but have a top 
level catch that stops page movements to url's I whitelist and instead just 
redirects navigation (which then updates other parts of the app), seems the 
most simple, but it is definitely not wrapped up in an easy way in elm yet 
(and mine is in javascript...).

On Wednesday, November 23, 2016 at 4:41:02 PM UTC-7, Wouter In t Velt wrote:
>
> Op woensdag 23 november 2016 23:52:54 UTC+1 schreef Brian Marick:
>>
>> So I suspect I’m doing something wrong. Am I?
>>
>
> Not wrong, I guess, but it is kind of a peculiar setup.
>
> I also use elm-lang/navigation, and never ran into this issue.
> After checking my code:
>
>- Either I use an `a [ href "#/path/location ]` to let the url-parser 
>navigate when the user clicks the link.
>- Or I use `button [ onClick (NavigateTo NewLocation) ]` to go to the 
>update function.
>
> (urlUpdate and update are wired so that navigation instructions can come 
> in through either function).
>
> So it seems kind of double to use both the href and the onClick on the 
> same element to do navigation.
>

-- 
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] Can Javascript to start Elm app be attached per page?

[OvermindDL1]

Awesome, you should post that in the elm section of the ElixirForums too so 
both sides can see it!  :-)


On Monday, November 21, 2016 at 5:52:59 PM UTC-7, Brian Marick wrote:
>
> I figured out how to make it work, thanks to your help. Because there are 
> some fiddly bits, I wrote up a blog post that points to a frozen branch 
> that might help others. It’s here:
>
> http://blog.roundingpegs.com/phoenix-elm-and-multiple-single-page-apps/
>
>
> On Nov 21, 2016, at 11:43 AM, OvermindDL1  > wrote:
>
> A few things (as I do use elm with phoenix):
>
> 1. Make sure the script tag is loaded before you load a page specific call 
> like require or so (my script sends a 'js-loaded' event when done that my 
> pages can listen to if it is not already sent, a simple function in the 
> head can simplify that to a single call).
> 2. I like to pack all my elm apps into a single file (which is then 
> stuffed inside app.js and minimized and such).  My individual pages just 
> call `require("web/static/elm.js").whateverApp.embed(blah);`, thus the 
> individual pages determine what they call, not a lot of checks in the 
> javascript.  :-)
>
>
> On Sunday, November 20, 2016 at 4:31:15 PM UTC-7, Brian Marick wrote:
>>
>> Note: newbie to Javascript and frontend in general. 
>>
>> TL/DR: I would like to see an example of the Best Way to (1) have N urls 
>> invoke N single-page Elm apps, and (2) pass each of them url-specific flags 
>> (to be received by  `Html.App.programWithFlags`). 
>>
>> - 
>>
>> The Elixir/Phoenix book [1] suggests having a single “app.js” file, 
>> compiled by Brunch. Part of the code compiled into that single file 
>> contains specific tests of the form “Am I on the page where behavior X is 
>> appropriate? If so, run this (page-specific) code to cause behavior X.” 
>> Given that my code for X is written in Elm, the source for the Brunch 
>> compilation contains code like this: 
>>
>> import Elm from './critter4us' 
>>
>> const ivDiv = document.querySelector('#iv-target'); 
>> if (ivDiv) { 
>> Elm.IV.embed(ivDiv); 
>> } 
>>
>> const animalsDiv = document.querySelector('#animals-target'); 
>> if (animalsDiv) { 
>>  Elm.Animals.embed(animalsDiv, { 
>> authToken: window.auth_token, 
>> }); 
>> } 
>>
>> // etc. 
>>
>> Note that the arguments are passed to Elm by cramming them into global 
>> variables before the “app.js” file is loaded. That is: 
>>
>> window.auth_token = "<%= assigns[:auth_token] %>" 
>> "> 
>>
>> --- 
>>
>> I can imagine having a whole sequence of such `if` tests in the master 
>> javascript file, one for each Elm-enabled page. But that seems really 
>> convoluted. It seems it would be better for each page to request a single 
>> library (app.js, loaded from cache), then have a snippet of code that 
>> launches the Elm app. 
>>
>> That is, following: 
>>
>> "> 
>>
>> would be a page-specific: 
>>
>>  
>>   Elm.Animals.embed("#animals-target", { 
>>   authToken: “fe9c6177-02df-4510-88fd-4c1bbe023d16", 
>>   …} 
>>  
>>
>> (Note: no need to cram values into `window`.) 
>>
>> But I can’t make that work. Can someone point me to examples? 
>>
>>
>> ——— 
>>
>> [1] https://pragprog.com/book/phoenix/programming-phoenix
>
>
> -- 
> 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: Tell me how to teach Web Apps

[OvermindDL1]

I teach languages but not web programming specifically.  I'd might 
recommend Elixir as a good back-end server software to program in.  It is 
easily one of the language that are the most fun to program in, although it 
is not statically typed, it is fully functional.  I happen to use Elixir on 
the back-end and Elm on the front-end for my big server right now.


On Monday, November 21, 2016 at 4:23:56 PM UTC-7, Robert Muller wrote:
>
> I'm teaching a full-semester course on Web Apps this spring. It's my first 
> time through so I have a lot to learn. I'm a long-time functional 
> programmer (mostly ML: SML & OCaml). If I wasn't worried about my students 
> getting jobs and internships the choice would be obvious: I'd teach Elm! 
> But the students are taking the course to get jobs and internships and I 
> have to respect that so I'm looking for advice.
> A couple of former students in industry tell me that I definitely need to 
> cover back-end issues. So I'm considering teaching the front 3/4 of the 
> course using Node.js + React.js and then integrating Elm in the advanced 
> topics part during the last 1/4 might be reasonable.
>
> But maybe not. Please tell share your thoughts with me!
>
> Bob Muller
> Boston College
>

-- 
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: highlight.js and elm code

[OvermindDL1]

As I recall highlightjs is heavily based on regex, which makes parsing a 
lot of things interesting and people have to handle the odd edge cases like 
that, which it probably is not.  I use highlightjs as well and it is 
painful on about every language...

On Monday, November 21, 2016 at 4:17:08 PM UTC-7, Brian Marick wrote:
>
> I recently installed highlight.js (http://highlightjs.readthedocs.io) on 
> my blog. It’s supposed to understand Elm code, but the results are not 
> appealing:
>
>
> Given the same thing happens with Haskell code, I suspect I’m doing 
> something wrong. Any advice or experience? 
>

-- 
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: Current date (sorry for starting it again)

[OvermindDL1]

Date.now would not be a functional call that way (returning the same output 
for the same input) thus that could not work (without hacks like native 
modules, but that would also break reproduceability).  By making it an 
effect it can just return a request to get the actual date.


On Monday, November 21, 2016 at 12:29:09 PM UTC-7, Tim Bezhashvyly wrote:
>
> Sorry for starting it again but do I really need to do Task.perform just 
> to print current year just once? "Date.year Date.now" doesn't work as 
> Date.now returns Task.Task x Date.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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Unpublishing a package

[OvermindDL1]

There is always this:  https://github.com/gdotdesign/elm-github-install
Install via:
```sh

npm install -g elm-github-install

```
With this usage:
```json

# elm-package.json
{
  ...
  "dependencies": {
...
"githubUser/repoName": "desiredVersion <= v < someLargerNumber",
"NoRedInk/nri-elm-css": "1.3.0 <= 1.3.0 < 2.0.0",
...
  }
  ...
}

```
Then this to install them:
```sh

elm-github-install

```


On Monday, November 21, 2016 at 11:49:17 AM UTC-7, Michel Rijnders wrote:
>
> On Monday, November 21, 2016 at 3:40:02 PM UTC+1, Peter Damoc wrote:
>>
>> On Mon, Nov 21, 2016 at 1:42 PM, Michel Rijnders  
>> wrote:
>>
>>> The issue is that somebody forked our package (truqu/elm-base64) and 
>>> published it, so now there's two (nearly) identical packages, potentially 
>>> causing confusion.
>>>
>>
>> This is a more interesting issue to discuss. 
>>
>> On one side, there should be freedom to fork and improved/change a 
>> package (as long as your license allows it). 
>> On the other side, I would not want nearly identical packages creating 
>> noise in the package manager. 
>>
>
> Totally agree, but in our case the fork was done solely because our 
> package hadn't been upgraded to 0.18 yet. So once we upgraded our package 
> there were two indentical packages. (Or nearly identical, because they 
> forgot to upgrade the tests.)
>
> IMO having a way to install packages from other sources than 
> package.elm-lang.org would solve this.
>  
>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

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

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

[OvermindDL1]

I highly doubt it would ever be changed, but I significantly prefer the 
OCaml style Some/None to Haskell's Just/Nothing as well.

Although `Thing` and `NoThing` could by funny and descriptive both.  ^.^


On Monday, November 21, 2016 at 10:48:11 AM UTC-7, Will White wrote:
>
> I remember being confused by Just, and I still find it awkward. Hearing 
> Richard F. explain it in his introductory Elm talk 
>  is what prompted me to start 
> this discussion.
>
> On 21 Nov 2016, at 17:33, Noah Hall > 
> wrote:
>
> Has anyone actually encountered anyone being confused by the names? I
> haven't. I think this a solution to a problem that doesn't exist.
>
> On Mon, Nov 21, 2016 at 6:15 PM, Will White  > wrote:
>
> I think that’s because you already know what Just means. I don’t think it’s
> arbitrary though from an accessibility point of view. Some or None is 
> easier
> for newcomers to understand than Just or Nothing, especially as Some isn’t
> misleading the way Just is, as Andrew described well.
>
> On 21 Nov 2016, at 17:05, Joey Eremondi > 
> wrote:
>
> Honestly, these choices seem pretty arbitrary. Everyone has a preference. 
> ML
> uses Some/None, Haskell uses Just/Nothing. Some people find Something
> intuitive, some don't.
>
> Given that the choices is (mostly) arbitrary, it seems best to stick with
> the status quo.
>
> On Mon, Nov 21, 2016 at 7:47 AM, 'Andrew Radford' via Elm Discuss
> > wrote:
>
>
> Probably inherited from Haskell, like a lot of other stuff. Doubt if there
> was any other thought put into it if I'm honest.
>
> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote:
>
>
> Sorry, meant to say “I guess he’s already considered and rejected them”.
>
> On 21 Nov 2016, at 14:21, Will White  wrote:
>
> I prefer Some or None, for understanding. Though, unless Evan didn’t know
> about them, I guess we’d already have them.
>
> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen 
> wrote:
>
> How about 'Some' and 'None'?
> Those are not longer to type than what we have today, and they should
> solve your initial confusion.
>
> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende:
>
>
> I'm talking about Maybe.Just, of course. Just has always seemed strange
> to me, as if it's hinting that it's something other than just the
> counterpart to Nothing. I don't know the reasons behind its naming, but I
> think I would prefer Something, as in "something or nothing". What do you
> think?
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Can Javascript to start Elm app be attached per page?

[OvermindDL1]

A few things (as I do use elm with phoenix):

1. Make sure the script tag is loaded before you load a page specific call 
like require or so (my script sends a 'js-loaded' event when done that my 
pages can listen to if it is not already sent, a simple function in the 
head can simplify that to a single call).
2. I like to pack all my elm apps into a single file (which is then stuffed 
inside app.js and minimized and such).  My individual pages just call 
`require("web/static/elm.js").whateverApp.embed(blah);`, thus the 
individual pages determine what they call, not a lot of checks in the 
javascript.  :-)


On Sunday, November 20, 2016 at 4:31:15 PM UTC-7, Brian Marick wrote:
>
> Note: newbie to Javascript and frontend in general. 
>
> TL/DR: I would like to see an example of the Best Way to (1) have N urls 
> invoke N single-page Elm apps, and (2) pass each of them url-specific flags 
> (to be received by  `Html.App.programWithFlags`). 
>
> - 
>
> The Elixir/Phoenix book [1] suggests having a single “app.js” file, 
> compiled by Brunch. Part of the code compiled into that single file 
> contains specific tests of the form “Am I on the page where behavior X is 
> appropriate? If so, run this (page-specific) code to cause behavior X.” 
> Given that my code for X is written in Elm, the source for the Brunch 
> compilation contains code like this: 
>
> import Elm from './critter4us' 
>
> const ivDiv = document.querySelector('#iv-target'); 
> if (ivDiv) { 
> Elm.IV.embed(ivDiv); 
> } 
>
> const animalsDiv = document.querySelector('#animals-target'); 
> if (animalsDiv) { 
>  Elm.Animals.embed(animalsDiv, { 
> authToken: window.auth_token, 
> }); 
> } 
>
> // etc. 
>
> Note that the arguments are passed to Elm by cramming them into global 
> variables before the “app.js” file is loaded. That is: 
>
> window.auth_token = "<%= assigns[:auth_token] %>" 
> "> 
>
> --- 
>
> I can imagine having a whole sequence of such `if` tests in the master 
> javascript file, one for each Elm-enabled page. But that seems really 
> convoluted. It seems it would be better for each page to request a single 
> library (app.js, loaded from cache), then have a snippet of code that 
> launches the Elm app. 
>
> That is, following: 
>
> "> 
>
> would be a page-specific: 
>
>  
>   Elm.Animals.embed("#animals-target", { 
>   authToken: “fe9c6177-02df-4510-88fd-4c1bbe023d16", 
>   …} 
>  
>
> (Note: no need to cram values into `window`.) 
>
> But I can’t make that work. Can someone point me to examples? 
>
>
> ——— 
>
> [1] https://pragprog.com/book/phoenix/programming-phoenix

-- 
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] Can't install native package using elm-github-install

[OvermindDL1]

On Friday, November 18, 2016 at 5:18:27 AM UTC-7, Rupert Smith wrote:
>
> I found using a port to enable global communication with the Auth module 
> from anywhere in my application (any time you get a 401 or 403 you invoke 
> 'unauthed') to be quite convenient. Perhaps I might find a better solution 
> to this using out messages, or perhaps Elm will eventually develop some 
> sort of pub/sub messaging mechanism that I could use instead.
>

It has that, they are called subscriptions.  ^.^

Subscriptions link to an Effect Module, you can make your own subscriptions 
via making an effect module (with potentially native module code used by it 
as well to properly hide all the internals). 

-- 
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] Listening to messages from different modules on an update

[OvermindDL1]

aMSG is not a valid constructor name, perhaps instead AMSG or A_Msg or MsgA 
or so, as long as it starts with an uppercase.  :-)


On Tuesday, November 15, 2016 at 3:50:36 PM UTC-7, Tim Bezhashvyly wrote:
>
> Thank you. Tried to apply it but my problem is that I'm trying to send 
> initialize a request on init:
>
> init : ( Model, Cmd Msg )
> init =
>  ( { 
>  -- my model here
>  }
>  , getJson
>  )
>
> And of course `getJson` is returning `A.Msg`, so even if in B I declare:
>
> type Msg
>  = aMSG A.Msg
>  | SomeLocalMessage
>
>
> I'm still getting an error that init was expecting `Main.Msg` but got 
> `A.Msg`.
>
> Hope I make sense.
>
>
> On Tuesday, November 15, 2016 at 7:40:50 AM UTC+1, Peter Damoc wrote:
>>
>> There used to be a "nesting" set of examples in The Elm Architecture but 
>> lately this approach has been discouraged. 
>>
>> What you describe here is a kind of decomposition into components. 
>>
>> It is recommended that you have one model and you decompose the 
>> functionality of update & view using regular functions. 
>>
>> If you want to see how this used to be done, take a look at the old 
>> CounterPair example:
>>
>> https://github.com/pdamoc/elm-architecture-tutorial/blob/master/examples/2/CounterPair.elm
>>
>> Please note that this code is obsolete. 
>>
>>
>>  
>>
>> On Mon, Nov 14, 2016 at 4:43 PM, Tim Bezhashvyly  
>> wrote:
>>
>>> I just started digging into Elm so quite possible that my question has a 
>>> conceptual problem. Please let me know if so.
>>>
>>> I have a module A which is asynchronously reading data from JSON. Module 
>>> A among other things exposes `getJson` function. As the read is processing 
>>> data asynchronously it can not just return data structure but returning 
>>> it's Msg type instead which is:
>>>
>>> type Msg
>>>   = FetchSucceed (Maybe Jobs)
>>>   | FetchFail Http.Error
>>>
>>> Now if module B imports module A it can call `getJson` method but it 
>>> will only trigger  initial call and then has to listen to `FetchSucceed
>>> `:
>>>
>>> update : A.Msg -> A -> (A, Cmd A.Msg)
>>> update msg model =
>>>   case msg of
>>>   FetchSucceed a ->
>>>   (A a, Cmd.none)
>>>
>>>   FetchFail _ ->
>>>   (model, Cmd.none)
>>>
>>> My question is if module B has it's own command how does `update` 
>>> function combines listening to commands from both modules?
>>>
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

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

Re: [elm-discuss] Re: Effects.tick vs Time.fps

[OvermindDL1]

Heh, good looking library, but you should definitely make it in a new 
thread titled as your library.  :-)


On Tuesday, November 15, 2016 at 3:13:34 PM UTC-7, Nick H wrote:
>
> On second thought, maybe it was not the best idea to resurrect a thread 
> whose title refers to two functions that no longer exist...
>
> On Tue, Nov 15, 2016 at 1:09 PM, Nick H  > wrote:
>
>> Thread... resurrected!
>>
>> Just wanted to mention that I took the game loop pattern and wrapped it 
>> up in a library 
>> . If 
>> anyone has feedback on the API, I would love to hear it. I went with 
>> something that made sense to me, but... well, you can draw any line you 
>> want through just one data point :-)
>>
>>
>> On Thu, Feb 25, 2016 at 4:38 PM, d13 > 
>> wrote:
>>
>>> That's brilliant, thanks so much for sharing your code!!
>>>
>>> -- 
>>> 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: How to manage subscriptions that require side effects?

[OvermindDL1]

There is not much documentation on it on purpose.  ^.^
Best way to learn it is to read how it is implemented in the core 
libraries.  :-)

As a comparison, if you are try to implement TEA in Swift, I managed to 
make subscriptions in mine via startup/shutdown callbacks and a back-end 
differ, quite easy to make then.  :-)


On Tuesday, November 15, 2016 at 2:35:20 PM UTC-7, Guido Marucci Blas wrote:
>
> Thanks a lot for the detailed answer!!! I clearly wasn't aware of the 
> effect manager. I would read more about it.
>
> Thanks!
>
> On Tuesday, November 15, 2016 at 6:20:27 PM UTC-3, OvermindDL1 wrote:
>>
>> Comments i
>>
>> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
>> wrote:
>>>
>>> Hi everybody! I've been reading the docs and following Elm every now and 
>>> then.  I did some toy application to learn the language and the 
>>> architecture. I am working on a native iOS application so using Elm in my 
>>> day job won't happen (for now). The main reason I want to learn Elm (apart 
>>> from it being awesome!) is that I want to apply Elm's architecture to iOS 
>>> with Swift (yeah a lot of people is doing the same thing). There are quite 
>>> a few libraries that try to bring Elm's architecture to Swift but I don't 
>>> want to use them. I want to implement something myself because that way I 
>>> will be able to understand it better. 
>>>
>>> The reason I am writing is that I want to better understand how 
>>> subscriptions work internally. Please correct me if I am wrong. My 
>>> understanding of how subscription works is that they provide a mechanism to 
>>> "hook" to a stream of infinite events. Those events get mapped to your own 
>>> application message by virtue of the message constructor function that is 
>>> passed when creating a new subscription. As far as I can tell the only way 
>>> of creating subscription is by a model update. Every time the model gets 
>>> updated, Elm's runtime calls the subscription function (passed to the init 
>>> function when you bootstrap your app). This gives us the change to create a 
>>> new subscription based of the current state. Am I correct? 
>>>
>>>- Is there any other way of creating subscriptions? 
>>>- What happens when the process of starting a subscription needs to 
>>>perform a expensive side-effect? 
>>>- What is the Elm way of doing this?
>>>
>>> No other way of creating subscriptions.
>> The subscription itself should be fairly minimal, the effect manager 
>> handling the subscription setup and teradown should be doing all the costly 
>> stuff 'out-of-band' of your main app.
>>
>> On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
>> wrote: 
>>
>>> Lets say that I have an application that connects to an external device 
>>> and after connecting with this device it wants to start listening to a 
>>> stream of data that this device reports every one second. Lets imagine this 
>>> device is thermometer that advertises the room's temperature. I want to 
>>> have an app that prints the average temperature since a connection with 
>>> thermometer was established. We can omit how we connect with thermometer 
>>> for now
>>>
>>
>>> type alias Model = 
>>> { thermometer: Maybe Thermometer
>>> , temperatureSamples: List Float
>>> }
>>>
>>>
>>> type Msg 
>>>   = ConnectedThermometer Thermometer
>>>   | TemperatureSample Float
>>>
>>>
>>> update : Msg -> Model -> (Model, Cmd Msg) 
>>> update msg model =
>>>   case msg of
>>> ConnectedThermometer thermometer ->
>>>   ({ model | thermometer = thermometer }, Cmd.none)
>>>
>>>
>>> TemperatureSample temperature ->
>>>   ({ model | temperatureSamples = temperature :: model.
>>> temperatureSamples}, Cmd.none)
>>>
>>> view : Model -> Html Msg
>>> view model = 
>>>   let
>>> averageTemperature = (List.sum model.temperatureSamples) / List.length 
>>> model.temperatureSamples
>>>   in
>>> Html.text (toString averageTemperature)
>>>
>>>
>>> subscriptions : Model -> Sub Msg
>>> subscriptions model =
>>>   model.thermometer
>>> |> map Thermometer.temperature TemperatureSample
>>> |> withDefault Sub.none
>>>

[elm-discuss] Re: How to manage subscriptions that require side effects?

[OvermindDL1]

Comments i

On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas wrote:
>
> Hi everybody! I've been reading the docs and following Elm every now and 
> then.  I did some toy application to learn the language and the 
> architecture. I am working on a native iOS application so using Elm in my 
> day job won't happen (for now). The main reason I want to learn Elm (apart 
> from it being awesome!) is that I want to apply Elm's architecture to iOS 
> with Swift (yeah a lot of people is doing the same thing). There are quite 
> a few libraries that try to bring Elm's architecture to Swift but I don't 
> want to use them. I want to implement something myself because that way I 
> will be able to understand it better. 
>
> The reason I am writing is that I want to better understand how 
> subscriptions work internally. Please correct me if I am wrong. My 
> understanding of how subscription works is that they provide a mechanism to 
> "hook" to a stream of infinite events. Those events get mapped to your own 
> application message by virtue of the message constructor function that is 
> passed when creating a new subscription. As far as I can tell the only way 
> of creating subscription is by a model update. Every time the model gets 
> updated, Elm's runtime calls the subscription function (passed to the init 
> function when you bootstrap your app). This gives us the change to create a 
> new subscription based of the current state. Am I correct? 
>
>- Is there any other way of creating subscriptions? 
>- What happens when the process of starting a subscription needs to 
>perform a expensive side-effect? 
>- What is the Elm way of doing this?
>
> No other way of creating subscriptions.
The subscription itself should be fairly minimal, the effect manager 
handling the subscription setup and teradown should be doing all the costly 
stuff 'out-of-band' of your main app.

On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
wrote: 

> Lets say that I have an application that connects to an external device 
> and after connecting with this device it wants to start listening to a 
> stream of data that this device reports every one second. Lets imagine this 
> device is thermometer that advertises the room's temperature. I want to 
> have an app that prints the average temperature since a connection with 
> thermometer was established. We can omit how we connect with thermometer 
> for now
>

> type alias Model = 
> { thermometer: Maybe Thermometer
> , temperatureSamples: List Float
> }
>
>
> type Msg 
>   = ConnectedThermometer Thermometer
>   | TemperatureSample Float
>
>
> update : Msg -> Model -> (Model, Cmd Msg) 
> update msg model =
>   case msg of
> ConnectedThermometer thermometer ->
>   ({ model | thermometer = thermometer }, Cmd.none)
>
>
> TemperatureSample temperature ->
>   ({ model | temperatureSamples = temperature :: model.
> temperatureSamples}, Cmd.none)
>
> view : Model -> Html Msg
> view model = 
>   let
> averageTemperature = (List.sum model.temperatureSamples) / List.length 
> model.temperatureSamples
>   in
> Html.text (toString averageTemperature)
>
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>   model.thermometer
> |> map Thermometer.temperature TemperatureSample
> |> withDefault Sub.none
>
>
> -- Inside the Thermometer module
> temperature : (Float -> Msg) -> Thermometer -> Sub Msg
> temperature msgConstructor thermometer = ...
>
>
> *I am assuming there is a function in the Thermometer that knows how to 
> create subscription for a given connected thermometer. I am also assuming 
> that this MUST be implemented in Javascript and that all needed 
> side-effects in order to create the subscription are performed on the JS 
> side.*
>

Nah, subscription can be managed within Elm by an effect manager (though it 
tends to eventually go out to a javascript effect manager, like via HTTP 
requests or whatever).


On Tuesday, November 15, 2016 at 2:02:10 PM UTC-7, Guido Marucci Blas 
wrote: 

> If my assumptions are correct then my main concern is that for every state 
> update this "expensive" side effects that could be performed on the JS side 
> by creating a new subscription are executed for every model update. If that 
> is the case then I have the following questions
>

A subscription is just that, a subscription, saying that you 'want to 
listen to messages from a given effect manager'.  The remote effect manager 
could even be doing stuff even when nothing is subscribed, a subscription 
is just that the main app wants to listen to messages from that effect 
manager.  Subscriptions should change only based on your state.  Basically 
it works kind of like this:

1. You have a subscription that appears when something on your model is, 
say, True.
2. The system sees that a new subscription has appeared compared to the 
last check, so it calls into the effect manager (passing it a 
'registration' m

Re: [elm-discuss] 0.18 Below the Hood

[OvermindDL1]

y, so read more about it.
<https://github.com/elm-lang/elm-compiler/blob/0.17.1/hints/type-annotations.md>

Detected errors in 1 module.
```



On Tuesday, November 15, 2016 at 11:43:58 AM UTC-7, John Orford wrote:
>
> > And there are certain classes of typed problems that are impossible 
> without this feature, so it is highly useful!
>
> Can you expand on this? I imagine it's expressions all the way down and 
> type inference is still possible... so imagine it's a nice-to-have rather 
> than must-have.
>
> Would like to understand more basically!
> On Tue, 15 Nov 2016 at 17:40, OvermindDL1  > wrote:
>
>> On Tuesday, November 15, 2016 at 9:30:23 AM UTC-7, Max Goldstein wrote:
>>>
>>> My impression is that it's a Haskell extension that's very commonly 
>>> used. In the process of upgrading, I uncommented some signatures only for 
>>> the compiler to tell me that they are incorrect, so this feature has been 
>>> useful already.
>>
>>
>> Oh it is very useful!  And there are certain classes of typed problems 
>> that are impossible without this feature, so it is highly useful!
>>
>> An example of usage in OCaml anyway (since I have a shell of it up right 
>> now):
>> ```ocaml
>> let f (x : 'x) =
>>   let a (y : 'x) = ()
>>   in a
>>
>> let b = f 42 3
>> ```
>> That compiles right, changing b to this though:  let b = f 42 3.14
>> Causes this error:
>> ```
>> Line 6, 14: Error: This expression has type float but an expression was 
>> expected of type
>>  int
>> ```
>> Where this compiles fine (and may not only be entirely unexpected but 
>> could hide major bugs later in the program!):
>> ```ocaml
>> let f x =
>>   let a y = ()
>>   in a
>>
>> let b = f 42 3.14
>> ```
>>
>> -- 
>> 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] 0.18 Below the Hood

[OvermindDL1]

On Tuesday, November 15, 2016 at 9:30:23 AM UTC-7, Max Goldstein wrote:
>
> My impression is that it's a Haskell extension that's very commonly used. 
> In the process of upgrading, I uncommented some signatures only for the 
> compiler to tell me that they are incorrect, so this feature has been 
> useful already.


Oh it is very useful!  And there are certain classes of typed problems that 
are impossible without this feature, so it is highly useful!

An example of usage in OCaml anyway (since I have a shell of it up right 
now):
```ocaml
let f (x : 'x) =
  let a (y : 'x) = ()
  in a

let b = f 42 3
```
That compiles right, changing b to this though:  let b = f 42 3.14
Causes this error:
```
Line 6, 14: Error: This expression has type float but an expression was 
expected of type
 int
```
Where this compiles fine (and may not only be entirely unexpected but could 
hide major bugs later in the program!):
```ocaml
let f x =
  let a y = ()
  in a

let b = f 42 3.14
```

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

Re: [elm-discuss] 0.18 Below the Hood

[OvermindDL1]

On Tuesday, November 15, 2016 at 8:57:30 AM UTC-7, John Orford wrote:

> >  let-bound values can be given type annotations that reference type 
> variables from the top level
>
> that's v thoughtful actually, I hadn't heard that before, just local 
> variables in any case, makes a lot of sense for tricky functions.
>
> is this an elm specific creation or do you also see it in Haskell? (iirc, 
> never)
>

Haskell has an option for it: 
 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#ghc-flag--XScopedTypeVariables

OCaml has it built-in.

I think SML has it built in too.

It is fairly common in other words, and very useful.  :-) 

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

Re: [elm-discuss] Re: Update Delay

[OvermindDL1]

Simplifying is a wonderful way to bug-hunt, one of my go-to methods.  :-)


On Sunday, November 13, 2016 at 2:28:00 PM UTC-7, John Orford wrote:
>
> My mistake! I was querying the previous list of strings rather than the 
> updated one. Good exercise though, simplifying helped me find the bug
> On Sun, 13 Nov 2016 at 19:48, John Orford  > wrote:
>
>> I have attached a simple example.
>>
>> I have a model with a field called 'currentQueryTips'.
>>
>> A list is filtered using the current query string, coming through an 
>> input field.
>>
>> If you run the test you will see that the view is always one step behind 
>> the input.
>>
>> In a previous iteration, I had the query filter function in the view and 
>> everything worked well.
>>
>> As I said before though, I think I did this more elegantly a few months 
>> ago, trying to remember how...
>>
>> Any help is appreciated!
>>
>>
>>
>>
>> On Thu, 10 Nov 2016 at 16:51 OvermindDL1 > > wrote:
>>
>>> Not something I've ever experienced and of which should be fairly 
>>> impossible.
>>>
>>> Do you have a simple reproduceable test-case that we can play with?
>>>
>>>
>>> On Thursday, November 10, 2016 at 8:43:30 AM UTC-7, John Orford wrote:
>>>>
>>>> I have fallen into this trap a few times,
>>>>
>>>> 1) I update my model
>>>>
>>>> 2) The View doesn't change
>>>>
>>>> 3) Some other action occurs
>>>>
>>>> 4) My view changes with the first update
>>>>
>>>> My view is one step behind.
>>>>
>>>> I have fixed this before a few times (been a while ago).
>>>>
>>>> And rather than tinkering, I thought I would ask what the canonical 
>>>> solution is.
>>>>
>>>> It's a simple mistake, but suspect common also, might help others.
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@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: Update Delay

[OvermindDL1]

Not something I've ever experienced and of which should be fairly 
impossible.

Do you have a simple reproduceable test-case that we can play with?


On Thursday, November 10, 2016 at 8:43:30 AM UTC-7, John Orford wrote:
>
> I have fallen into this trap a few times,
>
> 1) I update my model
>
> 2) The View doesn't change
>
> 3) Some other action occurs
>
> 4) My view changes with the first update
>
> My view is one step behind.
>
> I have fixed this before a few times (been a while ago).
>
> And rather than tinkering, I thought I would ask what the canonical 
> solution is.
>
> It's a simple mistake, but suspect common also, might help others.
>

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

[elm-discuss] Re: How to better integrate Elm with webcomponents?

[OvermindDL1]

1.  Honestly, I'm unsure a new program type is needed.  The big 
encapsulation of webcomponents are their properties and attributes. 
 Listening to a property/attribute change internally is as simple as 
getting a message (via subscriptions no doubt) on their change via the 
Observer API (which Polymer hides behind the scenes for you).  Setting 
external attributes and properties can be as simple as sending a command, 
although in my opinion the top-level 'view' element should expose it that 
way, both properties and attributes can be done that way and much more 
succinctly, but that 'might' necessitate a program change to take an 
enhanced view function.

2.  Polymer is just a library to make writing webcomponents in Javascript a 
bit easier, entirely unnecessary for an Elm integration and if you follow 
the HTML5 standards and events (Polymer does standardize a few event names 
that you might want to duplicate for ease of use, but that is really 
optional).  A webcomponent is only the javascript parts.  The reason you 
use some DOM, the  and  parts is just to ease the 
making of the DOM in the webcomponent, this part is entirely unnecessary in 
Elm and that removes the major using point for Polymer, the raw 
webcomponents API is far more simple (though usually more wordy than what 
you could make in Polymer, hence why Polymer is useful for javascript, but 
elm already has a good virtual-dom).

3.  Trivial to do as using them would be just like using normal DOM node's, 
which you can easily use in Elm already.  However, Elm does need to 
register observation events on those elements to listen to the backwards 
flow of 2-way data binding, this is an absolute necessity.

4.  You also need multiple 'main' functions, probably named the same as the 
webcomponent name it creates.  :-)

Elm could definitely become a fantastic webcomponent library.  :-)


On Thursday, November 10, 2016 at 4:11:14 AM UTC-7, Rupert Smith wrote:
>
> On Wednesday, November 9, 2016 at 4:02:42 PM UTC, OvermindDL1 wrote:
> > In my opinion Elm really needs to have a smooth integration with 
> webcomponents.  A webcomponent is a very small unit, something elm 
> > fits fantastically in, has two way data-binding up/down the DOM stack, 
> and getting built-in to browsers (Chrome is about the only one with
> > near-full support though, but it is coming in others).  It is something 
> that Elm would fit fantastically in if we could somehow get information
> > *out* of a webcomponent, right now elm can only put information 'in'.  A 
> binding to the HTML5 Observer API being transformed into Elm
> > Messages would be about perfect.
>
> After experimenting with Elm and Polymer I came to these conclusions on 
> future directions for this effort:
>
> 1. Build some support into the Elm compiler for webcomponents. This would 
> be a new 'program' type with support for hooking parts of the program state 
> and events up to a webcomponent. The consuming program would also be able 
> to link to it, in such a way that it can be given access to its 'public' 
> state. This is really OO encapsulation, and as such might not be a popular 
> idea within Elm. I only have a vague idea of what tighter integration would 
> look like anyway, so far too early to start down this route.
>
> 2. Build a component library using Elm + minimal amount of Polymer.
>
> 3. Build components on top of polymer-paper elements in the MDL style.
>
> This thread is about exploring option 1 in further detail, what would an 
> Elm with webcomponents integration built in to the language/framework look 
> like? I'll think about it and see if I can come back with some suggestions 
> or sketch out a bit in pseudo code what it might look like.
>

-- 
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: Correct use of port subscriptions in a submodule reused multiple times?

[OvermindDL1]

Definitely recommend simplifying it yep.  :-)

Ports, in my opinion, should only ever go in one, fully-functional module 
(I have it in a `Ports.elm` in my projects) that all things should share 
through it.  The global top-level update call should feel free to delegate 
messages around.


On Thursday, November 10, 2016 at 3:11:19 AM UTC-7, Matthieu Pizenberg 
wrote:
>
> Thanks OverminDL1 and Wouter In t Velt, I will try to explain how I have 
> come to this issue.
> Originally, I have designed a web page (the "part") that was loading a 
> collection of images to display them.
> So the flow was:
>  - init the elm page with a list of images urls
>  - [port] send the urls to JS
>  - JS create local blob copies of the images at these urls
>  - [port] JS send back the urls of local images to elm
>  - elm can display and manipulate the collection of locally stored images
>
> Everything was working fine.
> Then we wanted to deal with multiple collections of images successively.
> So the app becomed kind of a SPA (the "Group") where each page (a part) 
> corresponded to one collection.
>
> And so the problem is that each page is receiving a notification for 
> loaded images that should notify only the page corresponding to their own 
> collection.
>
> Currently, I have circumvent the problem by filtering.
> Since each page is aware of its own images urls, if it receives a port 
> notification with an new url that does not correspond to one of its own, it 
> does nothing of it.
>
> I have been reading a lot since, and a lot about the problem of making too 
> many "components".
> So as you suggested Wouter In t Velt, I am refactoring a lot of my code 
> (and getting rid of a lot of those "components" inside it ^^).
> It turns out it is getting much simpler than before. So I think I will go 
> with your first advice once it is finished, and manage all ports from the 
> top level SPA (the "Group").
>
> Thanks again, I will let you know how it is going as soon as I get some 
> time to take care of this.
>
> On Wednesday, November 9, 2016 at 5:37:19 AM UTC+8, Wouter In t Velt wrote:
>>
>> In your design, the port has a 1-to-1 connection to the Part.
>> The port does not communicate for which Part the incoming message is 
>> intended, because it "expects" that their is only 1 Part.
>>
>> Your batch function in the subscriptions in the Group.elm passes on the 
>> port message on to all your Parts.
>> Your port receives one message of type `PortMsg (Some, Values)`.
>> The Group subscription function effectively turns this into 10 messages 
>> of type `PartMsg 0 PortMsg (Some, Values)` etcetera.
>> And passes each on Group update function.
>> So all parts respond to the one message.
>>
>> You could:
>>
>>- refactor your port, to provide also an Int id of the intended Part 
>>to receive the message
>>- subscribe to this port ONLY in Group
>>- that would also mean you need to change code in JavaScript-land, to 
>>provide the Id when sending info to Elm
>>
>> Or:
>>
>>- store an `activePart: Int`  in your Group model, so your Group 
>>update knows to which single Part the message should go
>>- subscribe to the (unchanged) port in your Group subscriptions only 
>>(without bundling the subscriptions of each of the Parts)
>>
>> Or other options.
>> But that depends very much on what you want to achieve. The terms 'Part' 
>>  and 'Group' are quite generic, and it is unknown what happens at the other 
>> end of the port.
>> Maybe you could elaborate on what you want to achieve?
>>
>>
>>

-- 
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: Convincing my team that Elm isn't just going to die like CoffeeScript

[OvermindDL1]

Indeed, React is more of a stop-gap before full webcomponent support is out 
in browsers.  And nowadays with webcomponents.js emulating webcomponents on 
about everything 'fairly' decently (although some slowly, which libraries 
like Polymer smooth out) it is becoming less interesting.  In my opinion 
Elm really needs to have a smooth integration with webcomponents.  A 
webcomponent is a very small unit, something elm fits fantastically in, has 
two way data-binding up/down the DOM stack, and getting built-in to 
browsers (Chrome is about the only one with near-full support though, but 
it is coming in others).  It is something that Elm would fit fantastically 
in if we could somehow get information *out* of a webcomponent, right now 
elm can only put information 'in'.  A binding to the HTML5 Observer API 
being transformed into Elm Messages would be about perfect.


On Wednesday, November 9, 2016 at 8:39:15 AM UTC-7, Alexandre Galays wrote:
>
> So true. Even React is not here to stay. Libs come and go, don't feel 
> attached to one. Recruit flexible people who won't go on strike because the 
> stack changes.
>
>
> On Monday, November 7, 2016 at 7:07:06 PM UTC+1, John Orford wrote:
>>
>> I think *convincing* is besides the point.
>>
>> Tech comes and goes.
>>
>> I would rather read through the features of Elm, and make a checklist.
>>
>> Pure functions
>> Immutability
>> ADTs
>> Explicitness (avoiding type classes and other abstractions)
>> User friendliness
>> ...
>>
>> If your team buys into these features, then they should go with Elm or 
>> any other setup with the same features.
>>
>> I.e. I suppose, set out what everyone agrees is the basis of good code, 
>> and then go from there.
>>
>> Worst case, if Elm vanishes tomorrow, at least you're all on board with 
>> the same goal of writing code in to this standard, and can code move to 
>> PureScript or Typescript or whatever else matches in years to come.
>>
>> On Mon, 7 Nov 2016 at 18:57 Rex van der Spuy  wrote:
>>
>>> Just a few comments:
>>>
>>> > The one thing I'm not really sure I'm prepared to answer is how I can 
>>> be sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 
>>> years we'll have an impossible time hiring anyone > > who knows how to use 
>>> it because everyone's going to go back to JavaScript.
>>>
>>> Don't invest in any single technology or workflow - just invest in your 
>>> own ability to adapt quickly to constant change.
>>> Front-end software for the web is essentially disposable - let's embrace 
>>> this!
>>> If you get a couple of years of mileage out of your front end app before 
>>> it you need re-write it from scratch using a completely new or different 
>>> technology, you're doing great!
>>> My advice is just grab the best technology you can at the moment, milk 
>>> it for all its worth, jump to something better when it comes along - and 
>>> don't look back.
>>> The path my career took over the past 25 years was: Basic, Hypercard, 
>>> Director/Lingo, Java, Flash/AS3, JavaScript, and now Elm.
>>> Nothing is forever in this industry, and most things are deliriously 
>>> short lived.
>>> Just relax and enjoy the ride! :)
>>>
>>> ... However!
>>> Until Elm reaches v.1.0 (which could be years from now, nobody knows) 
>>> every version bump, every six months or so, results in API breaking changes 
>>> at the language level.
>>> Some of those changes, like from 0.16 to 0.17 have been huge and have 
>>> required quite a painful upgrade.
>>> (For example It took me 7 hours to upgrade a 3000 LOC app, making over 
>>> 200 changes. All of those 7 hours, except the last five minutes, was done 
>>> blind just following the compiler's messages.)
>>> Are you prepared to invest in upgrading your entire Elm codebase with 
>>> every version bump to keep it current?
>>> In that regard, although you can definitely use Elm in production, its 
>>> still very much an experimental technology - and we are the lab rats.
>>> But, it says a lot for the dismal state front end web development even 
>>> under these conditions Elm is way better than anything else out there!
>>>
>>> Regarding learning Elm:
>>> I'm a non-talented, slow learner who has to do everything about 10 times 
>>> before it sinks in.
>>> And then I have to do it another 10 times just to make sure.
>>> It took me about 2 weeks of true beginner-level head-banging to get to 
>>> grips with Elm, and another 2 weeks of tentative experimentation before I 
>>> started being productive.
>>> But, the time I spent learning Elm has been paid back many times over by 
>>> the time I've saved debugging my apps.
>>> Elm has unquestionably saved me **months** of debugging time.
>>> I've had experiences with Elm's compiler that have bordered on the 
>>> supernatural - it's pointed me to bugs that would have taken me weeks of 
>>> laborious mine-sweeping if I have had been using pure JS.
>>> And, the best part about learning Elm? 
>>> It makes programming fun again!
>>>
>>> Regar

[elm-discuss] Re: Correct use of port subscriptions in a submodule reused multiple times?

[OvermindDL1]

That is expected.  Generally you'd have a uniquely named port per module 
unless they really do all need to get the message.  It might be better if 
you describe what you are trying to accomplish instead of how to accomplish 
it?  :-)


On Tuesday, November 8, 2016 at 10:19:37 AM UTC-7, Matthieu Pizenberg wrote:
>
> Hi, I am currently struggling with port subscriptions in a submodule 
> (`Part`)
> reused multiple times in a bigger (`Group`) module like:
>
> -- In Group.elm
> type alias Model =
>   { parts : Array Part.Model }
>
> I've been using the following "batching" technique (here are the relevant 
> parts of 3 files: Part.elm, Ports.elm, Group.elm)
>
> -- Part.elm
>
> type Msg
>  = PortMsg (Some, Values)
>
> update msg model =
>  case msg of
>PortMsg (some, values) -> (...) -- using Debug.log here to see how 
> many times this is called
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
>Ports.portFunction PortMsg
>
>
> -- Ports.elm
>
> port portFunction : ((Some, Values) -> msg) -> Sub msg
>
>
> -- Group.elm
>
> type alias Model =
>  { parts : Array Part.Model }
>
> type Msg
>  = PartMsg Int Part.Msg
>
> subscriptions : Model -> Sub Msg
> subscriptions model =
> Sub.batch
>   <| Array.toList <| Array.indexedMap (Sub.map << PartMsg) (Array.map Part
> .subscriptions model.parts)
>
>
> The problem I face is that when a Sub Msg is processed, the updates of all 
> the parts are triggered instead of just the only one
> that should be subscribing to the msg (I verified it with the `Debug.log` 
> mentionned in the code).
> This means that if I have 10 parts in the group, it will trigger the 
> update function of the right part and also of the 9 other parts that should 
> not be updated with this sub msg.
> This is a huge efficiency problem in addition to potentially modifying my 
> models incorrectly if I don't care somehow in the update function.
>
> I fear I have come to this issue by design flaws since I'm not finding a 
> way to overcome it.
> Does anyone have an idea of what I'm doing wrong ?
>

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

[OvermindDL1]

What are they clicking on?  Can you show a simplified example that 
demonstrates the issue?

What it sounds like though, it they are clicking maybe an "a" element that 
has a "src" attribute set and you are reacting to a message on it, that you 
are not preventing default?



On Sunday, November 6, 2016 at 8:08:04 PM UTC-7, dedo wrote:
>
> Help! This is driving me crazy ... 
>
> I have Python/flask at the back end, Elm at front. The landing page is, 
> say, http://localhost:5000. 
>
> My Html.App.program is set up with an init Cmd wrapped around a 
>
> Http.get decoderA "localhost:5000/initialData" 
>
> of back-end data, . That works fine, browser url stays at landing page.
>
> My user next clicks a button and triggers a Cmd with a different callback, 
> wrapped around
>
> Http.get decoderB "localhost:5000/nextData/bar"
>
> and this time the back-end call happens, the response comes back, the 
> correct Msg is invoked, the right *update* state transition happens, and 
> then -- spontaneously -- the URL bar goes to "localhost:5000/?" -- with the 
> question mark -- and a spurious GET is sent to the back end, resetting the 
> page to the initial.
>
> Any ideas appreciated!
>

-- 
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: Metalinguistic abstractions over databases

[OvermindDL1]

Ah, no, in fact I do not recall seeing that, it looks like it has had a lot 
of development recently so it appears that it might be newer than when I 
built my api pipeline.  I've not had a pagination setup yet as the client 
requests the range of what they want for the one set of where a range is 
useful.  It is an internal API so if I exposed it to the public I'd set a 
range limit of 100 or something.

And nope, it's tied in through a specialized websocket (via phoenix) so I 
just build the queries manually and send it in via my phoenix library 
currently, pretty basic, but nice to use even manually.


On Friday, November 4, 2016 at 5:04:05 PM UTC-6, Gavin Walsh wrote:
>
> When you use Absinthe, do you use the relay 
> https://github.com/absinthe-graphql/absinthe_relay module as well? Even 
> though there's no elm equivalent to relay, the relay module helps with 
> pagination it looks like.. or did you do something else for pagination?
>
> And are you using https://github.com/jahewson/elm-graphql for the 
> frontend out of curiosity? 
>
> Thanks!
>
> On Thursday, October 20, 2016 at 10:34:23 AM UTC-4, OvermindDL1 wrote:
>>
>> On Thursday, October 20, 2016 at 3:55:45 AM UTC-6, Rupert Smith wrote:
>>>
>>> On Wednesday, October 19, 2016 at 8:23:46 PM UTC+1, OvermindDL1 wrote: 
>>>>
>>>> Absinthe handles all the nasty parts of GraphQL though, the combining 
>>>> of queries, the real-time type documentation generation, etc... etc...
>>>>
>>>
>>> What database do you use? Is it always a SQL database or can Absinthe 
>>> work with noSQL too?
>>>
>>> Also, when it combines queries, does it translate that down into an 
>>> efficient SQL join? Or does it process the joins outside of the database, 
>>> in the server code? 
>>>
>>
>> It is storage agnostic, and technically you do not even need a storage, 
>> remember that GraphQL calls are basically just RPC, you could have a `fib` 
>> GraphQL call that just calculates that.
>>
>> The database I use is PostgreSQL via the Ecto library though.  Absinthe 
>> is database and all agnostic, however it does have a section at 
>> http://absinthe-graphql.org/guides/ecto-best-practices/ talking about 
>> the best ways to use it with ecto for optimization purposes, and they do 
>> have planned more detailed ecto integration in the future, but for now it 
>> is do-it-yourself (which I prefer, means I can use my permission system to 
>> only return specific things that they have access to).  Absinthe itself 
>> does not combine queries, it has no clue what a query is, it just gives the 
>> graphql 'function call' setup to you, what the user requested, what they 
>> passed in, etc...  With proper Ecto work all the joins are in-database. 
>>  With ecto it is trivial to build up database joins in piecemeal, so it 
>> works fantastically with graphql.
>>
>

-- 
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: Feldmans talk about impossible states

[OvermindDL1]

Ah yeah, as an example say you have a list of messages, a message being a 
record, if you add a new message to the 'end' of the list then 
every-single-message-list-cell will be recreated, although not the message 
records themselves, that is because Elm is functional and a List is a Cons 
List.  If, however, you put the new message at the front (and render it 
backwards) then it changes none of the other.

Now for a list of todo's, if you touch one in the middle then all the list 
cells before it will be recreated, but the todo's themselves will not even 
in those.

That is not really something to worry about much though to be honest.


On Friday, November 4, 2016 at 2:17:36 PM UTC-6, Lars Jacobsson wrote:
>
> Yeah but that was kind of my point though. In an app where 'something' 
> (using your example) is the main piece of data, say a list of todos, then I 
> wouldn't want the whole slice thrown away on every update? Not too familiar 
> with the Elm core so I dont know where to look!

-- 
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: Feldmans talk about impossible states

[OvermindDL1]

Everything inside it is still reused.  Back to the struct if you do 
something like:
```elm
{ model | something = blah }
```
It is making a new model struct, but all the things in its keys other than 
'something' are re-used.  And actually something should be re-used too if 
`blah` is just `blah = model.something`.  You can look at the generated 
javascript.  :-)


On Friday, November 4, 2016 at 9:34:44 AM UTC-6, Lars Jacobsson wrote:
>
> I'm sure many of you have sen Richard Feldmans amazing talk on impossible 
> states from Elm conf. In there he uses a Union Type for working with his 
> data
> History = 
> History =
> { current: Question
> , others: List Question }
>
> This essentially means every time we want to update something in the 
> History, we'll have to use the "History" - constructor instead of the 
> regular record update syntax ( { questions | ... } ). How does this impact 
> performance? I've heard that regular record updates essentially reuses 
> everything that hasn't been changed. But when we are using a constructor - 
> do we get any reuse or are we creating a whole new questions object under 
> the hood?
>

-- 
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: Showing sub views dynamically

[OvermindDL1]

I am unable to load https://guide.elm-lang.org/types/union_types.html due 
to a broken certificate chain error for the site (the certificate itself is 
fine, but its chain to the parents is broken), what is up?

As for your question, it looks fine, but are you wondering about it not 
being more easily extendable or so?  If so you could always encode a Dict 
with String key and a function of `Model -> Html Msg` that you can 
dynamically add remove views too with a key of the active view.  That would 
be storing functions in the model though, which is generally frowned upon 
due to it making debugging more difficult.  It is hard to do that more 
'generic' though as the Elm language is designed to be simple for ease of 
use and lacks the higher constructs (which is a good thing for people 
learning this).  Explicit is better than Implicit as the saying goes.  :-)


On Friday, November 4, 2016 at 7:07:00 AM UTC-6, Samuel Müller wrote:
>
> Hi All,
>
> i'm trying to build an application that is similar to the Widget Dashboard 
> example from here: https://guide.elm-lang.org/types/union_types.html
>
> My specific usecase is this: i have a view which, depending  on what the 
> user has entered into a form, shows a specific "sub view". I call this sub 
> view a "plugin", and one would refer to it as a web component outside of 
> elm world. Check it out here: 
>
> https://github.com/samu/coversheets
>
> What i dont like about my approach is the code on these lines: 
> https://github.com/samu/coversheets/blob/7c9df68c99f7346c6e7491c9d8ef99a9d5c64f26/src/Plugins/PluginDispatcher.elm#L37
>
> Is it possible to do this in a nicer, more generic way? Or is my way of 
> structuring the app insufficient in the first place?
>
>

-- 
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 a decoder the right level of abstraction for parsing JSON?

[OvermindDL1]

I did precisely the same style 
in https://github.com/OvermindDL1/elm-jsphoenix too, to minimize the 
duplication of work (which also increased by elm removing the ability to 
extend record types into a new type, and lacking the ability to move Dict's 
across, so those two things still add some, but it still saved a ton of 
work but (ab)using ports for the end-user).


On Thursday, November 3, 2016 at 10:43:01 AM UTC-6, Kasey Speakman wrote:
>
> I first started using Elm's recommended codec-ing scheme. I found that if 
> I needed to round-trip an entity to an API, I needed *4 representations* 
> of the same entity. One on the client and one on server is given. But then 
> 1 encoder representation and 1 decoder representation... both of which 
> spell out the same information in the type alias. So in order to change the 
> entity, I have 4 places that need maintenance. *No thanks.*
>
> Abusing ports, I arrived at a similar solution to what I explained 
> previously in this thread for decoding. But since encoding is also monkey 
> work, I wanted to abuse ports to launder that too. However, the process to 
> do that was herky-jerky. A port/sub round trip for encoding, then an Elm 
> HTTP call, then a port/sub round trip for decoding. Instead, I abandoned 
> the Elm HTTP library altogether. I added in a fetch polyfill (whatwg-fetch 
> <https://github.com/github/fetch>) and run the HTTP call in JS.
>
> Here is a gist. 
> <https://gist.github.com/kspeakman/3653ae489c62c4d60c9ba9a9c19fd30b>
>
> *Notes*
>
> The JS fetch code could be generalized/improved even more, but this is all 
> I need for calling my own APIs. Once tweaked and running for its intended 
> use, it will rarely need to be touched.
>
> Outgoing ports start with 'api' so that the startup code knows to wire 
> them up. If Elm would let me, I would define only one outgoing port as `*port 
> apiRequest : Request a -> Cmd msg*`, but that doesn't compile.
>
> Overhead per API method is around 5 lines of code. One outgoing port, 2 
> incoming ports (1 success, 1 fail), and 2 for adding incoming ports to 
> subscriptions list.
>
> Most importantly, if my messages change, I only have 2 places to update 
> them: client model and server model. No encoder/decoder maintenance.
>
> Using strings to represent incoming ports is not ideal, but shouldn't need 
> that much maintenance and are private.
>
> Just starting to explore this, so maybe there is some blocking situation I 
> haven't discovered yet.
>
> On Tuesday, October 4, 2016 at 10:37:41 AM UTC-5, Vojtěch Král wrote:
>>
>> Awesome! I'll try it out...
>> Thanks!
>> Vojtech
>>
>> Dne úterý 4. října 2016 16:36:37 UTC+2 Kasey Speakman napsal(a):
>>>
>>> I haven't done this yet as we're developing the UI first as things take 
>>> shape and faking the API calls with Process.sleep + Task.perform. So below 
>>> is just a sketch.
>>>
>>> Conceptually, you could use `Http.getString` (or construct a request and 
>>> use `Http.send`) in Elm to get the JSON, then send that through a port to 
>>> JavaScript. You'd need at least one outgoing port, and an incoming port for 
>>> every result type.
>>>
>>> port deserializeJson : String -> String -> Cmd msg
>>>
>>>
>>> port studentsLoaded : (List Student -> msg) -> Sub msg
>>>
>>> port coursesLoaded : (List Course -> msg) -> Sub msg
>>>
>>>
>>> subscriptions : Model -> Sub Msg subscriptions model = Sub.batch [ 
>>> studentLoaded StudentsLoaded , courseLoaded CoursesLoaded ] 
>>>
>>>
>>> On the outgoing port, you could pass both the JSON and the incoming port 
>>> name as a string. Then in the JS, you could wire it once like this:
>>>
>>> app.ports.deserializeJson.subscribe(function(port, json) {
>>> // TODO can throw, so catch error and send to an error port
>>> var object = JSON.parse(json);
>>> app.ports[port].send(object);
>>> });
>>>
>>>
>>> Once you get the HTTP response string from a particular request, you 
>>> send it through the outgoing port with the correct return path.
>>>
>>> deserializeJson "studentLoaded" json
>>>
>>> It looks like after initial setup, each deserialization would take ~3 
>>> lines of wiring code. So it might not be worth it for small objects. But 
>>> again this is just a sketch that I haven't tried to run.
>>>
>>> On Tuesday, October 4, 2016 at 6:40:08 AM UTC-5, Vojtěch Král wrote:
>>>>
>>>> I have the same problem. Would someone be so kind as to give an example 
>>>> of how to launder the JSON via ports like this? Do you just rut the data 
>>>> through a port, or do you do ajax in JS?
>>>> 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] Re: Newbie - which build tool

[OvermindDL1]

Brunch is much older than webpack, one of the first javascript build 
systems.  Instead of specifying tasks everything is built via plugins, 
entirely concurrently and keeping things in memory as it is passed from 
thing to thing as it can, which makes it blazing fast (at work we have a 
few *thousand* javascript files totaling a few megs, it compiles it all in 
<4s flat.  Compared to one of the Elm apps, which elm takes over 40s to 
compile, which the elm source totals 290KB.  So Brunch can do all the elm 
and javascript simultaneously before bringing them all together, optimizing 
them, minifying, closure-compiling, etc..., whenever elm finishes that is. 
 ^.^

But yep, there are plugins for about anything for brunch, and dead simple 
to make your own as I've done.  You define a configuration for the plugins 
you use, there is no imperative declaration like grunt or so, just 
configuration, which makes it very simple.  I highly recommend brunch.

Brunch is also the distributed javascript asset build system for the 
Phoenix web server library as well, which is the fastest growing server out 
right now, of which they chose brunch for the reason of its fast 
compilation time so it can re-serve pages on the fly as files are edited.

Brunch plugins include not just compiling plugins but also has a web server 
plugin, where you can see file changes on the fly, a diff pusher, which 
sends updates to the files (css/javascript/whatever) to the embedded 
webserver plugin without needing a page reload, etc...


On Friday, October 28, 2016 at 9:24:13 AM UTC-6, Colin Yates wrote:
>
> Thanks OvermindDL1 - I did see a blog post about brunch but I kinda 
> skimmed over it as it didn't look that mainstream. Thanks again. 
>
> On 28 October 2016 at 16:21, OvermindDL1 > 
> wrote: 
> > I use brunch for all of the above except `executes any test`, of which I 
> > just use `npm test` for that.  Simple, significantly faster than webpack 
> > (though both will be bound by elm's slow compiling speed if that is all 
> it 
> > is really handling). 
> > 
> > 
> > On Friday, October 28, 2016 at 7:19:59 AM UTC-6, Colin Yates wrote: 
> >> 
> >> Hi, 
> >> 
> >> I have to get up to speed super-quick with Elm and so I want to stay as 
> >> mainstream as possible (yeah, I know it isn't 1.0 yet :-)). I am stuck 
> >> trying to decide on a build tool that: 
> >> 
> >>  - handles CSS (generating and compressing) 
> >>  - hot reload code in the browser so no refreshing 
> >>  - executes any tests 
> >>  - concatenates and optimises the JS 
> >> 
> >> Basically, my question is "leiningen is to Clojure as ___ is to 
> Elm" 
> >> :-). 
> >> 
> >> If the community had one voice, what would they fill in the blank? 
> >> 
> >> Thanks all. 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Elm Discuss" group. 
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/elm-discuss/7hEp70pIh98/unsubscribe. 
> > To unsubscribe from this group and all its topics, 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: Newbie - which build tool

[OvermindDL1]

I use brunch for all of the above except `executes any test`, of which I 
just use `npm test` for that.  Simple, significantly faster than webpack 
(though both will be bound by elm's slow compiling speed if that is all it 
is really handling).


On Friday, October 28, 2016 at 7:19:59 AM UTC-6, Colin Yates wrote:
>
> Hi,
>
> I have to get up to speed super-quick with Elm and so I want to stay as 
> mainstream as possible (yeah, I know it isn't 1.0 yet :-)). I am stuck 
> trying to decide on a build tool that:
>
>  - handles CSS (generating and compressing)
>  - hot reload code in the browser so no refreshing
>  - executes any tests
>  - concatenates and optimises the JS
>
> Basically, my question is "leiningen is to Clojure as ___ is to Elm" 
> :-).
>
> If the community had one voice, what would they fill in the blank?
>
> Thanks all.
>

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

[OvermindDL1]

That sounds like a typeclass or a HPT, neither of which are in Elm (yet?). 
 Passing in manual serialization/deserialization functions is easy to do 
though.  :-)

On Wednesday, October 26, 2016 at 10:32:18 AM UTC-6, Martin Cerny wrote:
>
> I think this points to a more general use case. I think it would be useful 
> to be able to use union types a bit like enums in other languages (my 
> background is mostly Java). For example having
>
>   type Role = Admin | Moderator | User
>
> it would be cool to get something like:
>
>   Role.optionNames == ["Admin", "Moderator", "User"]
>   Role.allOptions == [ Admin, Moderator, User ] 
>
> Now the 'allOptions' probably could work only when all type constructors 
> have the exact same parameters, but I think that use case is not infrequent 
> and having to define list of possible options manually is error-prone...
>
> The use case is not only for selects. You may for example need to show 
> counts of various types of objects displayed, where the type is given by an 
> enum, so iterating through the enum values makes sense.
>
> Just my $0.02.
>
> Martin
>
> On Wednesday, 26 October 2016 02:27:38 UTC+2, Ian Mackenzie wrote:
>>
>> 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.

[elm-discuss] Re: Is there any way to use a type instead of a string for the value of an option

[OvermindDL1]

`option` is supposed to match to the html , thus only strings, any 
marshalling you will need to perform yourself, such as by, for example, 
wrapping up option into something like `optionMyType t = option [ value 
(myTypeSerialize t) ]` or so for ease of use.  :-)


On Tuesday, October 25, 2016 at 6:45:26 AM UTC-6, 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.

[elm-discuss] Re: Pre-requisites for learning Elm?

[OvermindDL1]

That is a very good point, you can make a lot of cool things in pure elm, I 
whipped up an incremental clicker in an hour a few days ago when I was 
screwing around, dead simple.  ^.^


On Monday, October 24, 2016 at 4:44:53 PM UTC-6, joseph ni wrote:
>
> Hey Razi,
>
> That sounds great! I wish I was where you are now. In my first computing 
> course, I was expected to learn Haskell and assembly, we didn't have google 
> back then, nor wikipedia, blog sites, free online courses, and I was plenty 
> lost too.
>
> One of the most valuable experience that I got from uni was learning how 
> to be resourceful and learn things. Elm is a perfectly beginner friendly 
> language. It goes out of it's way to be beginner friendly. Don't let a lack 
> of html/css/js knowledge worry you. Get in there with a goal of what you 
> want to create and do it.
> Join the elm slack channel and ask for help in #help, #general, 
> #beginners, pick up a free html/css course over at khan academy, codeschool 
> etc..., ask a class mate about stuff you're confused about, approach your 
> prof and tell him/her your worries. All these resources are there, so start 
> using it!
>
> I started doing elm 6 months ago, in that time, I've built up to ~7000 
> lines in my game, it contains no javascript and the majority of the code 
> (~6500 lines) has nothing to do with html/css.
>
> Programming is about problem solving and creativity, Elm is an absolutely 
> fantastic language and you can't get much better than starting out with it 
> imo, so persist, give it your best and don't be afraid to try. See you on 
> elm slack ;)
>
> On Monday, 24 October 2016 08:22:22 UTC+11, Razi Syed wrote:
>>
>> Hi everyone, I've never programmed before and in my first year course 
>> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
>> does examples in class applying what he thinks we should have learned. 
>> Problem is, I'm totally lost. Some people are telling me you're supposed to 
>> know HTML and CSS before Elm. Even the official elm guide seems like it 
>> assumes you know HTML and CSS and javascript (note: I simply know the names 
>> of these languages and nothing about them), or have programmed in a 
>> non-functional programming.
>>
>

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

[elm-discuss] Re: Pre-requisites for learning Elm?

[OvermindDL1]

Elm is definitely a front-end language for javascript so it does assume at 
least a little prior experience, at least with html/css and how they work 
if not javascript (depending on what you need to do).  The class does not 
have those pre-requisites first?  Is it Elm specific or just a generic 
functional language of which you could pick another?


On Sunday, October 23, 2016 at 3:22:22 PM UTC-6, Razi Syed wrote:
>
> Hi everyone, I've never programmed before and in my first year course 
> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
> does examples in class applying what he thinks we should have learned. 
> Problem is, I'm totally lost. Some people are telling me you're supposed to 
> know HTML and CSS before Elm. Even the official elm guide seems like it 
> assumes you know HTML and CSS and javascript (note: I simply know the names 
> of these languages and nothing about them), or have programmed in a 
> non-functional programming.
>

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

[elm-discuss] Re: More on external "components"

[OvermindDL1]

Elm's VirtualDom has such a thing just for that: 
 
https://github.com/elm-lang/virtual-dom/blob/master/src/Native/VirtualDom.js#L88-L98

However, it is only accessible via 'native' code javascript, thus you'd 
have to make a native module, which if that is fine for you...

I also have no clue if it is 'official' api in any way, so unsure on its 
future-proofness.

Do note that it is very low level, you create the node and return it from 
`impl` based on the model data passed in to it, of which the VDom will 
mutate it further as necessary (or not at all if you do not put any 
mutations on if you want to handle it all yourself, so keep that in mind).


On Monday, March 28, 2016 at 5:37:58 PM UTC-6, Mark Hamburg wrote:
>
> A teammate and I have been working on integrating Dropzone.js into our Elm 
> page and while we've got it working — including updating to different URLs 
> for posting as the context changes in the model — the implementation isn't 
> exactly pretty. We ended up dependent on sending our JavaScript code a 
> tickle event via a port. This seems likely to either be noisy or to miss 
> things and if Elm were ever to decide to be somewhat lazy about rendering 
> and diffing HTML — e.g., only doing so if there are no pending actions — 
> then this could suffer from timing problems wherein the tick driven 
> JavaScript runs ahead of the actual tree update. There have been a number 
> of proposals that have floated past but they tend to feel complicated. 
> Having just gone through this, I'm trying to think through what the 
> simplest, reasonably general purpose boundary is that could be more robust 
> than just using tick to send data on a delay.
>
> What it feels like we need is a way to create a virtual DOM node type that 
> would create a div and invoke appropriate JavaScript code on it in 
> conjunction with doing the DOM update. Nodes that aren't leaves on the Elm 
> side or going to make the JavaScript side logic a lot more complex, so 
> let's focus on Elm leaves — i.e., nodes with no Elm-managed nodes 
> underneath them. There are three things that happen during updates to leaf 
> nodes. They get created, they get updated, and they get deleted from the 
> DOM.
>
> So, the code to run the Elm app could take a JavaScript function with the 
> signature: function( extensionClassName, eventName, divElement ) This 
> would receive a "class" name specified in Elm — possibly just the standard 
> HTML classname — an event name out of the following set: 
> "willInsertElement", "didUpdateElement", and "didDeleteElement", and the 
> div element. The hook code can then create or update the children within 
> this div node. Other actions like changing the attributes of the div node 
> or adding, removing, or moving it within the tree should be disallowed. 
> Note that I tried to set these events up so that run before the node is in 
> the tree or after it's been removed from insert and delete and the update 
> event comes after the node has been updated so that it only sees new 
> values. These seemed like the most "useful" choices but others may differ.
>
> In the case of Dropzone, I would have used these hooks as follows:
>
> willInsertElement: Create a child div that gets handed to the Dropzone 
> setup code and for which we track the upload target URL.
>
> didUpdateElement: If the upload target (indicated as an attribute of the 
> hook div) has changed, then remove any existing Dropzone child div and add 
> a new one. Note that in progress uploads can still continue and we can 
> cache the old one in case we switch back.
>
> didDeleteElement: If we're caching, any child Dropzone div can be moved 
> to the cache at this point.
>
> In Elm, I might have written something like hook [ class 
> "dropzone-container", action targetUrl ].
>
> The net effect of this would be that I can easily expose hook classes in 
> my JavaScript code and use them in my Elm code. They do all of their 
> communication for configuration via the standard virtual dom mechanism 
> without needing port hooks to trigger updates.
>
> Return data flow can probably just be via ports as it is right now though 
> I could see it being interesting to expose a standard return message 
> mechanism for hook nodes.
>
> Does this seem like a fruitful path to others who have explored this more 
> thoroughly than I and my team have?
>
> 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: How to preventDefault on keyup of a specific key?

[OvermindDL1]

On-going conversation about how to handle that (in my opinion an 
`onWithOptions` should not 'take' options but rather should return them 
along with the message as a tuple, but it does not function that way 
currently).  The current work-around is to use ports (register your event 
listener in javascript after an initial render then call back in to elm 
from the event callback via 'push').

On Friday, October 21, 2016 at 9:18:45 AM UTC-6, Jacky See wrote:
>
> In the js version of the code would look like
>
>
> el.addEventListener('keyup', function(ev){
> if(ev.keyCode == 32){
> ev.preventDefault();
> }
> });
>
>
> Can't seems to do that in current Html.Events.onWithOptions
>

-- 
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: Demo project that fails Google Closure Advanced Optimizations

[OvermindDL1]

I know it fails on our large Elm project at work, we have to run with 
standard optimizations of the Google Closure compiler, but I did not 
research in to far since generated code is not code that I control and I 
needed to get things done.  If I get time I'll try to run it again and get 
some data on it.


On Thursday, October 20, 2016 at 11:16:16 AM UTC-6, Robin Heggelund Hansen 
wrote:
>
> I was wondering if anyone had a project that fails to run properly when 
> applied with the Advanced Optimizations of the Google Closure Compiler?
> I want to figure out what the problems are so that I can submit a PRs to 
> fix the problem.
> Pretty sure I've figured out what the problems are, but I need to 
> replicate my success on larger projects than the few test cases I've made.
>

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

Re: [elm-discuss] Proposal: Rename case..of -> match..with

[OvermindDL1]

On Thursday, October 20, 2016 at 8:46:42 AM UTC-6, Peter Damoc wrote:
>
> On Thu, Oct 20, 2016 at 5:06 PM, Robin Heggelund Hansen <
> skinn...@gmail.com > wrote:
>
>> The proposal, as the title of the post suggests, is to rename the 
>> "case..of" expression to "match..with". 
>>
>
> One added benefit that I'm seeing is that today, if I would have to 
> describe "case...of", I would use the words "pattern matching". :) 
>
> I wonder if this has been discussed before.  I did a quick search but 
> nothing jumped out as relevant. 
>
> > case..of to match..with renaming could be handled by elm-format.
>
> in theory, yes, it could be handled by a tool like elm-format but in 
> practice, in order for it to be effective, it should be handled by 
> something that is part of the elm-platform. 
> this kind of a mechanical replacement would be OK if it would be handled 
> right away and in an official manner. 
> requiring installing extra tools that come with alpha warnings might be 
> scary. 
>

If this were done (plenty of other precedence, OCaml uses `match ... with` 
too), there could be a deprecation period where both are supported and 
`case ... of` generated deprecation warnings... 

-- 
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: Metalinguistic abstractions over databases

[OvermindDL1]

On Thursday, October 20, 2016 at 3:55:45 AM UTC-6, Rupert Smith wrote:
>
> On Wednesday, October 19, 2016 at 8:23:46 PM UTC+1, OvermindDL1 wrote: 
>>
>> Absinthe handles all the nasty parts of GraphQL though, the combining of 
>> queries, the real-time type documentation generation, etc... etc...
>>
>
> What database do you use? Is it always a SQL database or can Absinthe work 
> with noSQL too?
>
> Also, when it combines queries, does it translate that down into an 
> efficient SQL join? Or does it process the joins outside of the database, 
> in the server code? 
>

It is storage agnostic, and technically you do not even need a storage, 
remember that GraphQL calls are basically just RPC, you could have a `fib` 
GraphQL call that just calculates that.

The database I use is PostgreSQL via the Ecto library though.  Absinthe is 
database and all agnostic, however it does have a section at 
http://absinthe-graphql.org/guides/ecto-best-practices/ talking about the 
best ways to use it with ecto for optimization purposes, and they do have 
planned more detailed ecto integration in the future, but for now it is 
do-it-yourself (which I prefer, means I can use my permission system to 
only return specific things that they have access to).  Absinthe itself 
does not combine queries, it has no clue what a query is, it just gives the 
graphql 'function call' setup to you, what the user requested, what they 
passed in, etc...  With proper Ecto work all the joins are in-database. 
 With ecto it is trivial to build up database joins in piecemeal, so it 
works fantastically with graphql.

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

[OvermindDL1]

On Wednesday, October 19, 2016 at 7:39:25 PM UTC-6, Nathan Schultz wrote:
>
> Primes I'll miss for convenience, like when naming an inner tail-recursion 
> function to distinguish it from its wrapper. But it's not a big deal.
>

The convention for that in a few other languages is the name 'aux', such as 
in this copy/paste, perhaps that same convention could be brought in for 
that purpose?

  let rle list =
let rec aux count acc = function
  | [] -> [] (* Can only be reached if original list is empty *)
  | [x] -> (x, count + 1) :: acc
  | a :: (b :: _ as t) ->
 if a = b then aux (count + 1) acc t
 else aux 0 ((a, count + 1) :: acc) t  in aux 0 [] list 

-- 
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] OT: Elm Style formatting for other languages?

[OvermindDL1]

On Wednesday, October 19, 2016 at 10:58:17 AM UTC-6, Peter Damoc wrote:
>
> On Wed, Oct 19, 2016 at 3:02 PM, John Orford  > wrote:
>
>> Commas beginning lines etc.
>>
>> Perhaps not idiomatic in Python or JS, but new good ideas rarely are : )
>>
>>
> I think I've answered too quickly in the previous reply. 
>
> Commas beginning lines looks weird to a lot of people glancing at elm. 
> We got used to them and, as with status quo in general, one can find 
> reasons to keep it. 
>
> I would much rather have the compiler accept trailing comas and elm-format 
> inserting them automatically when spreading a list/record on multiple lines.
>

That is what I'd prefer as well.  An example, all of this is valid OCaml 
code for a record:
```ocaml
type myRecord = {
  i : int;
  s : string
}

type myRecord = {
  i : int;
  s : string;
}

type myRecord =
{
  i : int;
  s : string
}

type myRecord =
{ i : int;
  s : string
}

type myRecord =
{ i : int;
  s : string }

type myRecord =
{ i : int
; s : string
}
```
Though as you note, no pre-;'s are allowed, but trailing are.  For 
Variants/Unions:
```ocaml
type myUnion = Something | AnotherThing

type myUnion =
  Something | AnotherThing

type myUnion =
Something
  | AnotherThing

type myUnion
  = Something
  | AnotherThing

type myUnion =
  | Something
  | AnotherThing
```
The | can have a prefix one, but not a trailing one.  Personally I always 
use the bottom style unless I am just wrapping up a type into a new type to 
make sure I do not mis-use it, like by doing:
```ocaml
type systemID = SystemID of string
```

However, elm is trying to minimize the possible ways to represent 
something, if you can already do something one way then do not add in 
another way (I'm still not a fan of `.field` style record accessors, maybe 
a Lens or so to be able to get/set/update, but eh), and early/trailing 
things are such superfluous things technically.

-- 
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: Metalinguistic abstractions over databases

[OvermindDL1]

On Wednesday, October 19, 2016 at 9:58:07 AM UTC-6, Rupert Smith wrote:
>
> On Wednesday, October 19, 2016 at 4:39:00 PM UTC+1, OvermindDL1 wrote:
>>
>> I've been using absinthe on the server side and I am able to control 
>> access permissions quite well for GraphQL hosting, though I am using a 
>> custom permission library that ties to our local LDAP server so that code 
>> would not be generically useful to release.
>>
>
> Sounds interesting. Is hooking custom permissions into graphql part of the 
> graphql spec? Or is it some mechanism specific to absinthe that lets you do 
> this?
>

The Elixir language (which Absinthe is built for and of which I use on the 
back-end) has a very powerful hygienic macro system.  With absinthe you 
define (taking these examples from the manual examples) a 'schema', which 
is an endpoint that can be queried, a specific graphql command in other 
words.  An example would be this:
```elixir

@desc "An item"object :item do
  field :id, :id
  field :name, :stringend

 ```
This as it is does nothing as no action ('query') bound to it yet, this is 
just the data structure and the types (of which you can define your own 
types, use other objects, etc...), but we can bind such a query like:
```elixir

  query do
field :item, :item do
  arg :id, non_null(:id)
  resolve fn %{id: item_id}, _ ->
{:ok, @items[item_id]}
  end
end
  end

```
This defines a query that lets a client query by 'id' and only an 'id', 
which must not be null.  The resolve function in this case is what will do 
the actual database look up (in this example it is just returning a static 
data element or 'nil' if it does not exist).  This resolve function is 
where I put my access control.  My access control works by adding this kind 
of thing into where-ever I want to enforce a permission (which I can make 
as fine or coarse-grained as I want, the permission system is very finely 
grained):
```elixir

@perm true = user |> can?(select(%Perms.WhateverPerm{id: id}))

```
Where user would be passed in the 'context' of the map passed in to the 
resolve function (detailed at http://absinthe-graphql.org/guides/context/ 
for note).

Absinthe handles all the nasty parts of GraphQL though, the combining of 
queries, the real-time type documentation generation, etc... etc...


On Wednesday, October 19, 2016 at 9:58:07 AM UTC-6, Rupert Smith wrote: 

> Also, is graphql just for fetching data? Or it also allows you to create 
> new data on the server, or make updates to existing data?
>

Nope, you can query for (and only get back what you request, like if an 
'object' has 3 fields but the client only asks for 1 of them, you get that 
information in the resolver so you can optimize the DB queries 
accordingly), you can insert new things (if they fulfill your 
requirements/authorization/etc...), update things, delete things, etc... 
 Or anything else.  Technically a GraphQL 'command' is just like a function 
call where the arguments are well typed and defined and the return value is 
configurable based on the input, it is basically just RPC but a bit more 
optimized and self-documenting, and as such the 'functions'/queries can do 
whatever you want.


On Wednesday, October 19, 2016 at 9:58:07 AM UTC-6, Rupert Smith wrote:  

> But yes, I am a fan of GraphQL.  I just expose 'functionality', not raw 
>> tables.  Many of my GraphQL calls do not map to a database table but rather 
>> potentially multiple (or even none in some cases).
>>
>
> Yes, I also do not expose raw tables in the API, each entity is typically 
> a small document tree which maps to >1 table. Also depending on what you 
> fetch and what condition you use to filter the query results I would expect 
> hitting >1 table to be quite common.
>

Indeed, I have a caching system that caches immutable DB queries across 
servers (of which I try to design the DB to use as many immutable rows as 
possible, lots of SELECT and INSERT, few if any UPDATE's).

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

Re: [elm-discuss] How to write function that updates arbitrary element of a record

[OvermindDL1]

For note, if you are updating the view with the content, so if a person 
types "1w" then you do not store the update so it is still just "1" and you 
update the input with that so it becomes 1 as well, then a warning that 
sometimes the cursor jumps to the start when the user types fast.  Not an 
elm or vdom bug, just the way the actual DOM works.  You can fudge around 
it by only setting a value when an 'error' happened in the input and/or if 
using html5 just put a 'pattern'  and 'required' attribute (then with 
proper css you can even have it auto-turn red if they type invalid input or 
so), although it still lets them type it, just forms cannot be submitted, 
if it is in a form.

On Wednesday, October 19, 2016 at 9:18:54 AM UTC-6, Brian Marick wrote:
>
> I see I left out a required argument from what I want, which leads me to 
> this: 
>
>
> update : Msg -> Model -> Model 
> update msg model = 
>   case msg of 
> ChangedDripText string -> 
>   updateWhen model isValidFloatString dripText string 
> ChangedHoursText string -> 
>   updateWhen model isValidIntString simulationHoursText string 
> ChangedMinutesText string -> 
>   updateWhen model isValidIntString simulationMinutesText string 
> 
> dripText model val = 
>   { model | dripText = val } 
> simulationHoursText model val = 
>   { model | simulationHoursText = val } 
> simulationMinutesText model val = 
>   { model | simulationMinutesText = val } 
> 
> updateWhen : Model -> (String -> Bool) -> (Model -> String -> Model) 
> -> String -> Model 
> updateWhen model pred updater candidate = 
>   if pred candidate then 
> updater model candidate 
>   else 
> model 
> 
>
>
> … which is OK, but doesn’t take me to my happy place. 

-- 
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: OT: Elm Style formatting for other languages?

[OvermindDL1]

Not uncommon in many functional languages.  I've seen it done in Haskell 
and OCaml as a couple of examples that pop straight to mind.


On Wednesday, October 19, 2016 at 6:02:19 AM UTC-6, John Orford wrote:
>
> The standard elm code style is v nice - anyone know whether you can 
> /similar/ styles to use with auto-formatters for other languages? I.e. very 
> spread out, with no aversion to adding to LOC counts : ) Commas beginning 
> lines etc.
>
> Perhaps not idiomatic in Python or JS, but new good ideas rarely are : )
>

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

[elm-discuss] Re: Metalinguistic abstractions over databases

[OvermindDL1]

I've been using absinthe on the server side and I am able to control access 
permissions quite well for GraphQL hosting, though I am using a custom 
permission library that ties to our local LDAP server so that code would 
not be generically useful to release.

But yes, I am a fan of GraphQL.  I just expose 'functionality', not raw 
tables.  Many of my GraphQL calls do not map to a database table but rather 
potentially multiple (or even none in some cases).


On Wednesday, October 19, 2016 at 5:29:08 AM UTC-6, Rupert Smith wrote:
>
> On Wednesday, October 19, 2016 at 9:54:44 AM UTC+1, Peter Damoc wrote:
>>
>> *The problem *
>>
>> I know how to implement a REST API and interrogate that API from Elm but 
>> that *seams very low level. *
>>
>> I was curious about a language abstraction that would isolate my Elm 
>> program from the actual database strategy.  
>>
>> How do you approach dealing with the databases? What is your strategy? 
>> What options are there?
>> Do you have any pointers to interesting perspective/approaches?
>>
>
> Interesting that you jump straight from 'REST API' to 'database'. You can 
> map database CRUD operations straight onto REST POST, GET, UPDATE, DELETE 
> operations, it is true. Many APIs even if they do not expose all of CRUD 
> through REST in this way, often have a trace of it in the API since the 
> mapping is an obvious one. However, there is more to APIs than CRUD, and in 
> many situations CRUD is not what you want for an API at all.
>
> Here are some examples to illustrate.
>
> Suppose I have an API that lets a user create a profile, modify their 
> profile as they see fit, use their profile to access some applications, and 
> if they choose to, delete their profile permanently. This fits naturally to 
> a CRUD mapping of the profile.
>
> Suppose I have an API for a bank account. The user cannot simply make 
> changes to their account, they must always do so by requesting balancing 
> transactions. So take some money from my account, and put it in another 
> account. This does not map to CRUD on accounts at all, the API will 
> describe a carefully chosen set of transactions that the user can fill in 
> and request to have processed.
>
> CRUD on single tables does not necessarily make a good API, as tables can 
> be too small a fragment to deal with at the API level. Suppose in my 
> profile example, that the profile has a list of email addresses in it, one 
> of which is marked 'active'. There will be at least 1 profile table with a 
> 1-to-many to the email addresses table. When I fetch the profile, I likely 
> also want to fetch all the emails at the same time. The profile is what I 
> call a 'slice' of data and it corresponds to a little document model. You 
> could equally well store this document model in a non-relational database 
> as json, say on MongoDB for example.
>
> This is often how I think when designing APIs - what are the slices that 
> the consumer needs to be able to work with to get the level of abstraction 
> right. Having designed a data model and considered its slicing, I produce a 
> CRUD API (+ finders) but at the level of abstraction of the slices. Later 
> on, I then tidy this up by removing operations that should not be exposed 
> in the API, say I don't want the delete operation for example. Or sometimes 
> I remove the whole CRUD API for a certain class of entities, like the bank 
> accoutn example, as a more transactional style API will be used instead.
>
> 'graphql' looks very interesting. I had a wee look after the recend post 
> about an Elm client for it. Remember you will need a graphql implementation 
> on the server though. And that for some situations, graphql might not be 
> appropriate. As in the bank account example, you don't necessarily want the 
> consumer to be able to freely navigate the whole graph of your data model, 
> certain parts might require more restricted access.
>
> Actually, I was thinking I'd like to look into graphql more deeply at some 
> point. It essentially provides a way for the consumer of an API to 
> dynamically specify the 'slice' that they want. It could also be used 
> purely on the server side as a way of defining slices but exposing them as 
> particular end points for a particular slice. Like:
>
> GET /api/profile//summary - Gets just some of the profile data.
> GET /api/profile/ - Get the full profile
>
>
> Would be easy to do, if my server code let me set up these end points by 
> writing them as graphql queries and automatically map that onto whatever 
> underlying database technology I am using. I have no idea where we are at 
> for good server side libraries for doing 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: Standard practices for dynamic extension/plugins in Elm?

[OvermindDL1]

On Monday, October 17, 2016 at 6:07:45 PM UTC-6, Mario T. Lanza wrote:
>
> 1) due-dates: installing and activating this plugin causes a due date 
> field to be added to the Todo model.  The interface still provides only the 
> text input field for providing the next "What needs to be done?" entry.  In 
> the list portion of the view a due date column appears.  When the user 
> types in an @ followed by a date (e.g. @2016-11-01) the value is parsed out 
> of the text and included in the due date field in the list below.
>

Given that the plugin data has to reside somewhere, I'd probably add a set 
of plugin storages to the record, one for each possible plugin that may be 
enabled (you cannot generically store data in Elm due to lack of various 
features like HKT's, HPT's, polymorphic variants, etc...  Everything in elm 
is designed to be visible not hidden, thus you have to know all types ahead 
of time).  Each plugin data storage could easily be an option so it is 
either Nothing or Just depending on if enabled or disabled (since you said 
you do not care about storing it somewhere).

For the view you could go two ways, either just test for validity of each 
and display data depending in the view, very hard-coded, but also very 
Elm'y, or you could generate a set of record hooks depending on the plugin 
states and pass those around the view to call the right hooks at the right 
time, this is more generic and multiple plugins could be supported with 
ease, but you still have to store the model of each individually without a 
few more language features.
 

On Monday, October 17, 2016 at 6:07:45 PM UTC-6, Mario T. Lanza wrote: 

> 2) tags: installing and activating this plugin causes a tags field to be 
> added to the Todo model.  The interface still provides only the text input 
> field for providing the next "What needs to be done?" entry.  In the list 
> portion of the view a tags column appears.  When the user types in a # 
> followed by a contiguous word or group of words (e.g. #finance #2016-taxes) 
> the values are parsed out of the text and included in the tags field in the 
> list below. 
>
 
>
When a plugin is deactivated the columns are simply dropped from the model. 
>  I am not worried about persistence. 
> 
>

Basically doing what I suggested above should work, verbose and explicit, 
but it works and is obvious to readers of the code too.

-- 
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: Offtopic Choo Framework

[OvermindDL1]

Cool little library, but the main thing that makes me use Elm is not TEA, 
but rather the functional language.  Having types removes entire classes of 
bugs and immutability makes it easy to reason about a program flow.  It is 
just too easy to break both of those aspects in Javascript, even with 
layers on top.


On Monday, October 17, 2016 at 10:09:27 AM UTC-6, António Ramos wrote:
>
> Hello guys just trying to learm Elm but its not easy.
> I just found this js framework
>
> https://github.com/yoshuawuyts/choo
>
> i has the same concept as TEA
>
> subscriptions , model, update and messages
>
> Maybe i just learn it too, because i just feel that going back to 
> angular/react/vue is giving up in good and simple  ideas from ELM
>
>
> Regards
> António
>

-- 
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: Catching error in fullscreen/App.programWithFlags

[OvermindDL1]

You will not be able to do that as Elm has its own scheduler that uses 
`setTimeout(0, ...)` to do the event loops, including the very first init, 
and that errors causes that event loop to die.  I'd probably recommend 
changing your flags to handle this case differently or you might be able to 
do it by setting up a port and messaging into it and maybe seeing if the 
port exists (if it does not exist it all then the app may not have loaded, 
I've not tested this to see 'when' the ports are setup in the setup but you 
could always have the program message back 'out' if it was successful, 
though I'd go with changing how the data is passed in).

On Saturday, October 15, 2016 at 11:20:11 AM UTC-6, Kevin Berridge wrote:
>
> I'm using App.programWithFlags to initialize the state of my model from 
> local storage (as described in this blog article 
> ).
>  
>  But when the schema of my model changes (ex: I added a new field to a 
> record type) it will correctly error out when Elm.Main.fullscreen is called 
> with error: "You are trying to initialize module `Main` with an unexpected 
> argument."
>
> I am OK with throwing away the state from local storage and starting from 
> scratch when this happens, so I tried to add a try catch in the JavaScript 
> but surprisingly (to me) the catch doesn't fire.
>
> try {
> elmApp = Elm.Main.fullscreen(startingState);
> }
> catch (e) {
> elmApp = Elm.Main.fullscreen(null); // this never gets called
> }
>
> Is there a way that I can catch this error?  Or do I need to use a 
> different approach?
>
> Thanks,
> Kevin
>

-- 
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: Html.Keyed

[OvermindDL1]

On Wednesday, October 12, 2016 at 5:32:09 AM UTC-6, Max Froumentin wrote:
>
> Thanks OvermindDL1, that's very helpful. I now understand it's down to the 
> lack of two-way binding. Makes sense.
> Wouldn't it be useful to use a change of id attribute as a change of key?
>

Yep, adding an attribute ID of some sort would make that 'more expected', 
and some vdom libraries do indeed do that (that I could link you to if you 
are curious at seeing the implementation).  :-) 

On Wednesday, October 12, 2016 at 9:59:47 AM UTC-6, Mark Hamburg wrote:
>
> On Oct 11, 2016, at 1:09 PM, OvermindDL1  wrote: 
> > 
> > And as for cocoa, unlike the DOM anytime something like, say a checkbox 
> is checked, cocoa sends a message to the application to handle the change, 
> if unhandled then no update would happen... and the app would be frozen as 
> the event loop would not be processing, unlike the DOM in a browser that 
> would just keep on puttering along even if no handlers for any events were 
> registered in javascript at all.  They are entirely different programming 
> domains. 
>
> Actually, no, with respect to Cocoa. If a Cocoa view sends out a message 
> that the value changed, the controller is not required or even expected to 
> echo that change back. The message can disappear into the aether and the 
> state will remain. (Caveat: It's been a while since I've coded against the 
> Cocoa APIs.) So, it is essentially an identical situation of there being 
> extra state that is tied to the existence of a Cocoa view object or a DOM 
> element.


This is indeed true that you do not need to handle it, however you still 
need to `pump` the message loop so, in elm terminology, it gets processed 
to the right effect manager (in reality when the message loop gets pumped 
anything listening to the messages can react as you wish, but you yourself 
still have to pump it, although that code is generally already set up for 
you via the normal scaffolds, but it is very explicit where elm is more 
implicit and magical). 

On Thursday, October 13, 2016 at 2:20:36 PM UTC-6, Rupert Smith wrote:

By making it keyed then it is like "oh, these do not match at all, probably 
> a major structural change, kill the old, create the new".
>

I have to admit I am not really sure how Html.Keyed works, so this is an 
illuminating discussion for me. Could you answer some basic questions about 
it for me?

If the 'key' of a keyed node is the same, is it never updated?
If 'key' of a keyed node changes, is the whole node built anew?

Or something else, please explain it to me, thanks.


In Elm if a 'keyed node'  is changed then it will diff as normal.  If a 
keyed node has an ID change then it tests the node before and after in the 
old version and shuffles around as necessary (only 1 at a time, larger 
jumps cause destroy/recreations), and if none nearby match then it entirely 
destroys or creates it as necessary.  I went a different route with my VDom 
but I'm still unsure about my style, though it does work well and gets rid 
of the keyed node and lazy node concepts in a larger singular super-node 
thing...

On Thursday, October 13, 2016 at 2:23:04 PM UTC-6, Rupert Smith wrote:

Some other questions relating to this.

I have a node that I changed an Html.Attribute.property on. The node had 2 
properties, but I only changed one. However, the node as a webcomponent 
fired triggered an observer on the other property that was not changed.

If I change just one property of a node, are all properties updated?

What about atttributes, if I change one attribute are all updated?


Uh, it should not do that I would think, sounds like a bug as an un-touched 
attribute should not be touched.  Unsure if Elm or the 
webcomponent-library-that-you-are-using kind of bug, but it sounds like a 
bug (I'd wager in the webcomponent polyfill you are using most likely, does 
sound weird...).

-- 
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: Pure Elm contenteditable rich text editor

[OvermindDL1]

This is also what I do for a CMS'ish style of interface in something at 
work, using elm-markdown to render a real-time view of what is being 
created.

Even pre-markdown back in decades past I still opted two have two panes, 
one where (at the time) html was put in, and the other showing the rendered 
html (in pseudo-realtime at the time, a refreshing frame, bleh).  You have 
no sudden jerks or disconnects or something unexpected unlike a WYSIWYG 
style (which I utterly *abhor* due to how many issues pretty much all of 
them have).


On Tuesday, October 11, 2016 at 1:49:53 PM UTC-6, Rolf Sievers wrote:
>
> If your users understand markdown, you could use markdown input and maybe 
> even render a preview.
>
> This is what I am doing for a project of mine. (This of course circumvents 
> the problem of writing a rich text editor but might help with your original 
> problem.)
>
> Am Montag, 10. Oktober 2016 22:42:49 UTC+2 schrieb Bulat Shamsutdinov:
>>
>> Hello!
>>
>> I have aside project which I really want to write in Elm. That project 
>> needs rich text edit (nothing fancy, just bullets and text styles).
>>
>> To my knowledge there is no solution to that task in Elm (which is a 
>> bummer). And even ports require nasty hacks (according to previous 
>> discussions here)
>>
>> Is there a way to implement that basic functionality using only Elm? 
>>
>>- Is it technically possible at the moment?
>>- What approach would you suggest?
>>
>>

-- 
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: Html.Keyed

[OvermindDL1]

Eh, not really, it is precisely the same issues as you would have with, for 
example, React, or any of the other JS libraries that use virtual-doms. 
 Just an aspect of how web browser DOM's are made due to backwards 
compatibility with a lot of old sites over a period of many many decades. 
 Have to know about the platform that is being programmed for is all, this 
is not Elm specific.  :-)

Remember, it is just a diffing algorithm, when it gets to that point of 
your vdom and it compares an old vdom node of, for example:
```
  checkbox [ onClick (CheckToggle 42) ] [ text "Something" ]
```
and compares it to the new of:
```
  checkbox [ onClick (CheckToggle 43) ] [ text "Another thing" ]
```
It sees that there are two changes (well potentially 1 due to lack of keyed 
event handlers, but we'll say 2 for this example), thus it accesses the 
checkbox at the index that it is at here (say, 14 or so) by just something 
like `var node = curNode.children[14];` then just applies the two changes 
`node.removeEventHandler("click", 
oldEvent); node.addEventHandler("click", newEvent); 
node.children[0].nodeValue = "Another thing";`, which was just removing the 
old event handler, adding the new, and mutating the text.  Notice that it 
did not set the checked value because you never said what the checked value 
should be (thus meaning there was no difference in your defined checked 
state, thus it just leaves it at whatever it was since it sees no change to 
apply).

By making it keyed then it is like "oh, these do not match at all, probably 
a major structural change, kill the old, create the new".

If instead it did, as you imply, the deleting of the checkbox and 
recreating it so it has a consistent state regardless, then that would be 
an absolutely monstrous amount of DOM manipulating for, say, just a tiny 
text change, thus entirely defeating the point of a differencing system 
like a virtual dom (of which the sole purpose of is for speed), while also 
causing things like the checkbox to uncheck any time anything near its 
point on the DOM changed even by a single character in a text node.  :-)

If, however, you defined what the checked state should be in the vdom, then 
it would see that the old was checked, and the new was not, and would 
remove that property of it.  :-)


And as for cocoa, unlike the DOM anytime something like, say a checkbox is 
checked, cocoa sends a message to the application to handle the change, if 
unhandled then no update would happen... and the app would be frozen as the 
event loop would not be processing, unlike the DOM in a browser that would 
just keep on puttering along even if no handlers for any events were 
registered in javascript at all.  They are entirely different programming 
domains.

Some setups, like Angular 1, used two-way binding to overcome these issues, 
so the DOM could be reflected back in to the data model, however that is 
both hard to model and incurs significant speed hits based on access 
patterns (hence why Angular 2 got rid of it as I recall, though not messed 
with it to know for sure).


On Tuesday, October 11, 2016 at 1:33:38 PM UTC-6, Mark Hamburg wrote:
>
> I haven't yet dug into the actual example code, but this response goes 
> straight to the issue of continuity of identity that makes things like web 
> components an interesting problem for a functional virtual DOM.
>
> Mark
>
> P.S. I prototyped a system a few years ago on Cocoa in which view creation 
> was explicit — thereby providing identity — but property updates after 
> creation all came from reactive signals. It worked pretty well but took 
> more thought to use than does Elm's "just re-render the tree as you want 
> it" approach. What we're seeing here is that without identity — or with 
> erroneous identity — the diff the vdoms approach can have its own serious 
> surprises.
>
> On Oct 11, 2016, at 10:11 AM, OvermindDL1  > wrote:
>
> The ticked checkbox is because the user ticked it, it is some of the 
> implicit DOM state.  When the view changed to remove a checkbox but it 
> still had another one after, since they were not keyed it just did a 'diff' 
> between states.  The vdom has no information on any implicit state in the 
> actual DOM, in fact it does not access the actual DOM at all except to 
> apply patches, thus when it saw from its point of view that the checkbox 
> label had its name changed but nothing else different about it then it sent 
> a patch to change the text and that is all.  By changing the 'key' of it 
> then it knows that it is an entire tree change and will not even attempt a 
> patch but will instead rather re-generate the entire tree.
>
> Basically if a tree were to be regenerated just because some text changed 
> than that would make a virtual-dom ex

Re: [elm-discuss] Re: How important is Html.Lazy to performance?

[OvermindDL1]

Specifically the server sent a list of records over websocket one at a time 
(at times a *lot* of records), those were stored pretty much verbatim in 
the model.
I had a field on the model that was just an Int, started at 0, the view 
rendered the list of those records (just one part of the interface, though 
the largest, and just read-only) behind a lazy call that was just passed 
that integer, so the first render rendered it empty (technically a 
'loading' indicator if the integer was 0) and I received the records from 
the server until it stopped, once I got the last record then I just 
incremented it to 1 (I put it behind another message so I could just send 
that one message from anywhere to update that view).  Any time the server 
pushed a record update (remove/add/etc..) then I just kept incrementing the 
integer.  It was a perfectly suited method for my use-case, though it would 
be harder to do if it handled any user inputs and such (though still 
doable).

I had a similar setup in another elm app later but instead of using lazy I 
made my ProgramEx library, which added a `filter` callback so that I can 
just outright turn off view updating entirely for certain messages (as well 
as transforming messages, update other TEA things, etc..., filter was 
useful) and I just never ended up using lazy as keyed was perfect enough 
for most efficiency reasons (lazy could still be useful if the list got 
utterly huge though, but not for the new case).


On Tuesday, October 11, 2016 at 11:52:35 AM UTC-6, Mark Hamburg wrote:
>
> Interesting. I can understand using a sentinel to force re-rendering but 
> I'm curious as to how your model or view was structured such that it could 
> inhibit re-rendering via laziness.
>
> Mark
>
> On Oct 11, 2016, at 8:42 AM, OvermindDL1 > 
> wrote:
>
> Personally I've known it to help very little (keyed is usually more 
> appropriate), but there have been a few times where it saves significant 
> processing, but at those places I ended up setting it up with a 'sentry' 
> value in a model (just an integer) that I incremented every time I wanted 
> that lazy view to be re-rendered.  This was highly useful when I was 
> getting streamed a *ton* of data from a server over websocket that was 
> being placed all kinds of randomly into a keyed list (see keyed!), but this 
> was causing significant flickering and such until it was done, so I just 
> basically 'turned off' the rendering with lazy via the sentinel until I got 
> the last message.  That kept the model flat and lets my finely control when 
> I want the view to update.  I've not heard of others using it like this yet 
> and I'm unsure if it is well accepted, but I do not really use it for 
> 'optimization' per-say (the vdom is really plenty fast, and again use keyed 
> nodes when possible), but rather I used it as a better method of 
> controlling when the view is actually updated.
>
>
> On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote:
>>
>> I was looking back at our first "big" (as in not the tiniest of toys) Elm 
>> app and at its tendency to factor the model based on the view hierarchy. 
>> This had struck me as a dubious pattern at the time and there is a strong 
>> argument voiced by some that one should just stay flat as long as possible. 
>> But why had we done it this way? Some of it certainly stemmed from the 
>> emphasis in the TEA documentation at the time on how one can nest 
>> model-update-view-message quads. But another part stemmed from wanting to 
>> use Html.Lazy fairly aggressively. That desire also led to more logic that 
>> tried to avoid generating new values when existing values would do. 
>>
>> So, my question in retrospect is: How important is using Html.Lazy to 
>> performance? Is it something one should put in at obvious break points 
>> where there are expected to be large subtrees? Is it something that should 
>> be used close to the leaves with the internal tree largely left non-lazy? 
>> Is it something that you ignore until it seems like things aren't fast 
>> enough and then start trying to contort your model and view to make lazy 
>> work? 
>>
>> My expectation from years of development is that on performance issues, 
>> one shouldn't go putting in more complicated code for problems that aren't 
>> yet known to exist — e.g., just sprinkling in laziness everywhere — but one 
>> should plan for what one would do if performance became a problem — e.g., 
>> if this were an issue, we could make it lazy right here. Lots of people 
>> adhere to the first principle citing concerns over "premature optimization" 
>> but the second principle tends to

[elm-discuss] Re: Html.Keyed

[OvermindDL1]

The ticked checkbox is because the user ticked it, it is some of the 
implicit DOM state.  When the view changed to remove a checkbox but it 
still had another one after, since they were not keyed it just did a 'diff' 
between states.  The vdom has no information on any implicit state in the 
actual DOM, in fact it does not access the actual DOM at all except to 
apply patches, thus when it saw from its point of view that the checkbox 
label had its name changed but nothing else different about it then it sent 
a patch to change the text and that is all.  By changing the 'key' of it 
then it knows that it is an entire tree change and will not even attempt a 
patch but will instead rather re-generate the entire tree.

Basically if a tree were to be regenerated just because some text changed 
than that would make a virtual-dom extremely slow, its whole point is only 
to generate a set of differences between two virtual-doms and apply those 
differences to the real dom without ever reading anything from the real dom 
(as that is very slow).

It would indeed be preferable for checked-state to be controlled 
exclusively via the model and view, however only an event is sent for those 
changes and there is no way for the vdom to update its internal information 
otherwise, and registering an event everywhere, even bubbled events, would 
again make the vdom very slow and force the user to have to handle a lot of 
extra cases (imagine checked state, text values, even focus and all being 
controlled like this).


On Tuesday, October 11, 2016 at 11:01:57 AM UTC-6, Max Froumentin wrote:
>
> Hi there,
>
> Today I raised https://github.com/elm-lang/virtual-dom/issues/37
> Given there's no consensus on whether it's a bug, I'm bringing the 
> discussion here.
>
> The reason why I think it's a bug is that the second time the view 
> function runs it generates a ticked checkbox, although nowhere in the view 
> function is there any indication that a ticked checkbox should be generated.
>
> The alternative view is that the checkbox that's been clicked on has only 
> been mutated with new data. That's why it remains ticked. You need to use 
> Html.Keyed to tell elm that it is an entirely new checkbox.
>
> I must say I'm not convinced why the view function should generate Html 
> that depends on the previous state of the model.
>
> Thanks for any insight.
>
>

-- 
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 important is Html.Lazy to performance?

[OvermindDL1]

Personally I've known it to help very little (keyed is usually more 
appropriate), but there have been a few times where it saves significant 
processing, but at those places I ended up setting it up with a 'sentry' 
value in a model (just an integer) that I incremented every time I wanted 
that lazy view to be re-rendered.  This was highly useful when I was 
getting streamed a *ton* of data from a server over websocket that was 
being placed all kinds of randomly into a keyed list (see keyed!), but this 
was causing significant flickering and such until it was done, so I just 
basically 'turned off' the rendering with lazy via the sentinel until I got 
the last message.  That kept the model flat and lets my finely control when 
I want the view to update.  I've not heard of others using it like this yet 
and I'm unsure if it is well accepted, but I do not really use it for 
'optimization' per-say (the vdom is really plenty fast, and again use keyed 
nodes when possible), but rather I used it as a better method of 
controlling when the view is actually updated.


On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote:
>
> I was looking back at our first "big" (as in not the tiniest of toys) Elm 
> app and at its tendency to factor the model based on the view hierarchy. 
> This had struck me as a dubious pattern at the time and there is a strong 
> argument voiced by some that one should just stay flat as long as possible. 
> But why had we done it this way? Some of it certainly stemmed from the 
> emphasis in the TEA documentation at the time on how one can nest 
> model-update-view-message quads. But another part stemmed from wanting to 
> use Html.Lazy fairly aggressively. That desire also led to more logic that 
> tried to avoid generating new values when existing values would do. 
>
> So, my question in retrospect is: How important is using Html.Lazy to 
> performance? Is it something one should put in at obvious break points 
> where there are expected to be large subtrees? Is it something that should 
> be used close to the leaves with the internal tree largely left non-lazy? 
> Is it something that you ignore until it seems like things aren't fast 
> enough and then start trying to contort your model and view to make lazy 
> work? 
>
> My expectation from years of development is that on performance issues, 
> one shouldn't go putting in more complicated code for problems that aren't 
> yet known to exist — e.g., just sprinkling in laziness everywhere — but one 
> should plan for what one would do if performance became a problem — e.g., 
> if this were an issue, we could make it lazy right here. Lots of people 
> adhere to the first principle citing concerns over "premature optimization" 
> but the second principle tends to get less attention thereby leading to 
> "sand in the gears" that can never be adequately addressed. 
>
> So, how import is lazy HTML and how does one best plan for its 
> introduction where it proves necessary? 
>
> 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: Subscribe to a model value then call update function when condition is met

[OvermindDL1]

I'd set a flag on the model for when it is 'processing' (good flag name, 
maybe `isProcessing` or so?) and just test that in the model and set and 
unset it whenever processing is started/finished.  :-)

Just think of it as another piece of 'state'.  In fact if it can be gleaned 
from another piece of state (such as the animationframe being 'on') then 
check that instead, you do not want duplicate pieces in your model that 
hold essentially the same information, only have one place per piece of 
data.  :-)


On Monday, October 10, 2016 at 2:07:59 PM UTC-6, hoang...@gmail.com wrote:
>
> The AnimationFrame works perfectly. Thank you :D 
> I have another question came in mind. How do you think can we make the 
> view display, for example "Thinking", while the minimax algorithm is being 
> executed?
>
> Thank you a lot for your help. :D
>
> Vào 00:11:59 UTC+7 Thứ Ba, ngày 11 tháng 10 năm 2016, OvermindDL1 đã viết:
>>
>> Most callbacks in a browser, such as the timeout used for Time, is 
>> throttled to 4ms and behaves strangely below 16ms, if you want to execute 
>> as fast as possible then you should use an AnimationFrame subscription. 
>>  Time subscriptions should only be used for 500ms or larger or so, any less 
>> and it starts to act odd.
>>
>> You should probably still do a test to make sure it is the ai turn in 
>> your update for `AIMove` though, the browser can cache and send events 
>> 'later' than you expect as well.
>>
>> On Monday, October 10, 2016 at 11:06:07 AM UTC-6, hoang...@gmail.com 
>> wrote:
>>>
>>> I just found a problem with using subscription though. I tried replace 
>>> second with millisecond, while the minimax was executing (about less than a 
>>> second)  the program keep calling more AIMove.
>>>
>>>
>>> subscriptions model =
>>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>>> Time.every millisecond AIMove
>>>
>>>
>>> Vào 23:54:21 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã 
>>> viết:
>>>>
>>>> The example he put above is fine:  :)
>>>> ```
>>>> subscriptions : Model -> Sub Msg
>>>> subscriptions model =
>>>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>>>> Time.every second AIMove
>>>>   else
>>>> Sub.none
>>>> ```
>>>> Though if you want it in another function you can do that too (useful 
>>>> to batch functionality together):
>>>> ```
>>>> subAITick : Model -> Sub Msg
>>>> subAITick model =
>>>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>>>> Time.every second AIMove
>>>>   else
>>>> Sub.none
>>>>
>>>> subscriptions : Model -> Sub Msg
>>>> subscriptions model =
>>>>   subAITick
>>>> ```
>>>> Or if you have other subscriptions too, batching them together:
>>>> ```
>>>>
>>>> subscriptions : Model -> Sub Msg
>>>> subscriptions model =
>>>>   Sub.batch
>>>> [ subAITick
>>>> ; otherSubscriptionsHere
>>>> ]
>>>> ```
>>>>
>>>>
>>>> On Monday, October 10, 2016 at 10:48:34 AM UTC-6, hoang...@gmail.com 
>>>> wrote:
>>>>>
>>>>> Can you show code example :D I'm quite new to Elm and javascript. 
>>>>>
>>>>> Vào 23:45:45 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã 
>>>>> viết:
>>>>>>
>>>>>> Yep, just call it from the subscriptions callback then.
>>>>>>
>>>>>>
>>>>>> On Monday, October 10, 2016 at 10:36:58 AM UTC-6, hoang...@gmail.com 
>>>>>> wrote:
>>>>>>>
>>>>>>> This is quite a good idea. But can we define our own function that 
>>>>>>> can return a Sub Msg?
>>>>>>>
>>>>>>> Vào 20:41:40 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, Wouter In t 
>>>>>>> Velt đã viết:
>>>>>>>>
>>>>>>>> (disclaimer: I am also quite new to Elm) 
>>>>>>>> I always try to avoid creating my own Cmd: there is usually a 
>>>>>>>> better, less bug-prone way to achieve this (e.g. with resursive update 
>>>>>>>> calls).
&g

[elm-discuss] Re: Subscribe to a model value then call update function when condition is met

[OvermindDL1]

Most callbacks in a browser, such as the timeout used for Time, is 
throttled to 4ms and behaves strangely below 16ms, if you want to execute 
as fast as possible then you should use an AnimationFrame subscription. 
 Time subscriptions should only be used for 500ms or larger or so, any less 
and it starts to act odd.

You should probably still do a test to make sure it is the ai turn in your 
update for `AIMove` though, the browser can cache and send events 'later' 
than you expect as well.

On Monday, October 10, 2016 at 11:06:07 AM UTC-6, hoang...@gmail.com wrote:
>
> I just found a problem with using subscription though. I tried replace 
> second with millisecond, while the minimax was executing (about less than a 
> second)  the program keep calling more AIMove.
>
>
> subscriptions model =
>   if (gameIsNotFinished model && model.turn == AIToMove) then
> Time.every millisecond AIMove
>
>
> Vào 23:54:21 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã viết:
>>
>> The example he put above is fine:  :)
>> ```
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>> Time.every second AIMove
>>   else
>> Sub.none
>> ```
>> Though if you want it in another function you can do that too (useful to 
>> batch functionality together):
>> ```
>> subAITick : Model -> Sub Msg
>> subAITick model =
>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>> Time.every second AIMove
>>   else
>> Sub.none
>>
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>>   subAITick
>> ```
>> Or if you have other subscriptions too, batching them together:
>> ```
>>
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>>   Sub.batch
>> [ subAITick
>> ; otherSubscriptionsHere
>> ]
>> ```
>>
>>
>> On Monday, October 10, 2016 at 10:48:34 AM UTC-6, hoang...@gmail.com 
>> wrote:
>>>
>>> Can you show code example :D I'm quite new to Elm and javascript. 
>>>
>>> Vào 23:45:45 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã 
>>> viết:
>>>>
>>>> Yep, just call it from the subscriptions callback then.
>>>>
>>>>
>>>> On Monday, October 10, 2016 at 10:36:58 AM UTC-6, hoang...@gmail.com 
>>>> wrote:
>>>>>
>>>>> This is quite a good idea. But can we define our own function that can 
>>>>> return a Sub Msg?
>>>>>
>>>>> Vào 20:41:40 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, Wouter In t 
>>>>> Velt đã viết:
>>>>>>
>>>>>> (disclaimer: I am also quite new to Elm) 
>>>>>> I always try to avoid creating my own Cmd: there is usually a better, 
>>>>>> less bug-prone way to achieve this (e.g. with resursive update calls).
>>>>>>
>>>>>> That said: I can see the logic in having a Msg originating from a 
>>>>>> "real" player, and another Msg from your AI player.
>>>>>>
>>>>>> What you could do, is make a subscription to Time, that is only 
>>>>>> active if it is the AI's turn to move.
>>>>>> That way, you get a) a delay before the AI makes a move + b) you do 
>>>>>> not need to create your own command
>>>>>> Whenever it is the user's turn, or as soon as the game is over, the 
>>>>>> subscription is turned off.
>>>>>>
>>>>>> Something like this:
>>>>>>
>>>>>> subscriptions : Model -> Sub Msg
>>>>>> subscriptions model =
>>>>>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>>>>>> Time.every second AIMove
>>>>>>   else
>>>>>> Sub.none
>>>>>>
>>>>>> You would of course have to define your own functions to check if the 
>>>>>> game is still playing (no winner and no draw) and if it is the AI's turn 
>>>>>> to 
>>>>>> play.
>>>>>>
>>>>>

-- 
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: Subscribe to a model value then call update function when condition is met

[OvermindDL1]

The example he put above is fine:  :)
```
subscriptions : Model -> Sub Msg
subscriptions model =
  if (gameIsNotFinished model && model.turn == AIToMove) then
Time.every second AIMove
  else
Sub.none
```
Though if you want it in another function you can do that too (useful to 
batch functionality together):
```
subAITick : Model -> Sub Msg
subAITick model =
  if (gameIsNotFinished model && model.turn == AIToMove) then
Time.every second AIMove
  else
Sub.none

subscriptions : Model -> Sub Msg
subscriptions model =
  subAITick
```
Or if you have other subscriptions too, batching them together:
```

subscriptions : Model -> Sub Msg
subscriptions model =
  Sub.batch
[ subAITick
; otherSubscriptionsHere
]
```


On Monday, October 10, 2016 at 10:48:34 AM UTC-6, hoang...@gmail.com wrote:
>
> Can you show code example :D I'm quite new to Elm and javascript. 
>
> Vào 23:45:45 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, OvermindDL1 đã viết:
>>
>> Yep, just call it from the subscriptions callback then.
>>
>>
>> On Monday, October 10, 2016 at 10:36:58 AM UTC-6, hoang...@gmail.com 
>> wrote:
>>>
>>> This is quite a good idea. But can we define our own function that can 
>>> return a Sub Msg?
>>>
>>> Vào 20:41:40 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, Wouter In t Velt 
>>> đã viết:
>>>>
>>>> (disclaimer: I am also quite new to Elm) 
>>>> I always try to avoid creating my own Cmd: there is usually a better, 
>>>> less bug-prone way to achieve this (e.g. with resursive update calls).
>>>>
>>>> That said: I can see the logic in having a Msg originating from a 
>>>> "real" player, and another Msg from your AI player.
>>>>
>>>> What you could do, is make a subscription to Time, that is only active 
>>>> if it is the AI's turn to move.
>>>> That way, you get a) a delay before the AI makes a move + b) you do not 
>>>> need to create your own command
>>>> Whenever it is the user's turn, or as soon as the game is over, the 
>>>> subscription is turned off.
>>>>
>>>> Something like this:
>>>>
>>>> subscriptions : Model -> Sub Msg
>>>> subscriptions model =
>>>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>>>> Time.every second AIMove
>>>>   else
>>>> Sub.none
>>>>
>>>> You would of course have to define your own functions to check if the 
>>>> game is still playing (no winner and no draw) and if it is the AI's turn 
>>>> to 
>>>> play.
>>>>
>>>

-- 
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: Subscribe to a model value then call update function when condition is met

[OvermindDL1]

Yep, just call it from the subscriptions callback then.


On Monday, October 10, 2016 at 10:36:58 AM UTC-6, hoang...@gmail.com wrote:
>
> This is quite a good idea. But can we define our own function that can 
> return a Sub Msg?
>
> Vào 20:41:40 UTC+7 Thứ Hai, ngày 10 tháng 10 năm 2016, Wouter In t Velt đã 
> viết:
>>
>> (disclaimer: I am also quite new to Elm) 
>> I always try to avoid creating my own Cmd: there is usually a better, 
>> less bug-prone way to achieve this (e.g. with resursive update calls).
>>
>> That said: I can see the logic in having a Msg originating from a "real" 
>> player, and another Msg from your AI player.
>>
>> What you could do, is make a subscription to Time, that is only active if 
>> it is the AI's turn to move.
>> That way, you get a) a delay before the AI makes a move + b) you do not 
>> need to create your own command
>> Whenever it is the user's turn, or as soon as the game is over, the 
>> subscription is turned off.
>>
>> Something like this:
>>
>> subscriptions : Model -> Sub Msg
>> subscriptions model =
>>   if (gameIsNotFinished model && model.turn == AIToMove) then
>> Time.every second AIMove
>>   else
>> Sub.none
>>
>> You would of course have to define your own functions to check if the 
>> game is still playing (no winner and no draw) and if it is the AI's turn to 
>> play.
>>
>

-- 
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: Anyone working on audio stuff?

[OvermindDL1]

The HTML5 audio element you can already control easily.  WebAudio would 
require some types that do not yet exist in Elm, but you could use ports 
for now.

On Saturday, October 8, 2016 at 6:24:10 PM UTC-6, ratvis wrote:
>
> Either just HTLM5 audio element or web-audio? I kind of thought after .17 
> came out, some more stuff would come out. 
> Just a wrapper thing around html5 audio (onPause, onEnded,...) would 
> enable people to do fun stuff. 
>

-- 
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: Creating an API to be consumed by JS developers

[OvermindDL1]

The 'official' interaction between Elm and javascript is via ports, which 
involves marshelling any JSON-compatible type across the interface.  From 
the Javascript side it involves just 'send'ing something to somewhere (like 
via `Elm.MyApp.ports.someport.send("something");`) or to get data from Elm 
you 'subscribe' to it (such as in `
Elm.MyApp.ports.someport.subscribe(function(msg){console.log(msg);})`).  It 
defines a specific interface for data to transfer over so everything on the 
Elm side can be 'safe' and any unsafe access happens only through know 
access points.


On Saturday, October 8, 2016 at 12:22:12 PM UTC-6, Dave Ford wrote:
>
> My experience with compile-to-js languages include: GWT, Dart and 
> TypeScript.
>
> GWT was very good at *calling* JS libraries. Almost zero friction. But 
> not so, in the other direction. Creating API's to be consumed by JS was so 
> ugly that I can confidently say that it was not worth it. Unless you are 
> creating an API that has a very small surface area to functionality ration 
> (like maybe a spell checker).
>
> Dart has a similar story to GWT. 
>
> By far the best inter-op story is TypeScript. If you write a lib 
> in TypeScript it can be consumed by JS as-is. No special anything is 
> needed. 
>
> So my question is, where does Elm fall in this spectrum. Is it advisable 
> to create an api in Elm to be consumed by JS developers?
>

-- 
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: Which text editor do you prefer for Elm?

[OvermindDL1]

Are there a set of wiki pages that such a table could be set up at? 
 Perhaps at the elm-lang.github.io or so?  This would be a good setup to 
add.  I know Atom plugins have all the below features for Elm (and more 
features).


On Tuesday, October 4, 2016 at 6:35:38 AM UTC-6, Andrew Radford wrote:
>
> I'm also using this, but one thing that I can't figure out is how to copy 
> code to the elm repl. Never works if you copy more than one line...
>
> Would love to see a matrix of capabilities for common editors, covering 
> things like
>
> * Intellisense
> * Send to Repl
> * Go to definition
> * Rename Refactor
> * Elm-format 
>
> etc etc.
>
> I think it would be a good tool for beginners (like me) to get going 
> faster. They won't need to 'survey the landscape' as much.
>
> On Tuesday, 4 October 2016 12:57:15 UTC+1, Witold Szczerba wrote:
>>
>> Recently I've tried the VS Code. Installed the elm plugin and it works 
>> like a charm. I'm positively surprised. 
>>
>>
>>>

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