How is it off topic? Am I not following the instructions that were given on
the GHC Developer Wiki?
--
From: "Ian Lynagh"
Sent: 11 Thursday March 2010 0850
To: "John D. Earle"
Cc: "cvs-ghc"
Subject: Re: Fast H
lling"
Sent: 11 Thursday March 2010 0748
To: "John D. Earle"
Cc: "cvs-ghc"
Subject: Re: Fast Haskell Parser
No, it's not lazy vs. strict. Parsec's "try" switches the default
LL(1) parser to an LL(N) parser. Happy is always LALR(1), which is
some
Simon Marlow: Personally I find Parsec and the other parser combinator
libraries quite difficult to use when it comes to deciding where to put
'try'; ReadP is the exception here, because it does general backtracking and
doesn't make you decide where to use 'try'.
John
.
--
From: "Simon Marlow"
Sent: 11 Thursday March 2010 0328
To: "John D. Earle"
Cc: "cvs-ghc"
Subject: Re: Fast Haskell Parser
On 11/03/2010 01:25, John D. Earle wrote:
Hi, Ben! Thanks for the input. I went to the Parsec and Attoparsec
parser links. Atto
k you this has helped clarify my thinking.
--
From: "Ben Lippmeier"
Sent: 10 Wednesday March 2010 1734
To: "John D. Earle"
Cc:
Subject: Re: Fast Haskell Parser
Hi John,
Doing a Google search for "haskell parser"
I was thinking of ways to create an efficient Haskell parser. My initial
thinking was to write a top down parser in Haskell, but if you want speed a
table driven approach may make greater sense.
Due to the existence of build bots there is a certain degree of compliancy
concerning build times.
One of the things I was thinking about was looking at how the Tcl scripting
language and the Windows PowerShell languages do it in addition to the usual
Unix shells. The Windows PowerShell naming conventions seem particularly well
thought out. I do not like the language as a whole due to what I
This is a request for information concerning command line option conventions
that are used among the various operating systems. I intend to create a domain
specific language using quasi-quotation in Haskell that likely should use the
same command line option conventions that most people are fami
Neil,
I hope I can count on your continued support. Your comments are hoping me
refine my thinking. What I am attempting to do is ambitious and so I have my
work cut out for me.
Do I really need quasi-quotes? In a sense I will and in another I won't.
That is the best way to describe it. Ther
Dear Neil,
Neil: For GHC in particular, they currently have a build system that works,
what's the benefit of changing the build system?
John:
To make it even better. As I pointed out in my GHC ticket system feature
request ticket (http://hackage.haskell.org/trac/ghc/ticket/3912) the build
sys
aper. Trying to
be cute, you do realize that the mark of a good salesman is the ability to
sell refrigerators to Eskimos.
--
From: "Thomas Schilling"
Sent: 06 Saturday March 2010 0741
To: "John D. Earle"
Cc: "cvs-ghc
I am wondering if sending an e-mail attachment is acceptable or problematic in
an e-mail sent to a Haskell mailing list. I see that some people do this. I
would prefer to post content using TeX that is converted to PDF. I doubt anyone
will want to see a dvi or ps file which are common TeX output
As it concerns sources of inspiration is how proof assistants with dependent
types implement their module system. Traditionally, a computer programming
language consists of more than one sublanguage. A language of expressions and a
module language for example. With dependent types it becomes pos
The follow may seem a little like science fiction, but taken to its limit I do
not find it difficult to envision a single massive data stream greater than a
terabyte that consists of the entire software repository of say a corporation
or government and feeding it to the compiler that would globa
When the stream length (file size) is only a few kilobytes applying
optimizations to speed the compilation process along isn't especially
meaningful. With massive stream lengths there is economy of scale that will
likely also translate to producing better machine code and other aspects of the
p
The timing for this is good in that new technologies are coming forward that
may render the disk operating system paradigm altogether obsolete and not
merely grossly inefficient. Moving to a new paradigm now may help position us
ahead of the curve.___
Achim Schneider wrote "As it stands, GHC can't be bootstrapped without a GHC
... ." Yes, this has been my point. If this sort of dependency is to be
embraced there is no reason not to go all the way. We have already gotten to
first and second base. Now it is time to go for the gusto.
Achim Schn
I have already anticipated the objection concerning having a means to boot
strap the system. One solution is one I already hinted at. The sqlite
project solved that problem. I provided a hyperlink to the project earlier.
We could follow their lead. It is also possible to do something similar to
My ticket was just closed with a won't fix resolution. The comment was "I
think the first step would be to create a build system tool, and then we can
look at whether it makes sense to use it for GHC." On the face of it seems
some what logical. It is certainly non-committal and it isn't nurturin
Simon Marlow wrote "I suggest that the way to start would be to design and
build the
infrastructure first, and then think about replacing GHC's build system."
Simon Marlow wrote "But if someone else were to do the work, and the result was
maintainable and has at least the same functionality and
Hello,
I wish to discuss my feature request
http://hackage.haskell.org/trac/ghc/ticket/3912 entitled "Gut Build System". I
suppose the title is to the point.
I believe that considerable advantage can be achieved by positioning the GHC
Haskell language so that it may be used as a viable alterna
21 matches
Mail list logo
