Nice, the search works great, gives ConcatMap as the first result for ((a -> List b) -> List a -> List b).
+1 for integer-only ranges, seems like using floats there would probably be a bad code smell. On Thu, Aug 4, 2016 at 8:10 PM, Ian Mackenzie <[email protected]> wrote: > Someone actually did implement Hoogle-like search for Elm, and it works > pretty well, although using it is probably not kind to the > package.elm-lang.org server: http://klaftertief. > github.io/package.elm-lang.org/ > > I'm all for replacing special syntax with List.range or something similar. > I'd almost be tempted to say that 'range' should only work on Int values - > I've usually found it more robust to generate float ranges with something > like List.map on a List Int, where you can very explicitly control the > number of values produced and the exact start and end. (For example, you > can divide a float range by a float step and then decide yourself whether > you want to use floor, ceil or round to choose the number of steps.) > > On Friday, 5 August 2016 07:36:42 UTC+10, Joey Eremondi wrote: >> >> If we went crazy with this, most keywords / common functions from other >>> languages would be listed as keywords for their elm equivalents >>> and it could make life easier, I imagine >> >> >> A far more robust solution is just to have Hoogle-like search, where you >> put in the type, and it tells you what functions have that type, or similar >> types. So instead of searching "flatMap" or "concatMap" or "bind", you >> search ((a -> List b) -> List a -> List b). >> >> This seems simpler than trying to keep track of what each function is >> called in ML, F#, Scala, Haskell, Lisp, etc. >> >> >> On Thu, Aug 4, 2016 at 2:31 PM, Ambrose Laing <[email protected]> wrote: >> >>> To be completely honest, I would much prefer to keep the notation, but >>> suggest a different possible solution. >>> I would not complain if the notation goes away, but I would also like to >>> hear how you feel about the following possible alternative: >>> >>> Maybe we need a formal way to associate keywords with functions and >>> notations in elm. In your specific use case, the way this >>> would work is that "range" is a keyword for [ a .. b ]. So on the elm >>> documentation page, if you type "range", it will first give you >>> all the functions which contain range as a substring (the way it does >>> now), and then after that also list all functions and/or notations >>> that contain "range" as a keyword, which should pull up [ a .. b ]. >>> >>> Another example that has bitten me personally, coming from scala, is I >>> want to know how to do a flatMap in elm. As it turns out, it >>> is called concatMap in elm. If I were coming from Haskell, I would be >>> busily searching for "bind" or something similar. The concepts >>> do not have to match exactly, they just have to be close enough, to make >>> "flatMap" and "bind" become keywords for "concatMap". >>> So if I go search for "flatMap" in the docs, I should easily find >>> "concatMap", even when elm itself does not have a flatMap function. >>> If we went crazy with this, most keywords / common functions from other >>> languages would be listed as keywords for their elm equivalents >>> and it could make life easier, I imagine. >>> >>> What do others think of this? >>> >>> The arguments against this are that we can't list every possible >>> relevant keyword that might be helpful. My response is that we just do >>> some of the obvious ones and if possible make it so that the keywords >>> can be crowdsourced from elm users. >>> >>> The only thing is I feel bad suggesting more work that Evan or someone >>> else will have to do. >>> >>> >>> >>> On Thursday, August 4, 2016 at 4:21:55 PM UTC-4, Richard Feldman wrote: >>>> >>>> Currently the way you do ranges (like, say, to create the list [ 1, 2, >>>> 3, 4, 5 ]) is this: >>>> >>>> [ 1..5 ] >>>> >>>> This comes up super infrequently, and whenever it does, it's hard to >>>> Google for - when you want to know things like "can I use variables in >>>> there?" "is [1..5] going to give me 1,2,3,4,5 or 1,2,3,4?" etc. >>>> >>>> I'd rather drop this special syntax in favor of a simple function: >>>> >>>> List.range : number -> number -> List number >>>> >>>> It'd make for one less piece of syntax to learn, would simplify the >>>> compiler, and personally I'd find it more convenient to use than the >>>> special syntax. This way when I want to know how it works I can look it up >>>> in the List docs like normal! >>>> >>>> Thoughts? >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
