go to fullhn.com lihaoyi scalatex github
no endorsement. not tried. the simple markdown RST, python ALL OF IT FAILS.
WHERE IS HASKELL? and yes it is a research language, but this is a simple question and PRACTICAL.submitted by scalatexqqqqqqqq
[link] [3 comments]
<iframe frameborder="0" height="315" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/1p8tiMbPwjx1D4bVFlmL74GvCSQT6vXx01OLDYzf4XrU/pubchart?oid=1180289639&format=interactive" width="496"></iframe><iframe frameborder="0" height="315" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/1p8tiMbPwjx1D4bVFlmL74GvCSQT6vXx01OLDYzf4XrU/pubchart?oid=1544259560&format=interactive" width="496"></iframe>
I'm wondering if there can be a "Haskell" solution for enterprise integration. Basically, you have different applications, services, endpoints, that you want to integrate within your company, or in another context in some specific way, or you want to create an ecosystem of small independent services that fuel a bigger functionality of your system. So far, this kind of development is done in an "enterprise-y" way, with huge architectures, tools and processes (things like SOA, ESBs, etc)
I wonder if there can be a solution for this based on Haskell, and/or other principles which can be easily coded in Haskell (principles based on functional programming, category theory, etc).
I recently checked out this article above, and it started out promising, pointing out this exact problem from above and stating some problems it has. But after reading it I'm not convinced it proposes a solution at all. The article above presents a solution for specific problems (restartable processes in a web application, routing, etc) that seem unrelated to EAI (Enterprise Application Integration).
My main motivation comes from seeing solutions/products like these:
When one starts using such a product, or understanding what an ESB does, you can't help but think things like "These workflows feel like they could be done so much easier with Haskell!". In the standard solution you'd need huge tools (specific IDEs with specific plugins, GUI editors, etc), and/or programming using XML files and other beans/etc; when you could instead just write it all down in a small Haskell file using higher-order-functions and the like.
Articles like the above don't seem to solve this issue for me. If you need integration between different web services, FTP servers, databases and systems, you need ESBs, or integration brokers, and all kinds of middleware where there just doesn't exist a solution for them in the Haskell community.
My main questions would be:
- Would it be straightforward to create one of those "enterprise" solutions in Haskell to be used as a library (for example an ESB with the appropriate connectors and components)?
- Do you think there is a need to create a solution in Haskell for this kind of problem in the first place? Or are we just fine with the tools that already exist (for example Mule ESB above)?
- Should the solution be just a straight Haskell port of those products, substituting the IDEs and XML files with Haskell scripts instead (but still creating ESBs, etc, that behave the same way other products do)? Or can we apply other principles behind Haskell (purity, composability, etc) to instead create a better solution for this kind of integration? How would that look like?
Thankssubmitted by gonzaw308
[link] [22 comments]
I mean logistic regression in statistical sense, with p-values and confidence interval and all, like in R.submitted by Kindlychung
[link] [11 comments]
This is something that's been crossing my mind recently. A smart constructor is a function that ensures some invariants are satisfied before constructing a value from argument(s), otherwise it results in a runtime error result. Without dependent types this tends to be the only practical way to ensure invariants on many data types. Some examples:parseURI :: String -> Maybe URI parseUrl :: MonadThrow m => String -> m Request fromList :: [a] -> Maybe (NonEmpty a) parseDecl :: String -> ParseResult Decl parseRelativeFileLoc :: MonadThrow m => FilePath -> m (Loc Relative File)
The list goes on. These are great for working on runtime values, but often enough their arguments are known at compile-time by the programmer, who would rather not therefore have to handle a pointless runtime case that will never happen, and yet doesn't want to use fromJust, because that's icky. This happens both in regular production code and in the REPL. These are the cases that I'm concerned with. I suspect that the inconvenience of this partly contributes to people not using the smart constructor abstraction as much as they otherwise would.
Suppose we write a template-haskell function which accepts a smart constructor and an argument, runs that smart constructor with the argument, and if it succeeds, returns the success value, otherwise throws a compile error.$(mk parseURI "http://chrisdone.com/") :: URI $(mk parseUrl "http://chrisdone.com/") :: Request $(mk fromList [1,2,3,4]) :: NonEmpty Integer $(mk parseDecl "x = 1") :: Decl $(mk parseRelativeFileLoc "blah.txt") :: Loc Relative File
This would clearly be nice and handy. There are two issues:
- The error result type tends to vary sometimes. Maybe, Either, ParseResult, etc. A potential solution is to get more people to use MonadThrow, which the mk function can get an Either String a out of, and print some meaningful error at compile time.
- The resulting data structure needs to be lifted from TH-stage into regular stage. One solution is to instead write $(mk 'parseURI ...), which could then be used at both compile-time and run-time, and in the run-time case it would produce a case like case parseURI ".." of Right x -> x; Left p -> error ("parseURI of " ++ show ".." ++ " failed"). This error would never happen, of course, by the guarantee of the compile-time check, but it's nice to be complete.
With the quoted 'name, you could also reify its type and specially handle older constructors that are specifically Maybe or Either or ParseResult.
If everyone exported a mkURI, mkUrl, mkNonEmpty TH function, that'd be more handy, and shorter, but with the aversion to TH I can't see that happening in general.
EDIT: Any authors like this idea? gelisam's approach of using Lift would be ideal if authors get onboard with it.submitted by chrisdoner
[link] [17 comments]
Are there any tutorials (preferably in Haskell) about implementing a simple statically typed language?
We all know about "Write your own Scheme in 48 hours", but what about a similar tutorial for implementing a simple typechecker? I think it would be interesting to see what it's like actually implementing a real type system.submitted by SkoomaMudcrab
[link] [17 comments]
When I'm writing Python, I often ask the interpreter "what can I do with x" by typing x.<tab> in IPython. Then, if something looks useful, I'll verify that it does what I want by typing x.example_fn? and reading the documentation that comes up. If the function does what I need, I'll type y = x.example_fn(...) and repeat the process with y.
This works great for the following use cases:
- Learning to use a library
- Quickly hacking together automation scripts
Is there a way to mimic this workflow in Haskell? The closest I've found is checking the type of a variable, then querying Hoogle for functions involving that type.
Edit: A partial solution is to view the type (with :t), then see what type classes are implemented for the type (with :i). However, that doesn't help with discovering functions not defined in a type class.submitted by sharewa
[link] [18 comments]
Hey guys, after reading LYAH and some more tutorials I've decided to write my first program in Haskell. It's a very simple Uno game and buggy, but it works and coding it was fun, although there's a function which I'm very discontent with: gameRound which handles a single round (i.e. ask player which card to play, play this card, update the Game accordingly).
Coming from an imperative language (Python, C++), I would do something likewhile not game.over(): player = game.next() if game.skip: game.skip = False continue move = player.getMove() if move == DRAW: move = player.getMove() elif ...: ... card = move.card player.removeCard(card) game.topCard = card
here, the game state is updated in little pieces, e.g. by game.next(), player.removeCard(...) and later settings may override previous variables (like move). The same function in Haskell took me about 80 lines, looks bad and has quite some repetition in it (e.g. topCard = card in every case). Additionally, to update a player's hand I have to construct a whole new Game. I know that some of that burden is because my data representation is bad, but generally, what's the best way to express a pattern like this in Haskell?submitted by Dunj3
[link] [14 comments]