Re: GSOC draft

[Alex Vong]

address@hidden (Ludovic Courtès) writes:

> Hi, Alex!
>
> Alex Vong <address@hidden> 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!