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

[GordonBGood]

On Friday, 27 January 2017 20:22:23 UTC+7, Bob Zhang wrote:
>
> Hi Gordon, your facts can be changed every post. 
> And you spent a month in tweaking your elm expert's code to match the perf 
> of newbie's BuckleScript code, I am still not sure you reach there.
> I suggested we take the discussions off the list very very early,
> most people have very busy professional life, this is gonna be my last 
> post in this thread.


I did not spend "a month on elm expert's code"; I spent a month off and on 
evaluating many JS transpilers including Elm, PureScript, GHCJS, 
TypeScript, Nim, Kotlin, Fable, and finally BuckleScript.

I wrote the benchmarks for each in standard functional programming style 
including these ones for Elm and the ones for BuckleScript.

The objectives of the thread are clear enough:  try to make Elm faster 
where it isn't, and find ways to augment it when necessary.  I looked into 
all the other transpilers including BuckleScript with this in mind.

I agreed with you that an alternate way of communicating about BuckleScript 
would be better, and asked you to provide a means, as I didn't want to 
clutter your repo with issues.  You did not do this.

Finally, I found a significant slowdown of BuckleScript in one particular 
situation of running any benchmark on FireFox, and (although I didn't have 
to to this) traced the reason for this and the only workaround I could 
find, which has nothing to do with the code I wrote.

In response, rather than looking into the reasons for that slowdown, you 
have been snarky with me, maintaining that it is the differences in the 
code that cause the issue rather than looking at the real issues or opening 
a channel so you could obtain my code to look at it for problems.

You know, one of the reasons that one would choose to develop in one of 
these "one-man-show" languages is how the BDFL reacts to issues: in that 
you fail.

'bye.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Benchmarking with no JavaScript dependencies

[Joey Eremondi]

>
> I have some thoughts on how to fix the effectful functions… namely,
> lifting them to Tasks. But that doesn't seem like quite the right approach,
> since Tasks can fail and these can't. This makes me think that an effect
> module may be the best way to handle this.
>

Couldn't you just make them of type "Task Never Foo", and then you could
use them knowing they wouldn't fail? That seems preferable to having Native
dependencies to me.

I think you could get away without Native otherwise. For example, if your
Benchmark internally stored functions of "() -> a" into "() -> ()" by
giving them to "\f -> let _ = f () in ()", you could compile suites in a
typesafe way.

On Fri, Jan 27, 2017 at 2:09 PM, Brian Hicks  wrote:

> *Summary:* I'd like a benchmarking library to use in Elm with no
> JavaScript dependencies. The sketch I have so far requires native code. Now
> that I've proved the concept to myself, I'd like to discuss the best API.
>
> I've created the following functions, backed by native code (using
> performance.now):
>
> type Benchmark = Benchmark
>
> benchmark (() -> a) -> Benchmark
>
> time : Benchmark -> Float
>
> It does about what you'd expect, except `benchmark` removes the function
> type signatures so you can have a list of benchmarks in a suite, without
> having to make them all the same type. I think I can build a reasonable
> benchmarking library on top of this.
>
> The first reasonable thing to do is run a number of times and return
> statistics (I've started with mean runtime.) That would be `runTimes : Int
> -> Benchmark -> Float`.
>
> My next thought is to try and box these into a set runtime. I've
> implemented this as `run : Float -> Benchmark -> ( Int, Float )`. The tuple
> is `( sample size, mean runtime)`.
>
> Now, a third thought… and this is where I'd like feedback. The
> implementation so far has some problems:
>
> - The Benchmark type removes type information from the functions under
> consideration. I can think of ways to get around it in pure Elm (e.g.
> making a constructor using `always SomeStubType`.) But it just doesn't feel
> right.
> - The `time` and `run*` functions are effectful. Not that they can't be,
> if we're going to benchmark properly.
>
> I have some thoughts on how to fix the effectful functions… namely,
> lifting them to Tasks. But that doesn't seem like quite the right approach,
> since Tasks can fail and these can't. This makes me think that an effect
> module may be the best way to handle this.
>
> Either approach would allow us to use the existing composition functions
> (andThen, batch, etc) to compose benchmarks. We may also be able to, if
> using an effects module, "warm up" a particular benchmark before the first
> use for better accuracy when timeboxing.
>
> This library is already going to require an exception for native code no
> matter what because of `time`. I'd rather get feedback early before I go in
> one direction or the other for the API. So, what do y'all 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.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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] Benchmarking with no JavaScript dependencies

[Brian Hicks]

Summary: I'd like a benchmarking library to use in Elm with no JavaScript 
dependencies. The sketch I have so far requires native code. Now that I've 
proved the concept to myself, I'd like to discuss the best API.

I've created the following functions, backed by native code (using 
performance.now):

type Benchmark = Benchmark

benchmark (() -> a) -> Benchmark

time : Benchmark -> Float

It does about what you'd expect, except `benchmark` removes the function type 
signatures so you can have a list of benchmarks in a suite, without having to 
make them all the same type. I think I can build a reasonable benchmarking 
library on top of this.

The first reasonable thing to do is run a number of times and return statistics 
(I've started with mean runtime.) That would be `runTimes : Int -> Benchmark -> 
Float`.

My next thought is to try and box these into a set runtime. I've implemented 
this as `run : Float -> Benchmark -> ( Int, Float )`. The tuple is `( sample 
size, mean runtime)`.

Now, a third thought… and this is where I'd like feedback. The implementation 
so far has some problems:

- The Benchmark type removes type information from the functions under 
consideration. I can think of ways to get around it in pure Elm (e.g. making a 
constructor using `always SomeStubType`.) But it just doesn't feel right.
- The `time` and `run*` functions are effectful. Not that they can't be, if 
we're going to benchmark properly.

I have some thoughts on how to fix the effectful functions… namely, lifting 
them to Tasks. But that doesn't seem like quite the right approach, since Tasks 
can fail and these can't. This makes me think that an effect module may be the 
best way to handle this.

Either approach would allow us to use the existing composition functions 
(andThen, batch, etc) to compose benchmarks. We may also be able to, if using 
an effects module, "warm up" a particular benchmark before the first use for 
better accuracy when timeboxing.

This library is already going to require an exception for native code no matter 
what because of `time`. I'd rather get feedback early before I go in one 
direction or the other for the API. So, what do y'all think?

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

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Matthieu Pizenberg]

Yep he definitely should evan-gelize more. ... (OK I'm out)

On Jan 27, 2017 19:46, "Duane Johnson"  wrote:


On Fri, Jan 27, 2017 at 10:52 AM, Rex van der Spuy 
wrote:

> And, I hope he always remains the sole maintainer and developer of the
> language, because, frankly, I just don't trust anyone else :)
>

Gosh, I hope not, because that would mean he failed to teach anyone else
how to replicate Elm's leadership success.

-- 
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/rg3fzdyG_VU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Duane Johnson]

On Fri, Jan 27, 2017 at 10:52 AM, Rex van der Spuy 
wrote:

> And, I hope he always remains the sole maintainer and developer of the
> language, because, frankly, I just don't trust anyone else :)
>

Gosh, I hope not, because that would mean he failed to teach anyone else
how to replicate Elm's leadership success.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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

[Rex van der Spuy]

On Friday, January 27, 2017 at 12:36:38 AM UTC-5, Gage Peterson wrote:
>
> Totally agree. Reddit here I come. 
>
> Also, I feel we really need to treat Evan like the awesome leader he is. 
> Give the guy a break. He's making one of the best languages I've ever used.
>

Triple +++
Elm is the only language/software project that I know if where each new 
release is about r*emoving features* and *increasing simplicity*.
That's astonishing - Bravo!
And, extremely wise, long-term decisions are made that are right for the 
language, without being distracted by the current coding fashions of the 
moment.
Elm doesn't ever need to be mainstream - it just needs to be the best 
language it can be for the people like us who love using it.
Evan has completely won my trust over the year and half I've been using 
Elm, so whatever he recommends, I'm in! :)
And, I hope he always remains the sole maintainer and developer of the 
language, because, frankly, I just don't trust anyone else :)

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

Re: [elm-discuss] Convert Char to Int?

[Duane Johnson]

On Thu, Jan 26, 2017 at 11:52 PM, Peter Damoc  wrote:

> What does this mean? KeyCode is an alias to Int so, at least in theory,
> you should have the actual Int value of the Char.
> What happens if you display this Int value? How does it differ from what
> you need?
>

I was basing my comment on the documentation:

Keyboard keys can be represented as integers. These are called key codes.
> You can use toCode and fromCode to convert between key codes and characters.


And the `Char.toKeyCode` function describes its purpose as:

Convert to key code.


But it turns out you're right, there is a simple conversion to integer
happening under the hood.

I think what I'm concerned about is that these strings may be treated as
Unicode and some unintentional conversion will happen without my knowing.
But I haven't tried yet.

Thanks for your help on this.

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

Re: [elm-discuss] Re: Using Elm on the server (full stack Elm webapps )

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 4:00:17 PM UTC, Peter Damoc wrote:
>
> On Fri, Jan 27, 2017 at 4:51 PM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> On Friday, January 27, 2017 at 10:15:49 AM UTC, Rupert Smith wrote:
>>>
>>> I think what is missing is DB access.
>>>
>>
>> What would be even cooler is if you didn't need to worry about the 
>> database. If there was a way of declaring a Model in Elm, and every time 
>> you make an update to it, it automatically gets saved to the database, no 
>> need invoke a port to save it. I've always though a language which has 
>> persistence built in would be really cool. It could be done with Elm using 
>> the same trick as the time travelling debugger - just spool all the updates 
>> to disk and they form an 'event source' to recover the state from in the 
>> event of a crash. Occasionally you would check-point the entire state model 
>> to disk to make a fast recovery point. 
>>
>> Well... this is what I'm looking into right now. Nobody wants to write 
> boilerplate. :) 
>
> The idea would be for the page to interact with a client-side database 
> like entity that would take care of all the communication with the server. 
>
> This is a complex topic. For example, I still have no idea how could one 
> express relational data in Elm? 
> e.g. Users have Messages and Messages have other Messages as replies and 
> each of those Messages have Users. How would you model that in Elm?  
>

I just take a 'slice' of relational data on the client, the slicing having 
already been done by the server API. So if I took a slice from Users -> 
Messages -> Users I may end up with duplicate Users on the client - but 
thats ok. In other words I expand relational models out into document 
models, each of which is a slice of the relational data.

If I do want to represent a relationship on the Client, then I build a List 
or Set or Dict and populate it with data from various other slices. If I 
can see that a relationship being built on the client is already formed on 
the server side, I might just move it there as fetching it in one go will 
be more efficient. Provided it is something that makes sense as part of the 
API.

For example, at the moment I have a database for 'content'. Each 'content' 
can be the parent of another. And a 'content' can also act as a container 
and contain child pieces that make it up. I have queries for fetching the 
table of contents as a tree, and for fetching a full container of content 
to render a page. Both these are document models extracted from the 
relational model on the server.
 

>
> I started a topic back in October but I haven't followed it through and 
> now it has almost completely vanished from my mind. 
> I'll go again through that discussion and think some more on this. 
>

Yes, I remember it. I don't want to make the database directly accessed on 
the client though, as business logic on the client could potentially be 
bypassed, and the API to the database used to make direct modifications to 
the data. There may be complex or security rules that a server needs to 
enforce.

This kind of automatic persistence has a lot more appeal to me as a 
server-side concept.

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

Re: [elm-discuss] How do you discard an Html message?

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 4:02:27 PM UTC, Alex Barry wrote:
>
> That should do the trick for you. You might want a better message name. 
> Also, why discard the message?
>

Thanks. Just as a temporary measure whilst hacking at a new bit of code. I 
just wanted to display something but ignore its events for now.

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

Re: [elm-discuss] How do you discard an Html message?

[Witold Szczerba]

The solution mentioned here from time to time (I have used it as well) is
to treat
text ""
as… well… as nothing.

On Fri, Jan 27, 2017 at 4:45 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> Having a dozy moment again...
>
> If I have some view that returns an Html MyFunkyStuff.Msg but I want to
> Html.map that to the local Html Msg, is there a way I can discard the
> message being mapped? There isn't an Html.none like there is Cmd.none or
> Sub.none.
>
> Perhaps there isn't a way of doing this, and I need to code my own Noop
> message? I guess javascript event handlers have already been attached by
> the view function just executed, so they can't be turned off in this way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] How do you discard an Html message?

[Alex Barry]

Type Msg
  = ...
  | NoOp msg

update msg model =
  case msg of
NoOp _ -> ( model, Cmd.none )

That should do the trick for you. You might want a better message name.
Also, why discard the message?


On Fri, Jan 27, 2017 at 10:45 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> Having a dozy moment again...
>
> If I have some view that returns an Html MyFunkyStuff.Msg but I want to
> Html.map that to the local Html Msg, is there a way I can discard the
> message being mapped? There isn't an Html.none like there is Cmd.none or
> Sub.none.
>
> Perhaps there isn't a way of doing this, and I need to code my own Noop
> message? I guess javascript event handlers have already been attached by
> the view function just executed, so they can't be turned off in this way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [elm-discuss] Re: Using Elm on the server (full stack Elm webapps )

[Peter Damoc]

On Fri, Jan 27, 2017 at 4:51 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Friday, January 27, 2017 at 10:15:49 AM UTC, Rupert Smith wrote:
>>
>> I think what is missing is DB access.
>>
>
> What would be even cooler is if you didn't need to worry about the
> database. If there was a way of declaring a Model in Elm, and every time
> you make an update to it, it automatically gets saved to the database, no
> need invoke a port to save it. I've always though a language which has
> persistence built in would be really cool. It could be done with Elm using
> the same trick as the time travelling debugger - just spool all the updates
> to disk and they form an 'event source' to recover the state from in the
> event of a crash. Occasionally you would check-point the entire state model
> to disk to make a fast recovery point.
>
> Well... this is what I'm looking into right now. Nobody wants to write
boilerplate. :)

The idea would be for the page to interact with a client-side database like
entity that would take care of all the communication with the server.

This is a complex topic. For example, I still have no idea how could one
express relational data in Elm?
e.g. Users have Messages and Messages have other Messages as replies and
each of those Messages have Users. How would you model that in Elm?

I started a topic back in October but I haven't followed it through and now
it has almost completely vanished from my mind.
I'll go again through that discussion and think some more on 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] Re: Using Elm on the server (full stack Elm webapps )

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 10:15:49 AM UTC, Rupert Smith wrote:
>
> I think what is missing is DB access.
>

What would be even cooler is if you didn't need to worry about the 
database. If there was a way of declaring a Model in Elm, and every time 
you make an update to it, it automatically gets saved to the database, no 
need invoke a port to save it. I've always though a language which has 
persistence built in would be really cool. It could be done with Elm using 
the same trick as the time travelling debugger - just spool all the updates 
to disk and they form an 'event source' to recover the state from in the 
event of a crash. Occasionally you would check-point the entire state model 
to disk to make a fast recovery point. 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 5:36:38 AM UTC, Gage Peterson wrote:
>
> Also, I feel we really need to treat Evan like the awesome leader he is. 
> Give the guy a break. He's making one of the best languages I've ever used.
>

+1 to that. I am very much enjoying working with Elm, it has re-invigorated 
my interest in programming.

I learned ML at uni, but that was 20 years ago. It seemed to me at the time 
that it was a revolution that would be 20 years coming. I think Elm is well 
positioned, being simple, yet very practical. It may not have type classes 
like Haskell, but it sets itself apart from 'academic languages' by 
dispensing with some of the fancier features to appeal to a more mainstream 
audience.

20 years a Java programmer, and now I finally find a use for all that stuff 
my professors taught me, which quite honestly I have never used since 
finishing my university projects. Awesome effort Evan Czaplicki.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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...

[GordonBGood]

On Tuesday, 24 January 2017 18:47:49 UTC+7, Robin Heggelund Hansen 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).
>> This becomes readily seen the more functional the code, with the use of 
>> tuples (tagged objects), lots of records (tagged objects), lists (nested 
>> tagged objects) and so on, and these passed as (essentially untyped) 
>> arguments across functions.
>
>
> This goes against my own benchmarks, where replacing current Elm code with 
> arrays proved slower. Accessing an element on a record was faster than on 
> an array. Did you try against more than just one browser?
>

You've obviously been here, done that.  I repeated my tests across Chrome, 
FireFox, and Edge, and found that, as you say, the tagged JS Records were 
generally slightly faster, but the difference was too small to worry about. 
Bigger was the difference in browsers, where the ratio of the fastest 
(Firefox/Chrome) to the slowest (Internet Explorer/Edge) was over two times.
 

> It is possible to eliminate some of the string tags, but in most cases you 
> will need some sort of tagging. ADTs for instance, which is the majority of 
> cases using tags, does pattern matching on the tag because you cannot know 
> at compile time what object you're dealing with. You need some sort of 
> tagging here, and since strings are interned in javascript, equality 
> checking on a string is a very fast operation. In my tests there were no 
> difference between using numbers or strings as tags.
>

If the compiler kept its static type information for the Code Generator, it 
is possible to eliminate all string tags except for the tagged union (it's 
in the name!)/ADT's as BuckleScript does; However, as they don't seem to 
have an execution speed cost, it doesn't really matter for now. 
 

> Records are not tagged. They're just normal js objects.
> Tuple types only uses tags when determining size. And that is only done 
> for comparisons and equality checks if I remember correctly.
> Lists are linked lists, and so require some sort of tagging. The most 
> efficient way would to use some sort of possible null reference instead of 
> a string tag, but I doubt it makes much difference.
>

 Currently Tuple types tags are used to check for the size of the tuple for 
comparisons and equality, but that's just because the compiler didn't keep 
type information and it's too slow on some browsers to find the count of 
fields through a program; the compiler already knew the size of the tuples 
being compared; else it wouldn't have allowed the comparisons in the first 
place in the case of tuples.
Just as for List's, the compiler already knew what type was there and the 
only special case required is "bottom", which could be marked without a tag.
However, as you say the tags don't cost much if anything in execution speed 
and the main cost is only the extra space taken in memory.

If the compiler passed type information to the code generator, Records 
could be added to the comparable super type, functions could be comparable 
(as the compiler knows the type signature), and even tagged unions with 
only one tag could be part of the comparable super group as the compiler 
knows number and type of fields; the only reason they are not comparable 
now is that type information is not passed to the code generator.  The only 
things not comparable would be multi-tagged unions or any kind of stream 
where the compiler does not know the exact type in advance.  In 
BuckleScript, even tagged unions are comparable using the index number of 
the (numeric) tag as the first field.  If all Elm types were comparable, 
there wouldn't be restrictions on what could be used as keys in Dict's and 
Set's and little need for proposed type classes.

Now that I understand how things work better, my main speed issues now are 
the issue that you identified as an issue in eq/cmp calls and library 
things:  the current Lazy library module uses nested functions which can be 
very slow, and it seems to me that there is room for a linear immultable 
array library module like the Data.IArray module in Haskell, which would be 
useful when the current or 

[elm-discuss] Re: All animation to be done in a single update?

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 10:04:50 AM UTC, Rupert Smith wrote:
>
> The state for this particular piece of the application is held in an 
> elm-multiway-tree-zipper (
> http://package.elm-lang.org/packages/tomjkidd/elm-multiway-tree-zipper/latest).
>  
> The way to associate a message with part of the tree is to pass a zipper.
>

One thing I have come to realize about zipper trees, is that you can only 
make modificiations to the tree with one zipper at a time. Update 
operations that make changes to 2 or more parts of the tree in one go are 
awkward. The reason is that each zipper describes the state - 1 version of 
the tree. What I want is a zipper that describes state - 1, apply it to get 
a new temp state, then the second zipper to describe that temp state, then 
apply it to arrive at the new state for the tree.

The exception is when I want to make a change to all parent nodes walking 
back to the root. So if a deep node is 'opened' for viewing, I probably 
want to ensure all parent nodes back to the root are also 'opened'. That is 
possible as when walking the zipper back to the root to form the new tree, 
the same operation can be applied at all steps.

The solution generally seems to be to just walk the whole tree (using map) 
when changes are to be made to multiple parts of it. I suppose I could make 
this more efficient by writing a tree walk that only visits parts of the 
tree that are currently 'opened' as other parts will be hidden from view. 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: All animation to be done in a single update?

['Rupert Smith' via Elm Discuss]

On Friday, January 27, 2017 at 10:04:50 AM UTC, Rupert Smith wrote:
>
> So I think that Animate messages are sent out on a timer, one per tick, 
> rather than one per animation needing updated? I was assuming that 
> Animation.subscription would generate one Animate message per animation 
> needing updated, so if two updates occurred on the same tick there would be 
> 2 messages. This seems not to be the case.
>

So I dropped the zipper from the Animate message, and just iterate the 
whole tree and update all Animation.States encountered in it, on each 
Animate message. This produces the desired effect.

Might get slow if the tree gets big? I'll solve that problem when it 
happens...

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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: Using Elm on the server (full stack Elm webapps )

['Rupert Smith' via Elm Discuss]

On Thursday, January 26, 2017 at 8:00:57 PM UTC, Peter Damoc wrote:
>
>
>
> On Thu, Jan 26, 2017 at 6:40 PM, 'Rupert Smith' via Elm Discuss <
> elm-d...@googlegroups.com > wrote:
>
>> Still, its a long way from there to a full stack...
>>
>> Every journey has to start somewhere. Can you share a set of requirements 
> for a full-stack? Like, how would a checklist for your must have and nice 
> to have features would be? 
>

I think what is missing is DB access.

I'm doing static Html with Elm server side, but have not gone as far as 
business logic. Actually you have shown me something very interesting here, 
because I can see a way that I could very easily start writing business 
logic in Elm, which would be a nice language to write it in.

I can't see myself wanting to do DB access in Elm any time soon though. 
Partly because I have already solved that very nicely in Java. Java may not 
be nice but it does have one thing going for it: lots of mature libraries 
to interface just about anything.

I can map my Java data object into Elm (already doing that for the static 
Elm programs), all I would need to do is add ports for all the data layer 
operations (CRUD + finder + custom operations) and I could start doing 
business logic in Elm too. I would need it to run faster though. Its ok for 
static page generation to be really slow, as I can add a caching layer. I 
might be better to look at something like Frege (Haskell for the JVM) if I 
wanted to start writing business logic in a statically typed functional 
language.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and 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...

[GordonBGood]

On Friday, 27 January 2017 09:13:12 UTC+7, Bob Zhang wrote:
>
> As I said, you already get convinced elm is better for you, then happy 
> coding in elm. I am not interested in a biased judgement.


Hongbo, I'm making no judgement at all other than for the facts I see and 
the analysis I make based on those facts.

The fact is that I have two as much as possible identical implementations 
of a functional tree folding Sieve of Eratosthenes primes algorithm since 
you didn't like what I did with the Hamming numbers one, one written in Elm 
and the other in BuckleScript.

Another set of facts are that when run on Chrome or Edge, they have similar 
performance or at least small performance differences that are easily 
understood for the known differences in the emitted code, but when compared 
on Firefox, the BS version is about five times slower than the Elm version.

I thought you would like to look at the code and tell me if I am doing 
something wrong or look into it if it is a BS issue, which it is.

I no longer believe it has anything to do with the use of Array's versus 
the use of Record's, as other facts are that I wrote simple versions in 
pure JavaScript using each of Array's and Record's (without tags and 
without currying) and the times do not change significantly for any given 
browser and Firefox is then very fast.  I have also manually edited the BS 
code to eliminate any small differences that could make any difference in 
execution time such as unnecessary closures and polyfills to little effect. 
 This leaves the biggest possibility for the difference in performance on 
FireFox as the differences between how the two languages implement currying.

Now I know that I can force BS to not use Currying by using the [@bs] 
notation, which if I did would very likely make BS run at its normal fast 
speed, but as you said before, since Elm doesn't have such notations it 
wouldn't be comparing like-with-like.  However, I did it anyway (adding 22 
[@bs] notations) and that made the code run eight times faster than before 
on FireFox, faster than Elm, and about as fast as hand-written JavaScript, 
proving that it is your method of implementing Curry'ing in BS that is the 
problem.

Remember that Elm doesn't have, and doesn't really need these notations. 
 There are several differences:  1)  BS does not use function wrappers with 
tagged arities but uses the function .length property to determine the 
arity on each invokation; it seems this is slow on current Firefox, 2) ) 
Elm doesn't need an arity check/currying function when there in only one 
function argument so doesn't wrap the functions or use the currying check 
function in this case, thus saves some time for single argument functions, 
and 3) (which turned out not to affect the speed in this case) Elm doesn't 
have true closures but normally just depends on immutability so as to be 
able to directly refer to and use captured free bindings; if one needs a 
closure (say to freeze a mutable loop variable in a Tail Call Optimized - 
TCO'd - loop), one just writes one themselves, with the ability to write an 
IIFE lifted in the code to where ever is best for minimum impact on 
performance.  For this benchmark I didn't have to pay any attention to this.

If you don't want to improve the performance of your Curry'ing functions on 
FireFox, I'll just drop it and let your users be sure to use the [@bs] 
notations if they want to generate fast code for (current) FireFox.

The reason I am interested in Elm is that I want an easy-to-use programming 
environment and programming language that I can use to generate quick 
browser applications to demonstrate some advanced math concepts to my 
students, sometimes with a game-like interface to keep them interested.  As 
these are each quite small projects, compilation speed doesn't really 
bother me much, but I do want to be able to reduce the file size for 
download/transfer, and it seems there are tools that will do that for me 
from Elm.  Even a 3D graphics interface written in Elm is not impossible 
using the IArray library I mentioned in another post.  I have never 
envisioned replacing Elm with BS, just augmenting some of the things that 
are difficult in Elm.  Now, it seems more and more that Elm will be able to 
do the majority of the work, especially if I am able to help improve the 
execution speed, and I believe I now finally am able to narrow down the 
areas which need work.

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

[elm-discuss] All animation to be done in a single update?

['Rupert Smith' via Elm Discuss]

I think I understand this, but let me run it past you all to check.

I notices that some of my animations are happening in sequence instead of 
in parallel. That is one animation must complete before the next begins.

I set up the animation subscriptions like this:

subscriptions : Model -> Sub Msg
subscriptions model =
List.map
(\zipper ->
Animation.subscription (Animate zipper)
[ Zipper.datum zipper |> .controlBarStyle ]
)
(collectAnimatedNodes model.contentTree)
|> Sub.batch

The idea being that each Animate message is associated with a zipper, to 
tell it which part of a tree needs updated. The state for this particular 
piece of the application is held in an elm-multiway-tree-zipper 
(http://package.elm-lang.org/packages/tomjkidd/elm-multiway-tree-zipper/latest).
 
The way to associate a message with part of the tree is to pass a zipper, 
which also means that my Animate messages are each associated with just one 
thing that needs animated.

When an Animate message is passed to 'update' is just update one part of 
the tree:

Animate zipper msg ->
case updateControlBarAnimation (Animation.update msg) zipper of
Nothing ->
( model, Nothing )

Just newTree ->
( { model | contentTree = newTree }, Nothing )

In another part of my application, when I get an Animate message, I update 
_all_ animations, and this does display the animations running in parallel:

Animate msg ->
( { model
| menuStyle = Animation.update msg model.menuStyle
, slideButtonStyle = Animation.update msg 
model.slideButtonStyle
  }
, Cmd.none
)

So I think that Animate messages are sent out on a timer, one per tick, 
rather than one per animation needing updated? I was assuming that 
Animation.subscription would generate one Animate message per animation 
needing updated, so if two updates occurred on the same tick there would be 
2 messages. This seems not to be the case.

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

[elm-discuss] Re: Convert Char to Int?

[John Watson]

I think this issue is related to your problem 
- https://github.com/elm-lang/http/issues/11. *HTTP.getString *resolves to 
javascript *readAsText *whereas what you need is something that resolves to 
*readAsBinaryString*.  This got lost when elm-lang/http replaced 
evancz/elm-http.

On Friday, 27 January 2017 03:55:03 UTC, Duane Johnson wrote:
>
> Big picture:
>
> I'm writing a visual display algorithm of a binary ".hex" file that is the 
> result of compiling code on the Arduino platform. I load the file into the 
> browser via HTTP.getString, and then attempt to display the values.
>
> Problem:
>
> I'm unable to find a way to represent this binary data stream as a series 
> of 16-bit integers. I've attempted String.toList which results in a (List 
> Char) type, but what should I do with Char? Char.toCode and Char.fromCode 
> seem specifically tuned for use with keyboard events.
>
> Is there a way to handle a binary data series in Elm?
>
> Thanks,
> Duane Johnson
>

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