[Nix-dev] Use Haskell for Shell Scripting

[Ertugrul Söylemez]

>> Remember that we're talking about very different paradigms.  I can
>> totally see how you would want and love macros in CL.  In CL you
>> encode your solution in such a way that using macros is the natural
>> thing to do, and then lexical manipulation is probably something that
>> comes in handy.  In Haskell your encoding is entirely different, so
>> you wouldn't use macros in the first place.  Instead you would use
>> non-strict higher-order functions together with type classes.
>
> And of course Common Lisp does have higher-order functions; do type
> classes add any encoding power? I always thought they were needed to
> keep track of all that happens, and working duck typing with optional
> multiple dispatch allows to write the same code but with less safety.

Type classes are essentially just principled overloading.  They allow
you to write reusable code bound to certain *features* (rather than
specific types):

    multiCoreMapReduce :: (Monoid b) => (a -> b) -> [a] -> b
    multiCoreMapReduce f = fold . parMap rseq f

Whenever `b` is a monoid, the above function is a multi-core MapReduce
implementation.  Here `Monoid` is a class.


> There is a myth on the Lisp side that Common Lisp has a paradigm that
> means it wouldn't benefit from some more static annotation and
> analysis features; there is a myth in many non-Lisp places that
> feature X makes macros unneeded.
>
> Both are myths. Just a trivial with-fields (in its many many forms) is
> an example of a thing that is trivial with macros, useful enough to be
> built into Object Pascal and doesn't perform its primary task
> (reducing clutter) if implemented without macros.

I couldn't find any information online about what `with-fields` is, but
From its name I'm just going to assume that it brings stuff into scope
semi-automatically, i.e. it does something a regular function cannot do.
Does a CL programmer benefit from this?  Absolutely!  Would programmers
of most languages benefit from this, for example Object Pascal?  Likely!
Would a Haskell programmer benefit from this?  Well, probably not as
much as you would want them to.

Let's turn the table:  Laziness is a very powerful feature in Haskell.
Could I convince you of that?  Probably not, because you're not a
Haskell programmer and you wouldn't find it very useful in CL.  But I
may be crazy about laziness and think:  "How can anyone deny the
usefulness of laziness?".  You're suffering from the same fallacy
w.r.t. macros.  Let me explain.

There is a *very common* myth on the CL side that macros are so powerful
and so useful in CL that they must be powerful and useful *everywhere*.
That may easily lead you into the trap of thinking that any language
that lacks macros has a serious drawback compared to CL.  But that's a
myth.

I'll assume that right now you're thinking:  "Oh, come on, macros allow
you to manipulate lexical features, scope, introduce new views to data,
build functions automatically, etc.  How can they be useless in any
language?".  I could fall into the same trap:  "Oh, come on, laziness
allows you to build virtual data structures, specify if, how and when to
evaluate (e.g. in parallel), apply semantically huge/infinite transforms
in O(1), use action DSLs, etc.  How can it be useless in any language?".
Yet it would still be pretty useless in CL.

Let me go one step further:  Macros would do more harm than good in
Haskell, if people would actually be going to use them.  In fact we do
have a similarly powerful macro system called TH.  We even have a system
for custom syntax called QuasiQuotes, if you need it.  Our TH and QQ are
even type-safe!  Yet most experienced Haskell programmers try to avoid
both of them as much as possible, and for a good reason, which is beyond
the scope of this mail.

Now macros-considered-harmful probably goes even worse against your
world-view than macros-considered-useless.  But consider this:  In a
similar way laziness would not only be pretty useless in CL, it would do
more harm than good, because it entails the kind of non-determinism that
requires all side effects to be expressed in terms of a lazy
domain-specific action language (which is our `IO`).  You probably don't
want that.  Combined with macros it would have the potential to render
CL unpredictable.


>> Modern van Laarhoven lenses are a powerful abstraction for accessing
>> data structures, mainly because a lens does not necessarily
>> correspond to a certain concrete field (it can correspond to many
>> fields or to a logical alternate view of certain data) and also
>> because both lenses and lens operators are first class values.
>
> _Which_ lenses should be used, actually? It looks like there is a
> controversy about which packages are the correct ones to use and which
> should be considered just a proof-of-concept playground for new ideas.

It doesn't actually matter.  One nice thing about van Laarhoven lenses
is that all the lens packages are compatible with each other.  Most
people use the `lens` library though, because it is very featureful.


>> That's why we love lenses.  They are more than just a recovery from
>> our lack of a decent record system.  And they are defined in plain
>> Haskell, just to show you how far we can go without macros. =)
>
> Well, you haven't yet impressed me. I knew Haskell optimiser beats
> SBCL at some tasks; just writing all this functionality without macros
> is also straightforward in Common Lisp or Racket or whatever, but
> inlining would probably be suboptimal in some cases so macros (mabe
> just compiler macros) would be a good optimisation technique to use in
> Lisp for such a task.

I'm not trying to impress you.  I'm trying to explain why we don't need
a record system (or macros or ...), and why what we have is actually
more powerful.

In fact even a fully fledged record system even with type-safe dynamic
shape changes can be encoded in plain Haskell.  See Jon Sterling's
`vinyl` library.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150211/6f4ae966/attachment.bin