The Haskell platform includes two obsolete libraries, old-time and old-locale. For old-time, it also includes the preferred alternative (namely time), but I can't figure out what the recommended alternative for old-locale is.
Is this simply a shortcoming of the Platform as of now (version 2010.1.0.0), or something I've overlooked?
The libraries in the HP are by definition not obsolete. The particular names used though, are up to the maintainers. old-locale remains the preferred mechanism for manipulating locales.
In old-locale-1.0.0.5, the deprecation notice is removed: http://hackage.haskell.org/package/old-locale.
Related
Let us say that I have worked on a haskell library and am now ready to release a beta version of the software to hackage/make repo public on github etc.
Possible Solutions and why they do not work for me
Use packagename-0.0.0.1-alpha or similar.
The problem here is quite simple: The Haskell PVP Specification does not allow it: (bold is me)
The components of the version number MUST be numbers! Historically Cabal supported version numbers with string tags at the end, e.g. 1.0-beta This proved not to work well because the ordering for tags was not well defined. Version tags are no longer supported and mostly ignored, however some tools will fail in some circumstances if they encounter them.
Just use packagename-0.* until it is out of alpha/beta (and then use packagename-1.*).
The problem here is twofold:
This method would not work for describing relase candidates which are post version 1.
Programmers from other ecosystems, such as that of rust, where it is quite common to have a stable library in 0.*, might wrongly assume that this library is stable. (Of course, it could be mitigated somewhat with a warning in the README, but I would prefer a better solution still.)
So, what is the best (and most conventional in haskell) way to indicate that the library version is in alpha/beta stage of development or is a release candidate?
As far as I know, there is not a package-wide way to say this. However, you can add a module description that describes the stability of the module to each of your modules' documentation.
{-|
Stability: experimental
-}
module PackageName.ModuleName where
I'm about to get into Haskell, and I'm a bit confused why I'm recommended to install both GHC and the Haskell-platform via brew.
Isn't GHC a Haskell implementation/compiler?
When does one need the platform?
Short answer:
The Haskell Platform is a collection of stuff.
GHC is one specific component of those stuff.
Longer answer:
Usually you want to install the Haskell Platform, because then you get lots of stuff installed all in one go as opposed to having to manually set up all the pieces one at a time.
That's the purpose of the Haskell Platform.
To give some historical perspective: before the Haskell Platform was invented, GHC itself used to come with a random grab-bag of libraries.
The Haskell Platform was invented so that somebody less overworked could decide which libraries should and shouldn't be included out of the box (i.e. so the GHC people could stop thinking about libraries and go back to thinking about GHC).
It's been quite successful in that respect.
The Haskell Platform is a collection of compilers, tools and libraries for Haskell.
It currently specifies that GHC is included in the platform.
Compliant Haskell Platform packages will install GHC without additional work required on the part of the user.
I don't know the best way to solve a simple (probably) problems (hackage related).
I asked for help about it (http://stackoverflow.com/questions/12841599/haskell-hackage-ghc-and-productivity-what-to-do) but I knew not explain well.
Today, I'm with a this kin problem.
The concrete problem isn't relevant, but is it:
`Write a function that, given a string, remove diacritics.`
Example:
`simpleWord "Cigüeñal" <-> "Ciguenal"
The correct way (I think) is to use the standard Unicode normalization. In some languages/frameworks (.Net, PHP, Python, ...) exist some related function.
In Haskell, thanks to hackage community exist too:
`Text.Unicode.Normalization.normalize`
But, I couldn't install with (eg) ghc-7.4 but compact-string (that depends of) fail.
A fix for compact-string exists (compact-string-fix) then: can't I use cabal to install (directly)?, should I download and patch it?, should I look for another alternative to function about?
I explained a concrete real case (simple or complex, don't care), the question (that I ask help for) is how can, a novice haskeller, know the best way to select correct libraries, ghc correct (balanced) version, without hit a wall.
I'm really lost about it.
Really, thank you very much for any suggestion.
Best regards.
The documentation for compact-string says, "This package is obsolete. Use text instead.".
The documentation for text says, "To use an extended and very rich family of functions for working with Unicode text (including normalization, regular expressions, non-standard encodings, text breaking, and locales), see the text-icu package.".
The documentation for text-icu shows that it successfully builds on GHC 7.4 and has support for Unicode normalization.
Here's the general process I follow when deciding which packages to use. First, I try to identify multiple packages that meet my needs. Then I look more closely at each package to try to determine which ones are the best for me, according to the criteria listed below.
It's usually better to use packages that are currently maintained. To determine if a package is currently maintained, I check the "Upload date" link on the package description page. (Of course, there are some old tried-and-true packages that haven't been modified in ages because they don't need modification.)
It's usually better to use packages that are mature, so I check the version number on the package description page. A package with a version number of 7.3.5 is probably more mature than a version 0.1 package.
It's usually better to use packages that are well documented. Sometimes there's a nice example of how to use the package in the Haddock documentation (yay!). I'll also check the "Home page" link on the package description page, because often there will be more documentation there.
It's usually better to use packages that are popular, because any problems will probably be addressed quickly, and other users can answer questions. I'll usually do a Google search and see whch packages are mentioned most often on Haskell mailing lists and StackOverflow.
It's usually better to use packages that don't require a lot of packages I don't already have, so I check the "Dependencies" section on the package description page.
I tend to follow this procedure when choosing a package for any programming language, not just Haskell.
I'm in the process of generating a Haskell documentation set for Dash (http://kapeli.com/dash).
I'm trying to index the documentation found at http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/index.html, and there seems to be a complete index at http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/doc-index-All.html.
However, there seem to be a lot of libraries (base, ghc and haskell2010 are some I found), libraries which duplicate the same functions (as far as I can tell).
Which libraries should I index? What would you expect to find in a Haskell documentation browser?
Thanks!
You should cross-reference against base. The other libraries such as haskell2010 only exist to provide stable standards against older versions of the language. ghc is a developer library only, that I wouldn't expect you to be targetting.
I think there are two different issues here.
Which modules to index?
Well, if you manage to index the whole hackage, and keep your system convenient to use with so many functions, that'd be cool and very useful.
Otherwise, you can restrict yourself to the packages in Haskell Platform.
Function duplication
In Haskell modules can re-export entities (functions, types) defined in other modules. This is not specific to base vs haskell2012.
I don't know what interface you provide in your docs browser, but you could display all modules in which the entity is found. This is what Hoogle does: http://www.haskell.org/hoogle/?hoogle=Int (see the first entry there).
In Common Lisp, programs are often produced as binaries with a translator bundled inside. StumpWM is a good example.
How would one do the same with Haskell and OCaml?
It is not necessary to provide a debugger as well, as Common Lisp does, the aim is to make extensions while not depending on the whole translator package ( xmonad which requires GHC ).
P.S. I know about ocamlmktop, and it works great, except I don't really get why it requires "pervasives.cmi" and doesn't bundle it with the binary. So, best thing I can do is mycustomtoplevel -I /path/to/dir/with/pervasives.cmi/. Any way to override it?
This isn't really possible for (GHC) Haskell - you would either need to to ship the application binary + GHC so you can extend via GHC-API, or embed an extension language. I don't think there are any "off-the-shelf" extension languages to embed in Haskell at the moment, though HsLua might be close. This is a bridge to the the standard (C source) Lua. There was a thread on Haskell-cafe last month about extension languages written in Haskell, I think the answer was 'there aren't any'.
http://www.haskell.org/pipermail/haskell-cafe/2010-November/085830.html
With GHC, there is GHC-API, which allows you to embed ghci-like interpreters in your program. It's a quite low-level and often changing library, since it simply provides access to GHC internas.
Then, there is Hint, a library which aims to encapsulate ghc-api behind a well designed and more stable interface.
Nevertheless, I've recently switched from using either of these packages to using an external ghci. The external ghci process is controlled via standard input/output pipes. This change made it easy to stay compatible with GHC 6.12.x and 7.0.x, while our ghc-api code broke with GHC 7.x and hint didn't work out of the box either. I don't know whether there is a new version of hint available, which works with GHC 7.
For Ocaml, have you tried using findlib? See the section Custom Toploops.