Re: my latest blog post

[Catonano <catonano@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 10814 bytes --]

Ricardo,

you are right that in my last interaction there was some animosity and the
message was below the standard

I apologize

I see that you are maing an effort to deescalate. I appeciate that. Really

I also see that you are suggesting some techical remediation about the
store monad

And that is probably the most interesting result that came out of this
discussion until now

After all, I just wanted to understad what this monad macro does.

I'm sure you are in god faith and we are just having a misunderstanding due
to the fact that we come from different bacgrounds, even if you didn't
study computer science

In this very moment, I'm not abe to keep interacting lucidly, though

Because I lost my cool and I got tired

So I can't bring myself to read your technical contribution.

I probably need some time to regain my composture

I will probably go to the  beach to blow some steam off

I'll try again starting next monday, if you don't mind

So I can be more consequential, hopefully

For now, just a few notes

The first note is that macro expanding and macro stepping are not the same
thing


2018-06-09 14:14 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Hi Catonano,
>
> > 2018-06-09 12:39 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
> >
> >>
> >> Catonano <catonano@gmail.com> writes:
> >>
> >> > Assuming that users read academic articles about programming
> languages in
> >> > order to know your way aroung Guile is not reasonable
> >>
> >> I fail to see how this follows from Guile’s lack of a macro stepper.
> >
> >
> > Then you were not following
> >
> > Mark indicated me a paper about the first macro stepper in history
>
> I did follow the discussion and I did see Mark mentioning the paper.
> Since Guile does not *have* a macro stepper, reading a paper about how a
> macro stepper was implemented is certainly not a requirement to use
> Guile.


Ok. I was following a thought of mine, I had to mae more explicit, probably

In my view, hacking a quick and dirt macro stepper and then use it to
explore some existing macros *IS* a requirement to use guile

Because there are some macro based libraries, so using a macro stepper is a
requirement for common usage

As I wrote, if you provide a language feature, you need to provide the
tooling for it too

The fact that Guile has no macro stepper is not enough to thin that using a
macro stepper is not a requirement
It's enough to think that Guile is missing a fundamental bit

But I understand that we can disagree on this

Obviously, to implement a macro stepper it is useful to know how
> to do this.  But implementing a macro stepper is not what a Guile user
> like myself would ever do.
>

Eh.
It seemed to me that implementing a macro stepper was reqired to me in
order to undertsand some existing macros

Maybe your last techical contribution, the one that I can't read rright
now,  proves this false

I'll try again next week and report back

Thanks for clarifiyng


> >> And I have
> >> never felt the need to read computer science papers to “know my way
> >> around Guile”.  (I have not studied computer science, so it isn’t that
> >> my background allowed me to skip papers that are mandatory for other
> >> users of Guile.)
> >>
> >> The sentence above seems like an exaggeration to me.
> >>
> >
> > Ok, thans for your contribution
> >
> >
> >> (I say this with no hostility, just with surprise.)
> >>
> >
> > we have a loooong way to go
>
> I sense a lot of hostility in your responses to me and I don’t know why
> that is.  The first sentence reads like unwarranted sarcasm to me,
> because it does not seem to relate to what I wrote; the second sounds
> belittling, as if my surprise at what seems like an exaggeration to me
> is evidence of how far behind I am in my efforts to ensure that Guix and
> Guile a welcoming to newcomers.
>
> I’m sorry that you don’t find anything useful in my response above,
> which relates my personal experience with Guile as someone who is not a
> computer scientist.  I hoped it would be a useful data point.
>

I' sure it is a data point

I'm not sure what you think it means

Does it mean that I had it coming ?

You think that I indiced David Pirotte in assaulting me in that way ?



> As I find discussions like this exceptionally draining and discouraging,
> detrimental to my ability to volunteer time to free software, I will
> take some time off from this discussion after trying to respond to your
> other message to me in this thread.
>
> >> > The monad accessing the daemon, how would I delve in it ?
> >>
> >> The Guix manual should explain it fully, while assuming that the concept
> >> of a monad is known (because that’s not a Guix or Guile invention).
> >
> >
> > And how would I know what a monad is without reading academic materials ?
> >
> > Maybe Haskell is a requirement in order to use Guile//Guix ?
> >
> > "assuming that the concept of a monad is known" is a problem.
>
> By analogy, do you think that assuming the concept of recursion would be
> a problem?  Or the concept of a closure?  Would you say that this should
> be explained in the *Guix* manual?  (These are sincere questions.)
>

No.
I think they should be explained in the Guile manual, though

The edit I am proposing about macro stepping is for the Guile manual, not
the Guix one


>
> We are using both of these constructs.  We are also using delayed
> evaluation in the form of streams.  Luckily, those are provided as a
> Guile library and are thus documented in the *Guile* manual.
>

as it shoud be


>
> > Someone would want to _learn_ what a monad is AND how it can be
> implemented
> > in scheme, by dissecting this Guix macro based feature
>
> I used “,expand” in the past to see the expansion of a macro
> expression.  Here’s an example with the state monad:
>

ok, from here on I couldn't read

as I said, I'll try again

Only: macro expanding and macr stepping are not the same thing


>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,expand (with-monad %state-monad (return 1))
> $3 = (let ((value 1))
>   (lambda (state)
>     ((@@ (guix monads) values) value state)))
> --8<---------------cut here---------------end--------------->8---
>
> This shows us that returning a monadic value in the state monad is the
> same as returning a procedure that takes some state and returns it
> alongside the value.
>
> The Guix manual says about the things that we used:
>
> --8<---------------cut here---------------start------------->8---
>  -- Scheme Syntax: with-monad MONAD BODY ...
>      Evaluate any ‘>>=’ or ‘return’ forms in BODY as being in MONAD.
>
>  -- Scheme Syntax: return VAL
>      Return a monadic value that encapsulates VAL.
> --8<---------------cut here---------------end--------------->8---
>
>
> Earlier, it also says something about what monads are all about:
>
> --8<---------------cut here---------------start------------->8---
>    This is where the ‘(guix monads)’ module comes in.  This module
> provides a framework for working with “monads”, and a particularly
> useful monad for our uses, the “store monad”.  Monads are a construct
> that allows two things: associating “context” with values (in our case,
> the context is the store), and building sequences of computations (here
> computations include accesses to the store).  Values in a monad—values
> that carry this additional context—are called “monadic values”;
> procedures that return such values are called “monadic procedures”.
> --8<---------------cut here---------------end--------------->8---
>
> We’ve just seen the first part about associating “context” (in this case
> some state) with values.  The second part requires a larger expression
> to see how this is useful.
>
> The Guix manual has an example right there:
>
> --8<---------------cut here---------------start------------->8---
>  -- Scheme Syntax: >>= MVAL MPROC ...
>      “Bind” monadic value MVAL, passing its “contents” to monadic
>      procedures MPROC...(1).  There can be one MPROC or several of them,
>      as in this example:
>
>           (run-with-state
>               (with-monad %state-monad
>                 (>>= (return 1)
>                      (lambda (x) (return (+ 1 x)))
>                      (lambda (x) (return (* 2 x)))))
>             'some-state)
>
>           ⇒ 4
>           ⇒ some-state
> --8<---------------cut here---------------end--------------->8---
>
> So this is an expression that somewhat uselessly computes the number 4
> in a context where “some-state” is present.  We can use ,expand in the
> REPL to see how this works, this time with a slightly simpler
> expression that would compute 1 + 1 in some given context:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,expand (with-monad %state-monad
>                                (>>= (return 1)
>                                     (lambda (x) (return (+ 1 x)))))
> $6 = (let ((mvalue
>         (let ((value 1))
>           (lambda (state)
>             ((@@ (guix monads) values) value state))))
>       (mproc (lambda (x)
>                (let ((value (+ 1 x)))
>                  (lambda (state)
>                    ((@@ (guix monads) values) value state))))))
>   "Bind MVALUE, a value in the state monad, and pass it to MPROC."
>   (lambda (state)
>     ((@@ (guix monads) call-with-values)
>      (lambda () (mvalue state))
>      (lambda (value state) ((mproc value) state)))))
> --8<---------------cut here---------------end--------------->8---
>
> This looks similar to the previous expression (see “mvalue”).  Looking
> at the body, we see that this is a procedure that takes some state,
> computes a new value by passing the state to “mvalue”, and then passes
> that to the next action (the last lambda in the original expression).
>
> I don’t think that the presence of the relevant documentation in the
> Guix manual and the existence of a macro-expansion facility should be
> taken as evidence that we “think that the code should be kept obscure
> and unaccessible”.
>
> I would also like to state, though, that the use of the state monad is
> hardly essential for the purpose of extending or contributing to Guix.
> If you find a way to improve the existing documentation, you know from
> our past interactions that the maintainers and developers are very
> welcoming of additions or changes to the manual.
>
> --
> Ricardo
>
>

[-- Attachment #2: Type: text/html, Size: 13713 bytes --]