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
I think you are thinking too big-system-design instead of
quick-scripting about that.
Let's say I don't draw a line between small systems and large systems
when it comes to abstractions, because algebraic abstractions are cheap.
IMO a minimum requirement for a language to be called functional
Data type declarations are not free in any case, I think.
Compared to what? Algebraic abstractions usually compile to exactly the
code you would have written if you had not used abstraction.
Well, you started talking like you were considering some limitation of
XMonad hard to work around.
Data type declarations are not free in any case, I think.
Compared to what? Algebraic abstractions usually compile to exactly
the code you would have written if you had not used abstraction.
Data type declarations have to be written. Store-everything-in-hash-
tables is slower but quicker
It's seldom that you have to write your own data types, if you don't
want to. Basic types, functions, products and coproducts can express
anything you want that isn't a tightly packed array of machine words.
But if you really want to dump everything into a table-like data
structure, you can
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
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
Also the Nix model allows us to compile all our scripts easily (just
apply a function), which might hold some benefit in terms of startup
and switch times. There is little reason to use interpreted scripts
when you have a fast compiler.
So would you say that this is preferable to the
To be fair, there is also the GNU OS, which uses Guix, although the
underlying ideas and build system (nix-daemon) are the same.
[...] As such, it's probably best for me to not talk about GNU
OS, Guix, and Guile until I get the time/willpower to explain why my
viewpoint against that project
On 09/02/15 15:22, Ertugrul Söylemez wrote:
Also the Nix model allows us to compile all our scripts easily (just
apply a function), which might hold some benefit in terms of startup
and switch times. There is little reason to use interpreted scripts
when you have a fast compiler.
So would
Maybe you need to script it properly? Maybe StumpWM is less rigid from
the beginning, though (I use it and extended it for my needs, so I can
probably answer your questions if you wonder about it; it is in Common
Lisp, by default all the splits are manual, and there are many hooks
to perform
On 09/02/15 19:56, Ertugrul Söylemez wrote:
[...]
In short: Better stop arguing against them, regardless of what your
reasons are. [...]
I'm not; I'm avoiding argument. Please don't make assumptions as to what
my reasons are! Otherwise your mind is arguing ‘for me’, but not
necessarily with
On 30/01/15 16:02, Joe Hillenbrand wrote:
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
Time to replace all shell scripts in Nix with Haskell?
No, certainly _now_ is way too early to replace _all_, but possibly
_some_, and starting with just the functional
In short: Better stop arguing against them, [...]
I'm not; [...]
Alright. =)
In the ideal graphical environment I wouldn't see any reason to close
or move a single window -- ever. Xmonad gets closer, but is still
far away.
What?!! That sounds very abstract and cool! Maybe esoteric.
Thanks! However, I'd better not switch to a WM that I wouldn't enjoy
configuring. Also I think that I've bent xmonad pretty much to its
limits and hit the abstraction wall. Nowadays my configuration is a
whole cabalised package that I install via Nix. If you're
interested, it's online
The Typed Racket idea is pretty good. I would point out, however, that
it only addresses the type-safety concern Joe brought up; not purity.
It's still pretty idiomatic Typed Racket to use side-effects and
mutation from otherwise pure code.
On Sun, Feb 1, 2015 at 12:57 AM, Michael Raskin
If only we had a way to produce multiple outputs from a single package... :)
On Jan 31, 2015, at 07:22, Ertugrul Söylemez ert...@gmx.de wrote:
There should be a pure
library derivation and a separate compiler derivation. The former
should be as small as possible. Ideally there would be
If only we had a way to produce multiple outputs from a single
package... :)
We have. The `derivation` function supports producing multiple outputs,
and I'm sure that `mkDerivation` forwards this ability.
Greets,
Ertugrul
signature.asc
Description: PGP signature
Yeah, was kidding around!
On Jan 31, 2015, at 10:47, Ertugrul Söylemez ert...@gmx.de wrote:
If only we had a way to produce multiple outputs from a single
package... :)
We have. The `derivation` function supports producing multiple outputs,
and I'm sure that `mkDerivation` forwards this
Yes, I’m planning to work on multiple outputs for ghc soon :)
On Jan 31, 2015, at 3:55 PM, Daniel Peebles pumpkin...@gmail.com wrote:
Yeah, was kidding around!
On Jan 31, 2015, at 10:47, Ertugrul Söylemez ert...@gmx.de wrote:
If only we had a way to produce multiple outputs from a
Yes, I’m planning to work on multiple outputs for ghc soon :)
Great! I'm looking forward to that. =)
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
At Sat, 31 Jan 2015 13:22:09 +0100,
Ertugrul Söylemez wrote:
[...]
I have actually experimented with using Haskell (and a few other FP
languages) as a substitute for shells.
[...]
You might be interested why Curry didn't work. Simple: I couldn't figure
out how to write a program. Actually
2015-01-31 22:24 GMT-02:00 Ertugrul Söylemez ert...@gmx.de:
What about other languages as Python, Perl etc.? I know it is against
our purity standards, but they are a far superior to Bash scripting.
Well, that's the current state of the art. They are both used in
Nixpkgs and some Nix-related
What about other languages as Python, Perl etc.? I know it is against
our purity standards, but they are a far superior to Bash scripting.
Well, that's the current state of the art. They are both used in
Nixpkgs and some Nix-related tools. They are an improvement over Bash
scripting, but I
Guix is an already existing Nix implementation in Guile. Let's take the
other path.Haskell, since the issue of closures is apparently simple.
On Sat, Jan 31, 2015 at 10:22 PM, Ertugrul Söylemez ert...@gmx.de wrote:
At this current point in time, GHC is packaged in a poor manner, with
GHC
2015-01-31 10:22 GMT-02:00 Ertugrul Söylemez ert...@gmx.de:
At this current point in time, GHC is packaged in a poor manner, with
GHC being unbelievably huge. Dynamic linking is the answer, which
isn't done by default.
I have actually experimented with using Haskell (and a few other FP
Curry is indeed a beautiful language, and is essentially a
conservative extension of Haskell. I am surprised that more Haskell
folk have not adopted it.
Well, it does lack quite a few things right now, including on the
language level. For example its way to deal with ad-hoc polymorphism is
://lists.science.uu.nl/pipermail/nix-dev/attachments/20150131/cb913c27/
attachment-0001.html
--
Message: 5
Date: Sat, 31 Jan 2015 20:51:37 +
From: Shea Levy s...@shealevy.com
Subject: Re: [Nix-dev] Use Haskell for Shell Scripting
To: Daniel Peebles pumpkin
Chicken or Scheme are not at all what at all what I was suggesting as they
offer nothing in the way of purity or type-safety, which are the primary
motivation for suggesting Haskell.
On Sat, Jan 31, 2015 at 8:12 PM, Anderson Torres
torres.anderson...@gmail.com wrote:
2015-01-31 22:24 GMT-02:00
At this current point in time, GHC is packaged in a poor manner, with
GHC being unbelievably huge. Dynamic linking is the answer, which
isn't done by default.
I have actually experimented with using Haskell (and a few other FP
languages) as a substitute for shells. It is feasible if you
If you want to impose on people to learn Haskell and Nix to contribute,
you're going to end up in a lonely island. Remember, Nix tries to be
approachable to everyone and that's why it's minimal and simple.
A lot of developers do realize that bash is terrible, but it wasn't
replaced yet exactly
Not sure if you're serious, but the last time we considered even rewriting
the scripts in C, people were mostly against that. However, I guess with
this the major opposition (can't read the source code easily) goes away,
because you can still cat the scripts. However, I'd imagine that the
startup
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
Time to replace all shell scripts in Nix with Haskell?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
On Fri, Jan 30, 2015 at 8:36 AM, Domen Kožar do...@dev.si wrote:
If you want to impose on people to learn Haskell and Nix to contribute,
you're going to end up in a lonely island. Remember, Nix tries to be
approachable to everyone and that's why it's minimal and simple.
I'll never buy the
At this current point in time, GHC is packaged in a poor manner, with GHC
being unbelievably huge. Dynamic linking is the answer, which isn't done by
default.
http://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary
Aloha,
RK.
On Sat, Jan 31, 2015 at
You linked to something from 2011. Since 7.8 (or perhaps earlier?),
it's dynamically linked by default.
On Fri, Jan 30, 2015 at 7:52 PM, Raahul Kumar raahul.ku...@gmail.com wrote:
At this current point in time, GHC is packaged in a poor manner, with GHC
being unbelievably huge. Dynamic linking
36 matches
Mail list logo
