Niel, Outside of flags to enable display of modules specific to each major platform (+windows, +posix, +osx) I see two options. This all depends on hoogle having some sort of list of modules for each platform, which I believe would be the main problem. 1) Show all the functions (when the number is low), but place platform specific functions under separate headers: "Windows", "Linux/BSD/POSIX", "OS X", etc. This way the users can remain as ignorant as I was and still find their data. 2) Detect the OS (when possible - perhaps difficult for the web/JS interface) and display the functions specific to the platform requesting the search. This has a small issue if you are searching on one platform and programming on/for another platform. But the flags could still be used. Thomas On Thu, Feb 19, 2009 at 9:11 AM, Neil Mitchell wrote:

Hi

http://haskell.org/hoogle/?q=socket+%2Bnetwork

By default it searches the libraries supplied with Windows apart from Network (for various technical reasons). If you add +network it will then search the network library.

What libraries should Hoogle search by default? What flags should be available to control which ones are searched? I have no idea, if you do then say what you think and why!

Thanks

Neil

On Thu, Feb 19, 2009 at 2:50 AM, Thomas DuBuisson wrote:

...

I recall that Niel made sure hoogle doesn't search through non-portable libraries (a shame), but I thought Network.Socket could be used on Windows and yet Hoogle does not give any results for 'socket' or any other functions within Network.Socket.

First, am I mistaken and Network.Socket is POSIX only? I could swear it wasn't. Secondly - is there any chance of lifting the non-portable libraries ban, Niel? From the stand point of an application developer it might not sound good, but even in Haskell some software is system level and bound to be single platform (case and point: XCB, xmonad, hsXenCtrl). Judging by the amount of research in systems level functional programming I wouldn't be surprised to see this collection grow and making functions hard to find isn't productive.

Thomas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi

1) Show all the functions (when the number is low), but place platform specific functions under separate headers: "Windows", "Linux/BSD/POSIX", "OS X", etc.

If a function isn't available on all OS's then all Hoogle would be encouraging you to do is break compatibility and stop me from using your software. If a function is only available on one OS you will certainly have to deliberately choose to search for that, and it will never show up by default. For what shows up by default I more meant other packages. Should Gtk2hs show up by default? What about tagsoup? What about base? Things like Win32 will never show up by default. Thanks Neil

This way the users can remain as ignorant as I was and still find their data.

2) Detect the OS (when possible - perhaps difficult for the web/JS interface) and display the functions specific to the platform requesting the search.

This has a small issue if you are searching on one platform and programming on/for another platform.  But the flags could still be used.

Thomas

On Thu, Feb 19, 2009 at 9:11 AM, Neil Mitchell wrote:

...

Hi

http://haskell.org/hoogle/?q=socket+%2Bnetwork

By default it searches the libraries supplied with Windows apart from Network (for various technical reasons). If you add +network it will then search the network library.

What libraries should Hoogle search by default? What flags should be available to control which ones are searched? I have no idea, if you do then say what you think and why!

Thanks

Neil

On Thu, Feb 19, 2009 at 2:50 AM, Thomas DuBuisson wrote:

...

I recall that Niel made sure hoogle doesn't search through non-portable libraries (a shame), but I thought Network.Socket could be used on Windows and yet Hoogle does not give any results for 'socket' or any other functions within Network.Socket.

First, am I mistaken and Network.Socket is POSIX only?  I could swear it wasn't.  Secondly - is there any chance of lifting the non-portable libraries ban, Niel?  From the stand point of an application developer it might not sound good, but even in Haskell some software is system level and bound to be single platform (case and point: XCB, xmonad, hsXenCtrl).  Judging by the amount of research in systems level functional programming I wouldn't be surprised to see this collection grow and making functions hard to find isn't productive.

Thomas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

...

...

1) Show all the functions (when the number is low), but place platform specific functions under separate headers: "Windows", "Linux/BSD/POSIX", "OS X", etc.

If a function isn't available on all OS's then all Hoogle would be encouraging you to do is break compatibility and stop me from using your software.

How about showing all functions, but indicating available platforms? That way, we won't go looking for functions that work on "my platform", but for functions that work on the most platforms. And if we're looking at a function that isn't portable, we'll know immediately - unless I'm explicitly in one-shot/one-platform mode, portability (or lack of) is rather important information for me. It would be ok to filter that info in some way (character codes, or green symbol if it is available on major platforms, red otherwise, with more detailed info at package level). One of the most appealing things about Haskell, usually more common with scripting languages, is that it is possible to write portable code in it. So we don't have to make extra efforts to "code for Windows" or "code for Unix" - we just have to make the small effort to ensure that we are not coding for any particular platform. The less platform-specific code, the less work when a piece of software starts being successful. It would be very nice to have this info at the package/hackage level, too, including transitive dependency chasing. That way, package authors will not accidentally depend on packages that have non-portable dependencies, but have the chance to prefere portable alternatives whenever possible (unix vs unix-compat, etc). And package users will see where "cross-platform" was sacrificed. Claus

Neil Mitchell wrote:

Hi

...

1) Show all the functions (when the number is low), but place platform specific functions under separate headers: "Windows", "Linux/BSD/POSIX", "OS X", etc.

If a function isn't available on all OS's then all Hoogle would be encouraging you to do is break compatibility and stop me from using your software. If a function is only available on one OS you will certainly have to deliberately choose to search for that, and it will never show up by default.

I see your point, but why make Hoogle less usable for people interested in writing platform-specific software in Haskell? Will you really ever be interested in running a tool that "debianises" a cabalised Haskell library? I've on several occasions been irritated that hoogle doesn't cover platform-specific APIs. I've written platform-specific software for both Windows (e.g. pretty-printing SDDL) and Linux/Unix (e.g. ptrace-based debugging) and in both cases I'm bitten by this lack in hoogle. Since then I've found Hayoo! and have partly switched to using it instead.

For what shows up by default I more meant other packages. Should Gtk2hs show up by default? What about tagsoup? What about base? Things like Win32 will never show up by default.

IMHO hoogle should show all standard libraries (x-platform and platform specific) as well as _everything_ on hackage. This would of course mean that the UI must show whether a function is x-platform or not. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts

On Sat, Feb 21, 2009 at 11:55 AM, Martijn van Steenbergen wrote:

How about allowing an extra search flag +windows that reveals windows-specific APIs? Likewise for other OS's.

Being able to enable API for a specific package requires me knowing in what package I want to look, while an OS flag doesn't, all the while still making very explicit I want to look for OS-specific API.

There aren't enough platforms supported that we need this kind of freeform flag. My preference would be for a bunch of (initially hidden, drop-down) checkboxes, that remember their state via a cookie; if I wanted to see windows-specific functions last search, chances are I still do this time.

On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:

I think the (valid) concern is that too many people are choosing platform-specific packages when there are alternatives available (albeit not as convenient in some cases), and this really hurts the Windows community because Windows is so radically different from all the other operating systems.

Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages. We've heard many times someone say, "I don't know if it works on Windows, never really thought of that."

Um, why *should* I think of that? jcc

John A. De Goes:

I think the (valid) concern is that too many people are choosing platform-specific packages when there are alternatives available (albeit not as convenient in some cases), and this really hurts the Windows community because Windows is so radically different from all the other operating systems.

Its apparent that Neil has the legitimate concern of general purpose libraries becoming or being built on platform specific pieces - a situation I also want to avoid seeing as I work on three different platforms. The point I'm trying to make is that some programs and libraries perform platform specific taskes and that's ok - there is no loss of portability because it wouldn't make sense to port them anyway. Examples include Debian/Arch packaging, X.org bindings / Window Managers, Xen system call bindings, etc. Tom

sitting in a pub with some beer having a platform war). Martijn's thoughts of +windows, +unix, +os is exactly right, I'm happy to let users say "oh, please show me these packages", but there are trade-offs in Hoogle design. If someone has some clear viewpoint on the answers, I'd love to hear them. The three problems are:

1) What packages should Hoogle search by default? All of hackage? The base libraries? Only the packages a user has installed? Only packages that make it in to the Haskell Platform?

Why not make that configurable, similar to trac's custom queries, defining several default configurations with short names (+windows, +hackage, +hp, ..), rather than trying to define one default config? The kinds of configuration option available could be taken from information available to hackage/cabal (which presumably will specify/show platforms at some point). Claus

Thomas DuBuisson wrote:

I still prefer showing all platform results sorted into separate sections with headers, but understand that I am in the minority.

You aren't alone. Labelling them prominently with POSIX, UNIX, Linux, *BSD, OSX resp. Windoze is a Good Thing: That way, noone has to dig into package docs. "Show N more results specific to platform Foo"-links would be a good idea, too. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

wren ng thornton wrote:

Lacking a wiki account, ~wren

From HWN: HaskellWiki Accounts. Ashley Yakeley can [12]create a HaskellWiki account for anyone who wants one (account creation has been disabled as a spam-fighting measure). http://article.gmane.org/gmane.comp.lang.haskell.general/16846 Peter

On 2009 Feb 21, at 20:47, Jonathan Cast wrote:

On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:

...

Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages. We've heard many times someone say, "I don't know if it works on Windows, never really thought of that."

Um, why *should* I think of that?

I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. And we have a Windows group for that. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2009/2/19 Bryan O'Sullivan :

On Wed, Feb 18, 2009 at 6:50 PM, Thomas DuBuisson wrote:

...

I recall that Niel made sure hoogle doesn't search through non-portable libraries (a shame), but I thought Network.Socket could be used on Windows and yet Hoogle does not give any results for 'socket' or any other functions within Network.Socket.

I can't suggest why the network package isn't being indexed by Hoogle, but it does indeed work on Windows and is not, as erroneously stated by another respondent, POSIX-only.

If you say so, but.. Unix domain sockets? sendFd? I can't claim *none* of it works on windows, but those functions must at best be undefined on windows - right?