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] 
> <javascript:>> 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] <javascript:>.
>> 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.

Reply via email to