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
I'm in the process of preparing a rather long letter. In short my response
is "Fair enough. I'll take that as a challenge." This letter is a
meta-discussion. I'm talking about what I'm talking about. I thought to
flush out some of my thoughts and respond to objections which I more than
happy to
On 05/03/10 19:28, John D. Earle wrote:
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 certai
>>> http://chadaustin.me/2010/03/your-version-control-and-build-systems-dont-scale-introducing-ibb/
>>
>> This link is crazy. He's abusing big O notation, complaining about
>> constant factors (Python starting up) then suggesting he needs to
>> reduce the algorithmic complexity. He also forgets to
On 6 March 2010 07:35, Neil Mitchell wrote:
>
>> http://chadaustin.me/2010/03/your-version-control-and-build-systems-dont-scale-introducing-ibb/
>
> This link is crazy. He's abusing big O notation, complaining about
> constant factors (Python starting up) then suggesting he needs to
> reduce the a
Hi,
As Simon says, I've got some experience using Haskell for writing
build scripts. I had a fork of the Yhc build script written in
Haskell, for example. I think it's a very good idea in general. For
GHC in particular, they currently have a build system that works,
what's the benefit of changing
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
On Fri, Mar 05, 2010 at 09:26:08PM +, Simon Marlow wrote:
> >Switching GHC to a completely new build system written completely
> >in Haskell would be the most stupid idea ever. (You know why)
>
> You're referring to bootstrapping, I presume?
Yes.
> I did think about mentioning that. Of cour
On 05/03/10 21:17, Matthias Kilian wrote:
On Fri, Mar 05, 2010 at 12:17:55PM +, 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.
I have to admit, having rewritten GHC's build system
On Fri, Mar 05, 2010 at 12:17:55PM +, 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.
> I have to admit, having rewritten GHC's build system less than a year
> ago, I'm not part
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
/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 alternative to shell
> scripts and make files. Using Haskel
On 04/03/2010 21:06, John D. Earle wrote:
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 l
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 a
21 matches
Mail list logo