Re: [Haskell-fr] Bonjour
Bonjour, Elle fonctionne mais elle n'a jamais vraiment été active (cf https://mail.haskell.org/pipermail/haskell-fr/) Sylvain On 05/02/2020 11:22, Olivier Revollat wrote: Bonjour, Cette liste est elle toujours active ? ___ Haskell-fr mailing list Haskell-fr@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-fr ___ Haskell-fr mailing list Haskell-fr@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-fr
Re: [Haskell-fr] multilet ?
Salut, Tu peux utiliser un pattern dans un let. > let [x,y] = splitWhen (==0) [1,2,3,0,4,5,6] > x [1,2,3] > y [4,5,6] Par contre il faut être sûr que le pattern est valide sinon: *** Exception: :5:5-43: Irrefutable pattern failed for pattern [x, y] -Sylvain On 20/06/2017 09:37, Marc Chantreux wrote: salut a tous, je cherche a prendre le resultat d'un splitWhen pour affecter directement deux variables. naivement (venant de perl), j'aurais tendance à écrire: let votes, candidates = splitWhen (/= "0") $ lines getContents sauf que ca ne marche pas et google ne m'a pas été d'un grand secours (probablement parceque j'ai un pb de mot clef). si qq1 a une idée ... cordialement, ___ Haskell-fr mailing list Haskell-fr@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-fr
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=aboutl=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)
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=haskellcmpt=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=haskellgeo=DEcmpt=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
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
[Haskell-cafe] Re: Hackage survey
I give again the survey URL: http://polldaddy.com/s/2C49D15023CB88C6 On 20-07-2010, Ketil Malde ke...@malde.org wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com 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 20-07-2010, Christopher Done chrisd...@googlemail.com 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] 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
[Haskell-cafe] Re: Hackage survey
Hello, On 16-07-2010, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com 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
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 mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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: [jhc] Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
Hi, your post gave me the idea to profile the memory usage of the generated binary with valgrind. Has there been an effort in jhc to reduce the memory footprint of generated code? In this release of jhc, the problem is handled in a quite radical way. It seems that no free() is ever emitted, the allocated heap memory is not released. Well, this classifies like a bug, I guess. On the bright side, when I removed all memory deallocation from the C version, supposing (naively maybe) that it would radicaly reduce the difference in performance, jhc's still ran twice faster. Sylvain Nahas ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
Le samedi 21 mars 2009 à 09:58 -0700, Don Stewart a écrit : Oh boy. Compile with optimizations on please! ghc -O2 et al. Hi. I had done that, actually, before even my first post, and knew that it changes little to the picture, at least on my system. Please check the other post, where I publish the results with optimization turned on. http://www.haskell.org/pipermail/jhc/2009-March/000311.html I have also tested with another program, from the Great Computer Language Shootout. http://www.haskell.org/pipermail/jhc/2009-March/000313.html Sylvain Nahas ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
so compiling the others with -O is more appropriate. It seems the consensus is I should have activated optimizations. Let check that, same code in the same order (ghc, jhc, gcc). I changed only the options for ghc and gcc. Below is the Makefile, you can double check. with -O 0:09.96 real,9.86 user,0.06 sys 0:02.06 real,1.02 user,0.92 sys 0:02.80 real,2.55 user,0.00 sys with -O2 0:09.81 real,9.70 user,0.07 sys 0:01.95 real,1.01 user,0.93 sys 0:02.57 real,2.56 user,0.00 sys with -O3 0:09.86 real,9.78 user,0.06 sys 0:01.98 real,1.02 user,0.95 sys 0:02.63 real,2.64 user,0.00 sys I have tried with gcc 3.4 and 4.3.2. All results are consistent. Sylvain Nahas Makefile - OPT:=-O3 CC:=gcc-3.4 CFLAGS:=-Wall $(OPT) JHC:=/home/sylvain/bin/jhc-0.6.0/bin/jhc GHCFLAGS:=$(OPT) TIMEFMT:=-f %E real,%U user,%S sys all: test1 test2 test3 .PHONY: test1 test2 test3 test1: hello1 time $(TIMEFMT) ./$^ /dev/null test2: hello2 time $(TIMEFMT) ./$^ /dev/null test3: hello3 time $(TIMEFMT) ./$^ /dev/null hello1: hello.hs ghc $(GHCFLAGS) $^ -o $@ hello2: hello.hs $(JHC) $^ -o $@ hello3: hello.c $(CC) $(CFLAGS) $^ -o $@ clean: -rm hello1 hello2 hello3 hello.hi hello.ho hello_code ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
Hi,
This compiler is very promising, for the least.
Here is a small dummy Haskell program.
countdown :: Int - IO ()
countdown 0 = putStrLn finished
countdown x = do
putStrLn (show x)
countdown (x-1)
main = countdown 1000
and the C program that comes to closest.
#include stdio.h
int main(void)
{
int i;
for(i=0; i1000; i++)
{
printf(%d\n,i);
}
printf(finished\n);
return 0;
}
GHC is 6.10.1, gcc is 4.3.2, jhc is 0.6.0
arch is i386/Linux(Ubuntu)
$ ghc hello.hs -o hello1
$ jhc hello.hs -o hello2
$ gcc hello.c -o hello3
What about the size of the executables?
$ ls -l hello1 hello2 hello3
493567 hello1
16803 hello2
9083 hello3
let strip them.
309492 hello1
10092 hello2
5664 hello3
In the case of jhc, there is definitively room for some improvements.
I dare not say what I think of ghc.
Now, let run them.
$ time ./hello1 /dev/null
real0m12.092s
user0m12.005s
sys 0m0.052s
$ time ./hello2 /dev/null
real0m2.016s
user0m1.016s
sys 0m1.000s
$ time ./hello3 /dev/null
real0m2.609s
user0m2.588s
sys 0m0.020s
Actually, times varie between runs. It tends to decrease (except for the
ghc generated binary), so I suppose it is due to OS cache effects.
Yet, I consistently observed that, according to time, hello2 (jhc)
runs _faster_ than hello3 (gcc).
Something is wrong: how can Haskell be faster than C?
Last but not least, as well as generating fast code, jhc can make good
use of a C cross-compiler as back-end.
Well done.
Sylvain Nahas
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
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-newbiehttp://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 tomasz.zielonka at 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 tom at 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
Re: relative precedence of ! and function application
Please take me off this mailing list. I no longer have time to read it. Thank you, greg Greg Sylvain Hughes/STX Internet (arpa): [EMAIL PROTECTED] Programmer/Analysts Phone : 301 - 513 - 1622 Remember: 90% of everything is dealing with the brain-damaged.
