Re: [Haskell-cafe] Proposal: Pragma EXPORT
It also makes actual definitions cleaner/shorter rather than cluttering them with extra annotations (either PRAGMAs or public/private markers), though this is not that big of a deal. It's true, though you could get it pretty short, e.g. default private and leading ! for public. Go uses capitalization, though that's already taken for haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] plugins fails on a simple example
Any ideas what could be causing the problem? I could try creating a patch, but I have no clue where to start. Best regards, Petr Dne 09/16/2013 11:12 PM, Jeremy Shaw napsal(a): plugins probably needs to be patched[1]. I'll happily apply such a patch. - jeremy [1] or rewritten from the ground up On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák petr@gmail.com mailto:petr@gmail.com wrote: Hi, I'm playing with “plugins”, trying to evaluate a simple expression: |import Control.Monad import System.Eval.Haskell main =do let fExpr =1 + 2 :: Int r - eval_ fExpr [Prelude] [] [] [] ::IO (Either [String] (Maybe Int)) case rof Right (Just f) -do print $ f Left err - putStrLn $Error: ++ unlines err _ - putStrLn $Unknown error.| However, it fails with |Error: on the commandline: Warning: -fglasgow-exts is deprecated: Use individual extensions instead| Am I doing something wrong? How can I turn off the flag? I'm using GHC 7.6.3. Thanks, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] reifying typeclasses
Thanks to everyone who replied, indeed it looks like GADTs do what I claimed I wanted. That's neat because I've never been able to think of a use for them. However: On Sun, Sep 15, 2013 at 2:16 AM, o...@okmij.org wrote: Why not to introduce several type classes, even a type class for each method if necessary. Grouping methods under one type class is appropriate when such a grouping makes sense. Otherwise, Haskell won't lose in expressiveness if a type class could have only one method. That's a very good point too, and one I should have thought of first. It's the simplest and I think most idiomatic. Ok, I guess I'm back to not being able to think of a use for GADTs, it seems like that happens whenever I think I have a use for a fancy feature :) The main drawback of the intensional type analysis as shown in the enclosed code is that it breaks parametricity. The constraint Eq a I guess what you're saying is that since I'm implementing a typeswitch, then I lose the nice feature of typeclasses that I know it can't do anything with the value except what the typeclass provides. In a sense, it loses type safety because it's too generic. That's a good point too. No free lunch, I guess, you get one thing and lose another. Typeclasses, though, don't exploit the closed universe part, though I can't think offhand how that hurts me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] reifying typeclasses
I've been toying with using Data Types a la Carte to get type
representations, a `Typeable` class and dynamic types parameterized by a
possibly open universe:
If the universe is potentially open, and if we don't care about
exhaustive pattern-matching check (which is one of the principal
benefits of GADTs -- pronounced in dependently-typed languages), the
problem can be solved far more simply. No type classes, no instances,
no a la Carte, to packages other than the base.
{-# LANGUAGE ScopedTypeVariables #-}
module GG where
import Data.Typeable
argument :: Typeable a = a - Int
argument a
| Just (x::Int) - cast a = x
| Just (x::Char) - cast a = fromEnum x
result :: Typeable a = Int - a
result x
| Just r - cast (id x) = r
| Just r - cast ((toEnum x)::Char) = r
t1 = argument 'a'
t2 = show (result 98 :: Char)
That is it, quite symmetrically. This is essentially how type classes
are implemented on some systems (Chameleoon, for sure, and probably
JHC). By this solution we also gave up on parametricity. Which is why
such a solution is probably better kept `under the hood', as an
implementation of type classes.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Readable GHC 7.6.3 docs (Bootstrapped)
Update: some of the headers were not anchored, due to there being those accursed newlines in them. I have now corrected this, and I hope that now all headers are anchored in the way you suggested (that I found useful, too - of course. One can only wonder why the official docs aren't made thus.) Tarball available as usual, from first page (bugthunk.net). f Le 2013-09-11 14:59, Niklas Hambüchen a écrit : Looks pleasing! I have one feature request: Could you make headings links, or add anchors next to them (github readme style), such that I can directly share what I'm reading with people? On Wed 11 Sep 2013 20:31:30 JST, Obscaenvs wrote: At [1] you can find links to the GHC documentation that I use myself, since the official version is a bit too TimesNewRoman-y for my ...developed taste. It available in a downloadable Bzipped TAR aswell as being browsable online. [1] http://bugthunk.net/ /fredrik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- bugthunk.net monoid.se @MonoidSe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PSA: do not install xcode 5 if you are using ghc 7.6
Wow, thank you for the heads up! f Le 2013-09-17 05:16, Carter Schonwald a écrit : Hey everyone, if you are actively using ghc 7.6 on your mac, for now please do not install xcode 5. It will break your ghc install, because 7.6 doesn't know how to correctly use Clang for the CPP work. (ghc head / and thus 7.8 will work fine with xcode 5, thanks to some outstanding work by Austin Seipp, 7.6 does not) if you do not need xcode 5, and you're actively using ghc 7.6, stay with xcode 4.6 for now. if you installed xcode 5 because its there, and now your ghc 7.6 is occasionally giving you strange errors involving CPP parse failures on fragments like #-}, you should go to the apple developers website, download, and reinstall the xcode 4.6 CLI tools. if you need both xcode 5 and ghc in working order *right now, tomorrow*, either a) live on the wildside: test out using ghc head: also means you could play with ghc-ios too! b) if you need both in working order now, and stabilish, Darin Morrison has a set of mac-homebrew taps that should be you use https://github.com/darinmorrison/homebrew-haskell these taps should be regarded as more official and canonical than the formula's that brew provides (the normal brew ones recurrently have problems induced by folks who aren't haskell devs) c) wait a wee bit till 7.8 lands in all its glory, and have both the freshest of xcodes, and the newest of awesome ghcs tl;dr if you don't need xcode 5, having xcode 4.6 CLI tools installed will stand you in good stead. if you are on os x mavericks, or absolutely need xcode 5 installed, and you want a ghc thats already released, use darin's brew formulae https://github.com/darinmorrison/homebrew-haskell Darin and I plan to spend some time next month preparing an unofficial patched version of ghc 7.6 that should play nice with clang / xcode 5, though at such a time ghc 7.8 will be in RC status at the very least. cheers -Carter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- bugthunk.net monoid.se @MonoidSe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] name lists
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
module HelloWorld ( namelist MyDataLenses
, namelist ArithmeticOps
) where
import Control.Lens
data MyData = MyData { ... }
makeLenses ''MyDataLenses
-- makeLenses defines a namelist called MyDataLenses
namelist ArithmeticOps (add)
add = ...
namelist ArithmeticOps (sub)
sub = ...
Hi Ben,
Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?
E.g. the above could be structured as
module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData
module HelloWorld (module MyDataLenses, ...) where
...
Roman
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Pragma EXPORT
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes:
On 17 September 2013 09:35, Evan Laforge qdun...@gmail.com wrote:
snip
None of this is a big deal, but I'm curious about other's opinions on
it. Are there strengths to the separate export list that I'm missing?
I do like the actual summary aspect as you've noted, as I can at
times be looking through the actual code rather than haddock
documentation when exploring new code (or even trying to remember what
I wrote in old code).
The summary of functionality that the export list provides is a very
nice feature that I often miss in other languages.
That being said, it brings up a somewhat related issue that may become
increasingly problematic with the rising use of libraries such as
lens: exporting members defined by Template Haskell. While we have nice
sugar for exporting all accessors of a record (MyRecord(..)), we have no
way to do the same for analogous TH-generated members such as
lenses. Instead, we require that the user laboriously list each member
of the record, taking care not to forget any.
One approach would be to simply allow TH to add exports as presented in
Ticket #1475 [1]. I can't help but wonder if there's another way, however.
One (questionable) option would be to allow globbing patterns in export
lists.
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
module HelloWorld ( namelist MyDataLenses
, namelist ArithmeticOps
) where
import Control.Lens
data MyData = MyData { ... }
makeLenses ''MyDataLenses
-- makeLenses defines a namelist called MyDataLenses
namelist ArithmeticOps (add)
add = ...
namelist ArithmeticOps (sub)
sub = ...
That being said, there are a lot of reasons why we wouldn't want to
introduce such a mechanism,
* we'd give up the comprehensive summary that the export list
currently provides
* haddock headings already provides a perfectly fine means for
grouping logically related exports
* it's hard to envision the implementation of such a feature without
the introduction of new syntax
* there are arguably few uses for such a mechanism beyond exporting TH
constructs
* you still have the work of solving the issues presented in #1475
Anyways, just a thought.
Cheers,
- Ben
[1] http://ghc.haskell.org/trac/ghc/ticket/1475
pgpoddlH92BBj.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] name lists
Roman Cheplyaka r...@ro-che.info writes:
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
Hi Ben,
Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?
E.g. the above could be structured as
module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData
module HelloWorld (module MyDataLenses, ...) where
...
True. Unfortunately I've not seen much motion towards relaxing this
limitation[1].
Cheers,
- Ben
[1] http://ghc.haskell.org/trac/ghc/ticket/2551
pgpjfzeZUOpNI.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] plugins fails on a simple example
Probably just what it says -- plugins is calling ghc and passing the -fglasgow-exts flag. I would try just removing that flag. - jeremy On Tue, Sep 17, 2013 at 2:08 AM, Petr Pudlák petr@gmail.com wrote: Any ideas what could be causing the problem? I could try creating a patch, but I have no clue where to start. Best regards, Petr Dne 09/16/2013 11:12 PM, Jeremy Shaw napsal(a): plugins probably needs to be patched[1]. I'll happily apply such a patch. - jeremy [1] or rewritten from the ground up On Mon, Sep 16, 2013 at 2:49 AM, Petr Pudlák petr@gmail.com wrote: Hi, I'm playing with “plugins”, trying to evaluate a simple expression: import Control.Monadimport System.Eval.Haskell main = do let fExpr = 1 + 2 :: Int r - eval_ fExpr [Prelude] [] [] [] :: IO (Either [String] (Maybe Int)) case r of Right (Just f) - do print $ f Left err - putStrLn $ Error: ++ unlines err _ - putStrLn $ Unknown error. However, it fails with Error: on the commandline: Warning: -fglasgow-exts is deprecated: Use individual extensions instead Am I doing something wrong? How can I turn off the flag? I'm using GHC 7.6.3. Thanks, Petr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] name lists
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 12:41:05-0400]
Roman Cheplyaka r...@ro-che.info writes:
* Ben Gamari bgamari.f...@gmail.com [2013-09-17 10:03:41-0400]
Another approach might be to introduce some notion of a name list which
can appear in the export list. These lists could be built up by either
user declarations in the source module or in Template Haskell splices
and would serve as a way to group logically related exports. This
would allow uses such as (excuse the terrible syntax),
Hi Ben,
Isn't this subsumed by ordinary Haskell modules, barring the current
compilers' limitation that modules are in 1-to-1 correspondence with
files (and thus are somewhat heavy-weight)?
E.g. the above could be structured as
module MyDataLenses where
data MyData = MyData { ... }
makeLenses ''MyData
module HelloWorld (module MyDataLenses, ...) where
...
True. Unfortunately I've not seen much motion towards relaxing this
limitation[1].
Cheers,
- Ben
[1] http://ghc.haskell.org/trac/ghc/ticket/2551
I guess there simply were not many use cases for that. This may be one.
At least if we are talking about changing the compiler anyway, it's
better to stick with a well-understood and standardized mechanism.
Roman
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Opportunity with Machine Learning Startup in Northern California
Hello, My name is Charles Weitzer. I have two friends who have started a quantitative hedge fund. One has his PhD in CS from Stanford, while the other has his PhD in Statistics from Berkeley. Company has around 12 people currently. They have made some unpublished discoveries in the field of Machine Learning and in other areas as well. They are looking for an extremely talented software engineer. This position could be a simple software engineer, but it could also be where you are The Man, basically the head of systems development. These guys are going to be the next big thing in terms of quantitative strategies and systems. They are rebuilding their current system and also designing a new system. You could work on either or both. The title and level of seniority is very flexible. As well, given their returns, this is a chance to become extremely wealthy. They are currently managing a very healthy amount of capital. FYI, I am retained by them. They are located in Northern California. Their blurb below is really is just a starting point in terms of possible initial responsibility and seniority. They are flexible for the right person. Talk soon, Charles Weitzer CEO\Senior Recruiter Charles Weitzer and Associates, Inc. Global Financial Recruiting Services char...@charlesweitzer.com Voice: USA (510) 558-9182 Fast-growing systematic-trading firm seeks an exceptional software developer. You will architect and implement a diverse set of core infrastructures, including new production systems, scientific-computing environments, and modern data stores. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems and delivering complex projects on time. You should preferably have experience with high assurance, distributed, fault-tolerant systems. Experience with functional programming as well as soft real-time, low-latency, cache-friendly systems is a bonus. We are getting big fast. Willingness to take initiative, and a gritty determination to productize, are essential. Join a team that includes faculty at premier universities and PhD's from top-tier schools, led by the founder and CEO of a successful Internet infrastructure startup. You will have a high impact, and you can expect frequent interaction with the researchers, officers, and founders. Compensation and benefits are highly competitive. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Telling Cassava to ignore lines
I'm happily using Cassava to parse CSV, only to discover that non-conforming lines in the input data are causing the parser to error out. let e = decodeByName y' :: Either String (Header, Vector Person) chugs along fine until line 461 of the input when parse error (endOfInput) at ... Ironically when my Person (ha) data type was all fields of :: Text it just worked, but now that I've specified one or two of the fields as Int or Float or whatever, it's mis-parsing. Is there a way to tell it to just ignore lines that don't parse, rather than it killing the whole run? Cassava understands skipping the *header* line (and indeed using it to do the -by-name field mapping). Otherwise the only thing I can see is going back to all the fields being :: Text, and then running over that as an intermediate structure and validating whether or not things parse to i.e. float. AfC Sydney ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Telling Cassava to ignore lines
Hi, It depends on what you mean by doesn't parse. From your message is assume the CSV is valid, but some of the actual values fails to convert (using FromField). There are a couple of things you could try: 1. Define a newtype for your field that calls runParser using e.g. the Int parser and if it fails, return some other value. I should probably add an Either instance that covers this case, but there's none there now. newtype MaybeInt = JustI !Int | ParseFailed instance FromField MaybeInt where parseField s = case runParser (parseField s) of Left err - pure ParseFailed Right (n :: Int) - JustI $ n (This is from memory, so I might have gotten some of the details wrong.) 2. Use the Streaming module, which lets you skip whole records that fails to parse (see the docs for the Cons constructor). -- Johan On Tue, Sep 17, 2013 at 6:43 PM, Andrew Cowie and...@operationaldynamics.com wrote: I'm happily using Cassava to parse CSV, only to discover that non-conforming lines in the input data are causing the parser to error out. let e = decodeByName y' :: Either String (Header, Vector Person) chugs along fine until line 461 of the input when parse error (endOfInput) at ... Ironically when my Person (ha) data type was all fields of :: Text it just worked, but now that I've specified one or two of the fields as Int or Float or whatever, it's mis-parsing. Is there a way to tell it to just ignore lines that don't parse, rather than it killing the whole run? Cassava understands skipping the *header* line (and indeed using it to do the -by-name field mapping). Otherwise the only thing I can see is going back to all the fields being :: Text, and then running over that as an intermediate structure and validating whether or not things parse to i.e. float. AfC Sydney ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Telling Cassava to ignore lines
On Tue, 2013-09-17 at 19:03 -0700, Johan Tibell wrote: 2. Use the Streaming module, which lets you skip whole records that fails to parse (see the docs for the Cons constructor). Ah, that's sure to be it. Totally missed Data.Csv.Streaming. Thanks! AfC Sydney ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
