[Nix-dev] Use Haskell for Shell Scripting

Ertugrul Söylemez ertesx at gmx.de
Tue Feb 10 19:15:31 CET 2015


>>> Some of the shell tricks based on expansions are portable to Lisp,
>>> not worth it in Julia and definitely too costly in Haskell (learning
>>> Template Haskell is definitely outside my plans).
>>
>> I don't really know TH either.  Occasionally I use TH actions defined
>> in a library (for example to derive safecopy instances or, less
>> commonly, to auto-generate lenses).  But TH somehow feels wrong and
>> ugly.
>
> In both Julia and Common Lisp I use macros for many tasks and they
> make life much more comfortable. Of course, Haskell type system may
> make it hasrder to use macros.

Oh, Common Lisp (CL) macros don't correspond to TH, but rather to
regular functions in Haskell.  We have first class actions together with
lazy evaluation.  What is "code is data is code" in CL is "actions are
first class values" in Haskell.

You only need TH when you need to generate something that is not first
class, for example class instances.


>>>> However, you may want to write type signatures anyway.  It doesn't
>>>> increase your development time considerably.
>>>
>>> I also need to write matching to extract data from deep structures,
>>> no?
>>
>> I'm not sure what you mean by that.  Perhaps you can drop me an
>> off-list mail, so we can talk about your specific application.
>
> Well, it looks like field names are not scoped and if I use plain ADT
> I have to write pattern matching to extract data from a member of a
> member of a structure.

You can chain both functions and lenses.  Extraction via functions:

    (innerField . outerField) value

Extraction via lenses:

    value ^. outerField . innerField

Update via lenses:

    (outerField . innerField .~ 15) value

You can even get completely imperative by using a state monad:

    outerField . innerField .= 15
    outerField . otherInnerField .= "blah"


>> The trouble is that xmonad's idea of "set of workspaces" is encoded
>> as a list zipper.  It does not allow me to encode the tree.  It only
>> ever holds *lists* of workspaces and does not abstract over this data
>> structure.
>
> So? Keep your own structure and keep pointers to XMonad-stored
> entries.

Yes, I do that, arguably not in the most elegant way possible, because
the predefined workspace switchers and layout algorithms need to
understand my concept as well.

If xmonad would simply abstract over StackSet, it would be very easy and
transparent to do.
-------------- 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/20150210/7e53b647/attachment.bin 


More information about the nix-dev mailing list