[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)
>
> Let/in leads to a sort of vertigal zig zagging as you need to jump to the
> bottom then scan backwards for the supporting information.
This seems subjective and somewhat dependent on code style. Do you have an
example where sequentially reading the bindings causes confusion ("why
would you need to compute that?") not resolved until the returned value?
Otherwise this fails to be concrete and actionable.
> The pattern Joey suggests seems good, the counter argument though is that
> you need to check the 'in' to know if that pattern is being used so you end
> up doing the zig zag read anyway.
Coding convention around the name "result" or similar would eliminate that.
The argument regarding being able to use let/in with anonymous functions
> seems irrelevant as it's use would be a clear sign that the function should
> be broken out into a named function.
>
Janis gives a good example of when you'd want a local binding in an
anonymous function here
.
--
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] Same code generated by BuckleScriptRe: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...
Just for fun, I pasted the same code under BuckleScript playground:
https://bloomberg.github.io/bucklescript/js-demo/?gist=efaf57aef9b37a38785681ded0ba35a9
The generated code is below
```js
function testProg(n) {
var lmt = Pervasives.min(n + 1 | 0, 10);
var _i = n;
while(true) {
var i = _i;
if (i >= lmt) {
return i;
}
else {
_i = i + 1 | 0;
continue ;
}
};
}
```
Note that BuckleScript compiler is able to do type specialization for
generic comparison, also it heavily optimized curried calling convention
On Monday, December 26, 2016 at 12:44:49 PM UTC-5, GordonBGood wrote:
>
> *Synopsis:* Some, including Evan, maintain that Elm can be "faster than
> JavaScipt". While that may be true for some use cases including use of
> perhaps more efficient UI updates due to compartmentalized use of
> VirtualDOM, the actaul Javascript code generated by the compiler is not
> very efficient for many/most tight code cases. The reason is often
> unnecessary nested function calls that could easily be eliminated by making
> full use of the type information that the Elm compiler has.
>
> Part I
>
> *An example;* The following tight loop doesn't really do anything, so
> should therefore compile into the very tightest of code (and I'm not
> expecting the Elm compiler to recognize that the result is actually known
> at compile time):
>
> range : Int
> range = 10
>
> testProg : Int -> Int
> testProg n = -- do some work
> let lmt = min (n + 1) range in
> let loop i =
> if i >= lmt then i else
> loop (i + 1) in loop n
>
> which compiles to the following JavaScript:
>
> var _user$project$Temp1482759649866537$range = 10;
> var _user$project$Temp1482759649866537$testProg = function (n) {
> var lmt = A2(_elm_lang$core$Basics$min, n + 100,
> _user$project$Temp1482759649866537$range);
> var loop = function (i) {
> loop:
> while (true) {
> if (_elm_lang$core$Native_Utils.cmp(i, lmt) > -1) {
> return i;
> } else {
> var _v0 = i + 1;
> i = _v0;
> continue loop;
> }
> }
> };
> return loop(n);
> };
> All right, the code looks fairly good, and we can see that for the inner
> `loop` function that the compiler used its new capability to do tail call
> optimization and turn it into a while loop. Also, one might expect that
> any decent JIT compiler such as Chrome V8 will use constant folding and get
> rigd of the `_v0 variable. However, the real limitation of this loop is
> the call to the `Native_Utils.cmp` function. Function calls are expensive
> at 10's of CPU clock cycles each!
>
> The pertinent JavaScript for `Native_Utils.cmp` is as follows:
>
> var LT = -1, EQ = 0, GT = 1;
>
> function cmp(x, y)
> {
> if (typeof x !== 'object')
> {
> return x === y ? EQ : x < y ? LT : GT;
> }
> ...
>
> Note that there are three native branches here (in addition to the
> enclosing one): one for the check to see it the arguments are objects
> (which of course they are not in the case of Int's as here or Float's as
> the compiler well knows), one to check if they are equal. and (given that
> generally they won't be equal most of the time) one to see which is
> greater. Now these conditions are not so bad by themselves as they are
> very predictable for modern CPU's branch prediction (i is almost always <
> lmt), so that will cost at most a few CPU cycles; However, the call to the
> function in the first place will cost 10's of CPU clock cycles!
>
> Given that the compiler already knows and strictly enforces that the
> arguments are both Int's or Float's (which are both just Numbers in
> JavaScript), there is no reason that it cannot directly output (i >= lmt)
> instead of the function call and make the whole inner loop take only a few
> CPU clock cycles (on a JavaScript engine such as Chrome V8). If the
> compiler were consistent in applying this specialization rule, there would
> be no need for the `Native_Utils.cmp` function to do the check if the
> arguments are objects, but for safety's sake and considering that one extra
> check in the case of objects is likely negligible compare to the object
> processing, it may as well be left in for its true best use case of
> comparing objects of the various kinds.
>
> *The Elm Compiler only deals with two primitive types: Int and Float
> (which are both actual Number/Float to JavaScript), which makes direct use
> of primitive operands very easy*
>
> *Part II*
>
> In a similar way, the definition of the Bitwise library to emulate
> Haskell's definition of the Data.Bits library was silly for only five Int
> functions, made even worse by a name collision with the Bool `xor`
> operator. Because these are library functions, there is at least one level
> of function call for every use.
>
> *Just as for the above function call for known primitive types (in this
> case only for Int), these functions should be added to the Basics library
> as operators w
[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)
As a non haskeller I do find my something constantly wishing that where expressions had been chosen instead if let/in. Let/in leads to a sort of vertigal zig zagging as you need to jump to the bottom then scan backwards for the supporting information. In other languages I've always ordered my methods as per the where expression (I think it was a practice I picked up from Kent Beck who recommended it for readability) and while I can order my functions this way at the module level I do miss it with let/in. The pattern Joey suggests seems good, the counter argument though is that you need to check the 'in' to know if that pattern is being used so you end up doing the zig zag read anyway. That being said I favour the simplicity of a single form, I just wish where had been chosen instead of let/in. The argument regarding being able to use let/in with anonymous functions seems irrelevant as it's use would be a clear sign that the function should be broken out into a named function. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)
Those in favor of where clauses, would you mind summarizing any arguments from the thread that do not rely on personal preference but concrete improvements to code readability or maintainability, in a way not achieved by Joey's suggestion? We are looking for code examples in which where-clauses either let you do something let-clauses don't, or are visibly superior to them. I'll put forward Janis's concern that where clauses don't work as well in anonymous functions, eg. List.indexedMap (\i x -> let bar = f x.foo in g i bar) aList (I'm not entirely sure why this wouldn't work with where-clauses, but Janis knows his stuff.) Also, have where-clauses been requested by anyone who does not know Haskell? I think let-clauses are much more natural coming from imperative languages, and Elm's target audience is JS devs, not Haskell devs. This discussion seems to be "features for feature's sake" to me, rather than "features that are a solution to a problem". My question is, what is the problem that where-clauses solve when we have let-clauses? How do they solve the problem of local constants in a way superior -- by more than mere personal preference -- to let-clauses? -- 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: Feature: 'where' expressions (continued from GitHub)
On Friday, December 30, 2016 at 5:34:20 PM UTC, Lourens Rolograaf wrote: > > Please no. Not every Haskell feature should have a place in elm, > especially if there is already a construct that works (and overlaps 100%?) > Please do not make elm2016, elm2017 or coffeeElm, with all kinds of > syntactic sugar because some user from another language still thinks this > way. > +1 from me. Very much enjoying how Elm is keeping things simple and trying to avoid overlapping features. -- 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] Mutually dependent types
On Friday, December 30, 2016 at 1:48:31 PM UTC, Joey Eremondi wrote:
>
> You need to use type, not type alias, for mutual recursion. Type aliases
> are just ways to give a type a new name, and are expanded in the compiler,
> which would not terminate if recursion was allowed.
>
Also you will have to specify the Team for a Player, but that Team will
need to list its Players, which will need to specify their Teams, and so
on... infinitely.
You could do:
type Player = Player { team : Maybe Team }
type Team = Team { players : Maybe List Player }
or some variant thereof. That would allow you to hold as much or as little
of the recursive relationship as you want to.
--
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] Every textarea should be keyed?
Hi, I experienced a strange problem today that I solved by defining a key for every textarea in my code base (wrapping a Html.Keyed.node “div” around the text area). What I specifically did is replaced all Html.textarea calls with a call to: safeTextarea : String -> List (Html.Attribute msg) -> List (Html.Html msg) -> Html.Html msg safeTextarea key attrs0 children = let attrs = (name key) :: (id key) :: attrs0 in Html.Keyed.node "div" [] [ ( key, textarea attrs children ) ] Textarea DOM nodes have internal state and so making them keyed is not quite as random as it sounds. This is a little side project that I’ve been working on for a few months now, it’s only about 2000 sloc. It’s been behaving just fine until this morning when I made some change (I don’t know what, but I think it was adding a term to my Msg type) and two text areas began sharing content. This happened in Chrome, Safari, and Firefox. In all three cases inspecting the textarea showed the text I expected, not the text that was displayed. ** This problem started with a change remote from the existing textareas, and only affected two of eight or nine textareas ** I don’t think this is quite a reportable issue with elm, but maybe. If it is then the fix is to require keyed textareas. Cheers, Bob -- 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...
The promise of never needing to really get dirty and debug live Elm code is real, and it's true that nothing else quite lives up to that. I wrote some notes on getting ghcjs up and running earlier. The basic trick is to ignore the initial README documentation and look on the wiki, following the directions for your specific haskell version. For 7.10: I used ghc 7.10, which doesn’t work out of the box with ghcjs. I cloned ghcjs master and used these instructions: https://github.com/ghcjs/ghcjs/wiki/GHCJS-with-GHC-7.10 from the wiki to install it properly. The quick start on the ghcjs readme doesn’t quite mention everything. In particular, you must bootstrap like: ghcjs-boot --dev --ghcjs-boot-dev-branch master --shims-dev-branch master On Fri, Dec 30, 2016 at 5:27 AM, GordonBGood wrote: > Art, thanks for your input. I do like Haskell-like syntax and programming > model (something like Elm) so I haven't tried Fable yet, although F# syntax > is alright. Based on what you are saying and my trials, everything (really > incluing Elm) is still in too unstable stage, although Elm is somewhat > usable (although slow) as it is. > > I did the following: > >1. Tried PureScript in the browser on their "try" website and found >that although I could reasonably quickly get used to its changed syntax and >type class model from Haskell, libraries aren't very stable in that >although I could write and compile successfully a simple little >Data.List.Lazy progression, it would fail silently for some program >variations and blow up with a stack overflow for others; I think it is >inconsistent in applying force to the lazy stream with the library >functions. >2. I tried installing GHCJS since it doesn't have a try website, and >found that not smooth at all, with broken version references in the cabal >file. Eventually I got it to install with a patched version that someone >had contributed, but couldn't get the ghcjs-boot to build the libraries as >per the instructions because some parts weren't installed where the OS >could find them (more patches, messing around required) - not stable enough >if it takes all this work! >3. I haven't tried Fable, but from what you are saying it will >probably install but you are saying that the code output sometimes isn't >very good, with no package subsystem. >4. I tried Kotlin for generating JavaScript but found that although it >generates code for the JVM fine, it still isn't very stable for producing >JavaScript code, and only versions in development have some success at all >(with tail call optimization that works for JVM not working for > JavaScript). > > So it's back to using Elm for the front end and TypeScript/JavaScript, > which are stable, for the stuff that needs to be faster until some of > these, hopefully GHCJS but PureScript would be acceptable get more stable > and work consistently. Elm compiling to more efficient code would also > fill my needs. > > By the dates on the latest PR commits and how much there is to do, > PureScript, and Fable have the best chance of getting there reasonably > quickly, with Elm also actively developed, but I think we are looking at a > minimum of a year for any of them to get to stable status. > > On Thursday, 29 December 2016 22:23:50 UTC+7, art yerkes wrote: >> >> I can comment a bit on purescript and fable (and ghcjs) from a n00b >> perspective in all three. >> >> - Purescript's type system is not as well polished as haskell and has IMO >> a steeper learning curve. >> - Purescript's package ecosystem is very immature. >> - Purescript's js interop is very easy and doesn't fight at all. >> - GHCJS speed was surprisingly fast and it has concurrency features >> builtin (such as calling haskell from javascript with and without a wait >> for a result, chans etc). >> - GHCJS has the full haskell package set, but pins some emulated packages >> at specific versions, so some caveats apply. >> - GHCJS interop allows you at the core to just define javascript to run >> inline, but seems to be in flux in recent versions. I was able to use the >> basic interop features but couldn't find current docs on advanced ones. >> - Fable's type system has everything from .net, including classes and >> interfaces that work as you expect. It's basically the same type system as >> kotlin plus proper sum types and convenient product types. The fable >> language output isn't as perfectly stable and mature as others however and >> the type system has a hole: some functions are invisibly curried >> (temporaries, non-exported functions in a module), and some invisibly >> javascript-style (exported ones in a module, interface methods). >> - Fable's package ecosystem is basically nonexistent, and pure F# >> generally won't work if it relies on unemulated stuff from System.* but js >> interop is easy. >> - Fable's interop is mature and pretty good. It lets you just formula
Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)
> > we have legitimate issues with "let". Issues that cannot be solved with the pattern I listed? Also, are these issues that are purely stylistic and preferences, or are they actually blocking or hurting development, and if so, please tell concretely how that is happening. On Fri, Dec 30, 2016 at 1:24 PM, Colin Woodbury wrote: > As a poster from the original thread on Github, I encourage anyone on here > who hasn't read it in its entirety to do so. The "pro-where" camp is not > just Haskell whiners, we have legitimate issues with "let". > > On Friday, 30 December 2016 09:10:52 UTC-8, Will White wrote: >> >> Continued from https://github.com/elm-lang/elm-compiler/issues/621. >> > -- > 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] Re: Feature: 'where' expressions (continued from GitHub)
As a poster from the original thread on Github, I encourage anyone on here who hasn't read it in its entirety to do so. The "pro-where" camp is not just Haskell whiners, we have legitimate issues with "let". On Friday, 30 December 2016 09:10:52 UTC-8, Will White wrote: > > Continued from https://github.com/elm-lang/elm-compiler/issues/621. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)
I think the strongest argument is that, if you really want where expressions, you can just do this: Translate some_expresssion_with_p1_to_pk where p1 = e1 ... pk = ek into let ret = some_expresssion_with_p1_to_pk p1 = e1 ... pk = ek in ret You get the advantage of a where expression: the primary thing you're talking about comes first. It works because all Let blocks in Elm are mutually-recursive, so the ordering doesn't matter. But, it's just a pattern with existing syntax, instead of new sugar, which is more inline with the Elm philosophy. On Fri, Dec 30, 2016 at 11:34 AM, Lourens Rolograaf wrote: > Please no. Not every Haskell feature should have a place in elm, > especially if there is already a construct that works (and overlaps 100%?) > Please do not make elm2016, elm2017 or coffeeElm, with all kinds of > syntactic sugar because some user from another language still thinks this > way. > > Op vrijdag 30 december 2016 18:10:52 UTC+1 schreef Will White: >> >> Continued from https://github.com/elm-lang/elm-compiler/issues/621. >> > -- > 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] Re: Feature: 'where' expressions (continued from GitHub)
Please no. Not every Haskell feature should have a place in elm, especially if there is already a construct that works (and overlaps 100%?) Please do not make elm2016, elm2017 or coffeeElm, with all kinds of syntactic sugar because some user from another language still thinks this way. Op vrijdag 30 december 2016 18:10:52 UTC+1 schreef Will White: > > Continued from https://github.com/elm-lang/elm-compiler/issues/621. > -- 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] Feature: 'where' expressions (continued from GitHub)
For those not following the bug, the question is: What real-world problems do you have (if any) that would be solved by a Haskell-like `where` syntax, which are not already solved by the current `let...in` syntax? On Fri, Dec 30, 2016 at 6:10 PM Will White wrote: > Continued from https://github.com/elm-lang/elm-compiler/issues/621. > > > > > > > > > -- > > > 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] Feature: 'where' expressions (continued from GitHub)
Continued from https://github.com/elm-lang/elm-compiler/issues/621. -- 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] where vs let (cont'd)
For continuation of this thread: https://github.com/elm-lang/elm-compiler/issues/621 -- 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] Mutually dependent types
You need to use type, not type alias, for mutual recursion. Type aliases
are just ways to give a type a new name, and are expanded in the compiler,
which would not terminate if recursion was allowed.
On Dec 30, 2016 7:39 AM, "Marco Perone" wrote:
You're right! Sorry for the dumb question...
I need to use something like
type alias Player =
{ ...
, team : TeamId
}
2016-12-30 14:17 GMT+01:00 Cristian Garcia :
> Is it even posible to have such a type in the Elm type system? I dont
> think you can call this type recursive, it looks like an infinite type.
>
> On Fri, Dec 30, 2016, 03:29 Marco Perone wrote:
>
>> I have two types
>>
>> type alias Player =
>> { ...
>> , team : Team
>> }
>>
>> type alias Team =
>> { ...
>> , players : List Players
>> }
>>
>> which clearly have a circular dependency. I am duplicating data and I am
>> doing that on purpose.
>>
>> Now the question is: is it possible is some way to have these two types
>> in different modules/files? Or must I have them in the same module/file to
>> avoid circular dependencies?
>>
>> --
>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/elm-discuss/si6DOd-rol8/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.
--
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] Mutually dependent types
You're right! Sorry for the dumb question...
I need to use something like
type alias Player =
{ ...
, team : TeamId
}
2016-12-30 14:17 GMT+01:00 Cristian Garcia :
> Is it even posible to have such a type in the Elm type system? I dont
> think you can call this type recursive, it looks like an infinite type.
>
> On Fri, Dec 30, 2016, 03:29 Marco Perone wrote:
>
>> I have two types
>>
>> type alias Player =
>> { ...
>> , team : Team
>> }
>>
>> type alias Team =
>> { ...
>> , players : List Players
>> }
>>
>> which clearly have a circular dependency. I am duplicating data and I am
>> doing that on purpose.
>>
>> Now the question is: is it possible is some way to have these two types
>> in different modules/files? Or must I have them in the same module/file to
>> avoid circular dependencies?
>>
>> --
>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/si6DOd-rol8/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: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...
Art, thanks for your input. I do like Haskell-like syntax and programming model (something like Elm) so I haven't tried Fable yet, although F# syntax is alright. Based on what you are saying and my trials, everything (really incluing Elm) is still in too unstable stage, although Elm is somewhat usable (although slow) as it is. I did the following: 1. Tried PureScript in the browser on their "try" website and found that although I could reasonably quickly get used to its changed syntax and type class model from Haskell, libraries aren't very stable in that although I could write and compile successfully a simple little Data.List.Lazy progression, it would fail silently for some program variations and blow up with a stack overflow for others; I think it is inconsistent in applying force to the lazy stream with the library functions. 2. I tried installing GHCJS since it doesn't have a try website, and found that not smooth at all, with broken version references in the cabal file. Eventually I got it to install with a patched version that someone had contributed, but couldn't get the ghcjs-boot to build the libraries as per the instructions because some parts weren't installed where the OS could find them (more patches, messing around required) - not stable enough if it takes all this work! 3. I haven't tried Fable, but from what you are saying it will probably install but you are saying that the code output sometimes isn't very good, with no package subsystem. 4. I tried Kotlin for generating JavaScript but found that although it generates code for the JVM fine, it still isn't very stable for producing JavaScript code, and only versions in development have some success at all (with tail call optimization that works for JVM not working for JavaScript). So it's back to using Elm for the front end and TypeScript/JavaScript, which are stable, for the stuff that needs to be faster until some of these, hopefully GHCJS but PureScript would be acceptable get more stable and work consistently. Elm compiling to more efficient code would also fill my needs. By the dates on the latest PR commits and how much there is to do, PureScript, and Fable have the best chance of getting there reasonably quickly, with Elm also actively developed, but I think we are looking at a minimum of a year for any of them to get to stable status. On Thursday, 29 December 2016 22:23:50 UTC+7, art yerkes wrote: > > I can comment a bit on purescript and fable (and ghcjs) from a n00b > perspective in all three. > > - Purescript's type system is not as well polished as haskell and has IMO > a steeper learning curve. > - Purescript's package ecosystem is very immature. > - Purescript's js interop is very easy and doesn't fight at all. > - GHCJS speed was surprisingly fast and it has concurrency features > builtin (such as calling haskell from javascript with and without a wait > for a result, chans etc). > - GHCJS has the full haskell package set, but pins some emulated packages > at specific versions, so some caveats apply. > - GHCJS interop allows you at the core to just define javascript to run > inline, but seems to be in flux in recent versions. I was able to use the > basic interop features but couldn't find current docs on advanced ones. > - Fable's type system has everything from .net, including classes and > interfaces that work as you expect. It's basically the same type system as > kotlin plus proper sum types and convenient product types. The fable > language output isn't as perfectly stable and mature as others however and > the type system has a hole: some functions are invisibly curried > (temporaries, non-exported functions in a module), and some invisibly > javascript-style (exported ones in a module, interface methods). > - Fable's package ecosystem is basically nonexistent, and pure F# > generally won't work if it relies on unemulated stuff from System.* but js > interop is easy. > - Fable's interop is mature and pretty good. It lets you just formulate > javascript to have in the literal generated code, replacing a specific > function call. > > On Thursday, December 29, 2016 at 3:51:50 AM UTC-8, GordonBGood wrote: >> >> >> >> On Thursday, 29 December 2016 09:47:13 UTC+7, Martin DeMello wrote: >>> >>> On Wed, Dec 28, 2016 at 6:25 PM, GordonBGood wrote: Related to speed, it seems to me that the working Fable (F#) code linked from your link above is more responsive than the working Elm code from another link on that page, both for the same sample application; am I imagining things or do you see that too? >>> >>> yes, but it seems to be due to a slower load time from the backend >>> rather than any perceptible frontend differences. >>> >>> martin >>> >> >> Do you know anything about PureScript as compared to Fable and Elm >> (according to the article it sits somewhere betwee
Re: [elm-discuss] Mutually dependent types
Is it even posible to have such a type in the Elm type system? I dont think
you can call this type recursive, it looks like an infinite type.
On Fri, Dec 30, 2016, 03:29 Marco Perone wrote:
> I have two types
>
> type alias Player =
> { ...
> , team : Team
> }
>
> type alias Team =
> { ...
> , players : List Players
> }
>
> which clearly have a circular dependency. I am duplicating data and I am
> doing that on purpose.
>
> Now the question is: is it possible is some way to have these two types in
> different modules/files? Or must I have them in the same module/file to
> avoid circular dependencies?
>
> --
> 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] What is this? type Decoder a = Decoder
Ignore it. It’s an internal detail, “cheating” the Elm type system inside the core library, because the Decoder type is actually implemented in JavaScript. That strange definition inside Elm is just a placeholder to prevent the compiler from complaining. 2016-12-30 0:17 GMT+01:00 Adrian Ribao : > Hi, > > I'm reading the source code of Json/Decode.elm and I find this code: > > type Decoder a = Decoder > > I've been working with elm for a few days now and I don't know what this > does exactly. I guess is a recursive union type, but I don't understand how > it works or why is useful. > > Thanks, > > Adrián > > -- > 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] What is this? type Decoder a = Decoder
Hi, I'm reading the source code of Json/Decode.elm and I find this code: type Decoder a = Decoder I've been working with elm for a few days now and I don't know what this does exactly. I guess is a recursive union type, but I don't understand how it works or why is useful. Thanks, Adrián -- 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: Unable to render updates to text fields in Elm 0.18
What a garden path! Glad you figured it out.
On Thu, Dec 29, 2016 at 5:23 PM, Chris Van Vranken <
cessationoft...@gmail.com> wrote:
> Thanks. I ran your example with elm-reactor and it worked, so at least I
> could be sure it wasn't elm's fault.
>
> But the code wasn't significantly different than mine. So I started
> stripping code out of my program to identify the source of the problem.
> Stripped it down to nothing without success. But I was hosting it on an
> ASP.NET MVC development server. So I finally ran the simple version with
> elm-reactor and it worked from elm-reactor but not from ASP.NET MVC
> hosted webpage.
>
> I finally found that the problem was coming from how I was loading the elm
> script in the ASP.NET page.
>
> I had been loading the elm script with this line:
> @Scripts.Render(System.Web.Optimization.BundleTable.
> Bundles.ResolveBundleUrl("~/bundles/distjs", true))
>
> instead of
>
> @Scripts.Render("~/bundles/distjs")
>
> Which has the nice effect of letting me simply reload the webpage to
> update my elm script, instead of restarting my server. But it has the
> downside of breaking certain aspects of Elm's rendering process. Was
> extremely weird and hard to pin down.
>
> Chris
>
> On Tuesday, December 27, 2016 at 7:16:30 PM UTC-5, Duane Johnson wrote:
>>
>> Using your code snippet, I created a project that changes the text value,
>> as you would expect it to do. Is my code set up differently than yours?
>>
>> https://github.com/canadaduane/elm-dd
>>
>> Initial state and "after clicking" state images are attached.
>>
>> -- Duane
>>
>>
>>
>>
>> On Tuesday, December 27, 2016 at 4:02:28 PM UTC-7, Chris Van Vranken
>> wrote:
>>>
>>> I am trying to render a text
>>> field
>>> with Elm 0.18. The text is wrapped in a div and I need to re-render it
>>> when my model changes. It will not update after the initial render, so its
>>> initial value is always displayed even though the class of the div updates
>>> properly and the style obviously changes. If I change the Html.text to
>>> Html.input and set the input's value then the value changes are displayed
>>> properly (but the styling is horrible). The Debug.log output also makes it
>>> seem like it should be working. I would think Html.text is pretty
>>> ubiquitous, so this seems like a silly question...but is Html.text working
>>> properly in 0.18? Any ideas why this isn't working for me? Thanks, Chris.
>>>
>>>
>>> My code comes from this example
>>> and
>>> looks like the following
>>>
>>> renderDropdownValueHtml : Dropdown -> Html Msg
>>> renderDropdownValueHtml model =
>>> let
>>> isPlaceHolder =
>>> (String.length model.value) == 0
>>>
>>> dropdownValue =
>>> if isPlaceHolder then
>>> Debug.log "Render PlaceHolder" model.placeholder
>>> else
>>> Debug.log "Render Value" model.value
>>> in
>>> div
>>> [ class <|
>>> if isPlaceHolder then
>>> "elm-dropdown__value is--placeholder"
>>> else
>>> "elm-dropdown__value"
>>> , onClick ToggleDropdown
>>> ]
>>> [ text dropdownValue
>>> ]
>>>
>>>
>>>
>>> --
> 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] Mutually dependent types
I have two types
type alias Player =
{ ...
, team : Team
}
type alias Team =
{ ...
, players : List Players
}
which clearly have a circular dependency. I am duplicating data and I am
doing that on purpose.
Now the question is: is it possible is some way to have these two types in
different modules/files? Or must I have them in the same module/file to
avoid circular dependencies?
--
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.
