Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
Hi, The best low-level foundation libraries that I know of are the Enlightenment Foundation Libraries (EFL) [1,2]. They are cross-platform : they support many backends (X11, OpenGL, framebuffer...) and are used on desktops and mobile devices (even to provide games on the French Free ISP box). It seems that they also work on exotic platforms such as Windows and Mac OS. They are fully written in C, hence are easy to build and to use from Haskell. Evas [3] is a stateful canvas onto which shapes and texts can be drawn. It supports OpenGL regions [4]. Ecore [5] is used to manage windows, timers, etc. especially with Ecore_Evas [6]. Edje allows you to clearly separate UI and the rest of the code. The same thing has been integrated into Qt with QML (and was present in Delphi decades ago ;)). It makes it easy to create animated UI, etc. Finally, Elementary is a standard widget toolkit based on Edje, Evas and Ecore. The good news is that I have been working on an Haskell binding for the EFL [7]. The bad news is that it is not complete. Evas, Ecore and Ecore_Evas are partially done but need more polishing and testing. This simple example here [8] works well in GHCI (even better than when the program is compiled because I haven't yet figured out why the text is not displayed in this latter case...). I do not plan to write bindings for Edje and Elementary as I would prefer an Haskell DSL to replace Edje and a widget toolkit on top of it (another project seems to provide some bindings for Elementary [9]). If you want to use the EFL as a "working foundation", I can try to work a little bit more on the binding. Cheers Sylvain [1] http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries [2] http://www.enlightenment.org/p.php?p=about&l=en [3] http://docs.enlightenment.org/auto/evas [4] http://docs.enlightenment.org/auto/evas/group__Evas__GL.html [5] http://docs.enlightenment.org/auto/ecore/ [6] http://docs.enlightenment.org/auto/ecore/group__Ecore__Evas__Group.html [7] https://github.com/hsyl20/graphics-efl [8] https://github.com/hsyl20/graphics-efl/blob/master/examples/Simple.hs [9] https://bitbucket.org/arrowdodger/efl-haskell Le 27/09/2013 05:32, Conal Elliott a écrit : I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI & graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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] Slightly humorous: Headhunters toolbox (example for Germany)
Hello, > I'm not sure if you're serious or not ... Well, I wasn't, actually. My previous email was an eruption of "second degré" (I guess the closest English term would be irony). > But you do realise Haskell is not a word only used to name some > programming language used by fanatic hipsters [0]? Apart the programming language, I have encountered this term only as a family name. I would find interesting to know if there is a language in which this word exists and has yet another meaning. > Other sources show growing interest in Haskell (much to the dismay of > our favorite motto). Would you accept to refer to these other sources? > Cheers, Greetings, Sylvain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slightly humorous: Headhunters toolbox (example for Germany)
Hi, the results given by the same research at the world level is worrisome: the interest in Haskell is steadily declining since 2004. Why was Haskell not successful conquering the hearts? Is it doomed to fail or is there still a chance? http://www.google.com/insights/search/#q=haskell&cmpt=q BTW, who would have thought that there is so much Haskellers in Jamaica? Cheers, Sylvain Le samedi 14 août 2010 à 21:23 +0200, Daniel Kahlenberg a écrit : > Hi list, > > stumbled across that: > http://www.google.com/insights/search/?hl=de#q=haskell&geo=DE&cmpt=q > > Greetz > Daniel > > ___ > 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
[Haskell-cafe] Re: Hackage survey
Hello, On 20-07-2010, Christopher Done wrote: > Do you value libraries/tools that are shipped through Hackage? > > * Yes, I always use only libraries/tools available on Hackage > * Yes, but if a package is not available on Hackage, I will still use it > > I'm torn between the first two. I picked the first. If it's not > available on Hackage, I will usually package it up and put it on > Hackage. (E.g. the Frisby library hasn't been on Hackage for some > reason so I uploaded it http://hackage.haskell.org/package/frisby) > I think you pick the right answer. > Anyway, I took the survey. Nice idea. How much response have you had so far? > I have 239 answers so far. This is far beyond what I expected. Right now, my problem is that polldady limits answers to 100 per month, so I will have to wait until August to be able to read 200 answers (and september for the rest). But, you can still answer to the poll -- I will probably upgrade my account to read all the answers before september ;-) If you want to know some basic things I discover: - Being able to rate/comment a package is a must have - Most common pitfalls: Difficult to choose which library to use I never thought of adding ratings/comments to my OCaml project (OASIS-DB). All your answers already clarify a very important feature missing from my project. A lot of thanks. http://oasis.forge.ocamlcore.org/oasis-db.html Regards, Sylvain Le Gall ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hackage survey
I give again the survey URL: http://polldaddy.com/s/2C49D15023CB88C6 On 20-07-2010, Ketil Malde wrote: > Ivan Lazar Miljenovic writes: > >> I'd like to request some clarification of some of the questions: > > You might want to add a "don't know" or similar option, so that people > don't have to fill in questions arbitrarily in the case they feel none > of the answers match. > You can just skip the question. No question are mandatory. >> 3. I use cabal-install only in testing my own packages (as it's easier >>to do "cabal foo" than "runhaskell Setup.hs foo"). > > I generally try to use distribution packages first, and (manually) > download from hackage in case my distribution doesn't supply what I > need. I'm not quite sure what to answer here. > I think the answer: "I use cabal-install when my Linux/Mac/Windows distribution doesn't provide the package" should be ok. Thank you for answering the survey. Regards, Sylvain Le Gall ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hackage survey
Hello, On 16-07-2010, Ivan Lazar Miljenovic wrote: > I'd like to request some clarification of some of the questions: > > 1. By "all projects", are you including one-use only scripts? How about >university assessments (when it isn't Haskell-oriented, just have to >write a program to do some simulation or something) and thus it isn't >meant to be something used by other people or used after a certain >date, etc.? > You can use cabal as a standalone build system generator. So you can use it also for unreleased projects. Using it this way shows that the tool "cabal" itself is useful. But you need to draw a line, so if you don't use it for "one-use only scripts", I think you should still answer "for all projects". But if you only use it for project that you intend to publish, you should answer "Only for projects released on Hackage". > 3. I use cabal-install only in testing my own packages (as it's easier >to do "cabal foo" than "runhaskell Setup.hs foo"). I also use >cabal-install to test which packages I have installed have newer >versions available (cabal update && cabal upgrade --dry-run) so that >I can update the Gentoo packages for them. As such, which option >should I choose from the ones offered (as none of them match my >case)? Should the question be clarified and be made more explicit? > Depending if you only use Gentoo Haskell package or not: - if you use only Gentoo packages: "No, I only use packages from my Linux/Mac/Windows distribution" - if you still have some packages installed from Cabal: "I use cabal-install when my Linux/Mac/Windows distribution doesn't provide the package" > 9. I wouldn't classify Hackage as a "tool", but even still, what happens >if we think Hackage is very important but still should be replaced? >(Playing devil's advocate here: I think it could do with some >upgrades but there's no need to completely throw out what's already >there). > It depends how strong your feeling about Hackage is: - if you say "damn it misses this or that" each time you use Hackage: "Hackage should be replaced by a better tool" - if you only have minor problems and think it is an important tool: "Hackage is a very important tool for the Haskell community" Regards, Sylvain Le Gall ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage survey
Hello dear haskellers, I am working on OASIS-DB, a tool similar to Hackage and would like to have more information on how Haskellers use Hackage. I have setup a small poll (10 questions only) with the help of John Goerzen and Don Stewart. I will be very thankful that you answer this poll: http://polldaddy.com/s/2C49D15023CB88C6 I will share the data with the Haskell community, so that we will be able to make progress on Hackage and OASIS-DB. Cheers Sylvain Le Gall ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
Le mardi 12 janvier 2010 à 21:25 +, Andrew Coppin a écrit :
Hi Andrew,
> As you can see, this conclusively proves... something.
What, exactly?
Take Eiffel in its last version: I have identified 11 keywords that are
either used for Design By Contract or source-code documentation. These
are software engineering tasks that in the other languages you cite are
not supported at the grammar level and, if ever, fulfilled by enriching
the code using comments, annotations or compiler extensions. Removed,
this make Eiffel the less "verbose" object-oriented language of your
list, excepted Smalltalk. In any case the less verbose statically typed
compiled OO language.
One factor is how rich is the set of OO constructs supported by the
language. Visibility rule keywords may shrink or extend the list of
reserved words. Same for math or logical operators: some languages
define as keyword what belongs to libraries in another. Same for
exception mechanism.
Some languages defines the code block constructs using keywords while
other use tokens that are not considered reserved words.
Contrast for example the following Ada code (4 keywords):
procedure Hello is
begin
...
end Hello;
against the equivalent C (1 keyword):
void HelloWorld()
{
...
}
or the equivalent Haskell (0 keywords):
helloworld = ...
Ada in its 71 reserved words features keywords for concurrent
programming that doesn't exist at the same level in the other languages
in your list, and an explicit "pragma" keyword to allow the programmer
to specify things like the alignement used in the generated binary. So a
significant factor in programming language "verbosity" is how much
control the language intends to give to the programmer on the
implementation level - or said otherwise how abstracted is the language
from its run-time environment.
Let me order your list:
Smalltalk: 0
Lisp: 0
Tcl: 0
Haskell: 21 *
Python: 31
C: 32 *
JavaScript: 36
Ruby: 38
---
Borland Turbo Pascal: ~50
Java: 53
Eiffel: 59
C++: 62
Interestingly enough, interpreted languages tend to need less keywords,
which support my observation above.
Let ignore C. Noticeable is Haskell, with little reserved words while
being efficiently compiled. It reflects the fact that it does not have
elaborated object-oriented constructs, that code is structured using
layout rules, that the exception and concurrency mechanisms are provided
at the library level, that there is no way to control the code
generated, and that there is no built-in support for software
engineering like the sort Eiffel provides. It reflects as well the
"expressiveness" of Haskell and how good at abstracting the description
of a computation from its run-time environment it is. But if you really
wanted to compare apples to apples you would, for instance, add GHC
pragmas and "magic" things like `par` to the mix. I wonder if the
picture would change much?
> Hmm, I wonder if there's some way to compare the size of the language
> specification documents? :-}
Maybe comparing the grammars in a standardized form (BNF) ?
Cheers,
Sylvain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: jhc 0.7.1
> There should be no excuses for not giving jhc a whirl.
Agreed.
In a lot of ways, jhc seems like a Haskell compiler done right. It
generates very fast and lean binaries - using C as an intermediary
language - which makes it a natural cross-compiler and indicates it
should not be too difficult to write a back-end for the CIL and the jvm.
On the other hand, it is still far away from GHC features-wise.
So there is definitively room for people looking to contribute to a
compiler with a high potential. Wouldn't that be fun?
Sylvain.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Le mercredi 11 février 2009 à 11:12 +0100, Daniel Kraft a écrit :
> Hi,
Hi,
> Do you think something would be
> especially nice to have and is currently missing?
In my humble opinion, Haskell presently fall short of its promises
because it does not embed theorem proving. Quickcheck-like testing is
truly great, but can not replace proofs to produce bug free software.
With use of equational reasoning + induction, one can already prove a
huge amount of useful properties of an Haskell program [1].
The idea would be to extend Haskell with a syntax to write such proofs,
and implement support for it in the GHC compiler.
This could look like:
module Integer where
..
theorem read_parses_what_show_shows :
(a :: Integer, Show a, Read a) =>
show . read a = id a
proof
axiom
In the case above, programmers may resort to the "axiom" keyword, which
would at last have the merit of explicitly document assumptions. For
axioms, one would have to fall back to quickcheck and consort, so these
tools would not be made obsolete ;)
Another example:
theorem : ( xs :: [a], ys :: [a], f :: a -> b) =>
length (map f (xs ++ ys )) = length xs + length yx
proof
length (map f (xs ++ ys )) =
length (xs ++ ys) = {- use length++ -}
length xs ++ length ys
Theorems can be named, like "length++" (which is not shown here).
Successfully proven theorems would be automatically added to the current
theorem database and could be reused in further proofs in the same
scope.
The compiler could even be instructed to make use of this database to
optimize the program.
This theorem prover could also be used to ensure the soundness of
refinement, rewrite of an obvious version of a function/module in a more
efficient but less obvious version.
Furthermore, the compiler could be instructed to generate a "proof
obligation", which would have to be discharged by the programmer.
instance Read Integer where
...
instance Show Integer where
...
constraint read_parses_what_show_shows where
(Read a, Show a) => read . show a = id a
The compiler would complain if, for any couple of Read/Show instance of
the same data type, the constraint is not proved to be satisfied.
There is more to it, of course. "Tactics" would be needed to make this
practical. Hopefully, at this stage, this project would catch interest
of the "academics", and development would take off, until we get an
almost automated theorem prover.
Haskell is a nice, mature and efficient programming language.
By its very nature it could also become a nice executable formal
specification language, provided there is tool support. This would be
quite unique[2] and there really would be no excuse to not use it in one
step or another of the development process :)
Hope I didn't uttered nonsense.
Sylvain
PS A package even exists that may serve as basis for this work
http://www.haskell.org/haskellwiki/Haskell_Equational_Reasoning_Assistant
[1] I currently think that equational reasoning + induction is
effectively enough to prove every theorems on Haskell programs. Please
somebody knowledgeable, correct me if I am wrong?
[2] I know of "B", but it is not "nice".
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linux kernel/library question
Hi Vasili, Please have a look at http://vger.kernel.org/vger-lists.html The main list is "linux-kernel". Depending on the level of your questions, you may also check "linux-newbie<http://vger.kernel.org/vger-lists.html#linux-newbie>". If it concerns a defined subsystem/architecture, there is often a relevant mailing-list. Hope it helps and happy hacking, Sylvain 2008/7/21 Galchin, Vasili <[EMAIL PROTECTED]>: > Hello, > I am working on POSIX stuff. I have used Linux as my POSIX OS and have > read source when I could find it. Does anybody in this > group of Linux newsgroup where one can ask Linux-related implementation > questions? > > Regards, Vasili > > ___ > 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
[Haskell-cafe] Re: Fwd: Parsing in Practice
Tomasz Zielonka gmail.com> writes: > The problem is that the set of LALR grammars is not closed under composition > (as I've read in some paper on GLR parsing). If I'm right, the set of unambiguous grammars is not closed under concatenation nor union. This makes things rather difficult. If you are looking for closed sets under most language operations, but deterministic parsing, you can give a look at packrat parsers, but then you may have some issues when trying to find out which language you are really defining. > On 10/18/05, Tom Hawkins confluent.org> wrote: > > Even though I hate debugging LALR(1) parsing ambiguities, > > it prevents problems. > > Yes, when you fight the conflicts, you get static guarantees in return. > I wonder how it is with GLR? You will not get any static guarantees with GLR. Until you feed the generated parser with an input that reveals an ambiguity, you will not know for sure whether such a case might occur or not. Except of course if your grammar is in one of the nice subsets of all CFGs for which you do have static guarantees, like LALR(1). But in that case, there is no point in using a GLR parser. Thus, when using a GLR parser, try to have foolproof code ready to catch an unexpected ambiguity. -- Regards, Sylvain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
