l...@gnu.org (Ludovic Courtès) writes: > Hi, Alex! > > Alex Vong <alexvong1...@gmail.com> skribis: > >> Deliverable: >> An extensible working bare-bone build system in Guile >> Plan: >> Idea: >> Autotool separates the configure phase and the build phase, >> in which the configure phase is responsible of probing feature >> provided by system, while the build phase actually does dependency >> tracking >> and performs the build. This is not optimal since global variables has to >> pass to another phase, one has to make sure to perform the probing >> in the right order. Also, many probing are done regardless whether they >> are needed. This causes performance issue when the result is not cached. >> So, the idea is to integrate the 2 phases, >> so that every declaration is approximately: >> (target (input ...) rule-to-make-target-from-input) >> and rule-to-make-target-from-input should return a Boolean indicates >> if the build succeed. >> For instance we can probe the C compiler using the following rule: >> (gcc () (and=> (return-path-of-gcc-if-exist-else-return-false) >> (lambda (path) (make-c-compiler path)))) >> Proof of concept: >> Incomplete port of Chicken port of PLT (now Racket) make module in Guile. >> See build instruction of <https://gitlab.com/alexvong1995/calc>, >> it uses that incomplete port to build. >> 1. Port the Chicken port of PLT (now Racket) make module to Guile. >> 2. Rewrite the make macro using syntax-rules. >> 3. Add support for feature probing. >> 4. Add support for multiple targets. (mid-term?) >> 5. Add support for parallel build and opportunistic execution. >> 6. Discuss with mentor to proceed. > > From this message it is not entirely clear to me whether Guix would be > used at all, and how things would fit together. I believe it would make > a lot of sense to use Guix to build such a thing but then of course, it > would only work for users would have a running guix-daemon. > > WDYT?
First, I have withdrawn my proposal since I think it is not good enough. Of course I will be exploring guix during summer, since it is a fun thing to do. My original thought is to first port a working make-like tool and then change it to output g-exps instead of actually performing the build. > > I would suggest looking at the prototype Make replacement that Eelco > Dolstra wrote as part of his PhD thesis on Nix: > > http://nixos.org/~eelco/pubs/phd-thesis.pdf (Chapter 10) > Thanks for the link to the paper. The paper mentioned nix expression. Is that what g-exp based on? I recently learnt monad by reading `You Could Have Invented Monads! (And Maybe You Already Have.)'. I followed the examples and worked them out in Guile. I highly recommend it to anyone who want to learn monad. I want to ask is the store-monad comparable to the state monad? In the article mentioned above, it introduces >>=, unit and lift, which always satisfy the following: let f, g be normal procedure and f* be monadic procedure 1. (>>= unit f*) === (>>= f* unit) === f* 2. (lift (compose f g)) === (>>= (lift f) (lift g)) 3. >>= is associative What are their name in the case of store-monad? I see there is >>= in store-monad, but how about the other ones? > There’s also this defunct project about a Make replacement in Guile (not > connected to Guix and Nix): > > http://home.gna.org/conjure/ > The homepage does not mention guile, is conjure written in guile? Also, the all links in `Getting the Code' section are dead. Should it be fixed? > Maybe Pjotr has other comments. > > Thanks, > Ludo’. Finally, I suggest talking about the monad in the next Guix talks, I "assert" people will love it! Thanks for your feedback!
