Hi Tomas,

Tomas Volf <[email protected]> skribis:

> first, let me thank you for your time and willingness to engage in this
> discussion.  For large part, let us agree to disagree, but one final
> question below, if you would have time to enlighten me.  (Well, and
> technically also one more comment.)

Thank you.  I also appreciate your critical view on this and other
matters!

> Here I do not understand.  I have read the paper while back (and enjoyed
> it), but I still do not get it.  Thunks (as implemented by (thunked))
> are not necessary for the delayed computation no?  Any lambda would
> suffice no?  So wrapping it in a lambda of a single argument (the record
> instance) instead of zero (thunk) would achieve the same result, but
> allow removing all the magic.
>
> True, it would be more verbose when getting the value
>
>     ((package-inputs pkg) pkg)
>
> versus current
>
>     (package-inputs pkg)
>
> but it would achieve the same effect right?

Yes, you are right; this is what the ‘thunked’ property does.

I chose to have a thin layer atop records to abstract this away.  That
way, one doesn’t have to explicitly write (lambda () …) and one doesn’t
have to “call” fields that happen to be thunked.  That makes the
interface simpler and leaves more freedom for the record type developer
who can easily move between thunked, delayed, or default.

Incidentally, the introduction of ‘this-package’ was made possible
thanks to this abstraction.  Without it, we’d have to change every
occurrence of:

  (package
    ;; …
    (inputs (lambda () …)))

to:

  (package
    ;; …
    (inputs (lambda (this-package) …)))

And then change:

  ((package-inputs p))

to:

  ((package-inputs p) p)

The syntactic abstraction is very helpful here.

>> The goal from day 1 has always been to allow for declarative package
>> specifications that “look” obvious and have as little boilerplate as
>> possible.
>
> One could argue that when looking at
>
>     (let ((services (modify-services ...)))
>       (operating-system
>         (inherit %base-os)
>         (services services)))
>
> it is obvious what it *should* do (and what it looks like it is doing).
> Yet here we are.  So while this change definitely satisfies the latter
> part of the goal, I still question alignment to the former.

Yeah I understand.  The “looking obvious” part is necessarily subjective
as it’s more a question of familiarity with the semantics.

Thanks,
Ludo’.

Reply via email to