On 15/07/2013, at 8:23 PM, J. Stutterheim wrote:
> The OS dependency for dynamics stems from the fact that the Clean dynamics
> are quite a bit more powerful than Haskell's. For example, using dynamics, it
> is possible to send arbitrary functions to another Clean application, which
> can then
The IDE still works for Windows, but it isn't actively developed anymore (though bugs and minor annoyances are still being fixed). For Mac and Linux we now have a command line tool that uses the IDE's codebase. Personally, I just use vim (of course you can use any editor you prefer; vim comes with
On 13/07/2013, at 11:27 PM, J. Stutterheim wrote:
>> - they then abandoned the Macintosh world for
>> Windows. The Mac IDE was killed off; there is
>> now an IDE for Windows but not MacOS or Linux.
>
> The good news is that the latest version of Clean[2] and its code
> generator[3] now works
On 12/07/2013, at 6:12 PM, Andreas Abel wrote:
[I can't try your F# example but ocaml does something different.]
Yes. They are different languages.
By the way, I used the F# that comes with Mono.
> On 12.07.2013 02:22, Richard A. O'Keefe wrote:
>> For what it's worth,
>>
>>> let x = 1 in
>> -
I currently work at the Radboud University where Clean is being developed. As
such, I use it daily. Coming from Haskell, I have to admit that I never really
got used to the let-before syntax, exactly for the reasons described in the
previous emails. However, it does have some merit. In combinati
On 12.07.2013 02:22, Richard A. O'Keefe wrote:
For what it's worth,
let x = 1 in
- let x = x+1 in
- let x = x+2 in
- x;;
prints
val it : int = 4
in the F# interactive system, but
let x = 1 in
- let x = x+1 in
- let x = x+2 in
- x;;
prints "Duplicate definition of x" at the
On 11/07/2013, at 6:16 PM, wrote:
>
> I'd like to emphasize that there is a precedent to non-recursive let
> in the world of (relatively pure) lazy functional programming.
So what? You can find precedents for almost anything.
I could even point you to a lazy mostly-functional language
with as
I'd like to emphasize that there is a precedent to non-recursive let
in the world of (relatively pure) lazy functional programming.
The programming language Clean has such non-recursive let and uses
it and the shadowing extensively. They consider shadowing a virtue,
for uniquely typed data.
Richa
Alberto G. Corona wrote:
> I think that a non-non recursive let could be not compatible with the pure
> nature of Haskell.
I have seen this sentiment before. It is quite a mis-understanding. In
fact, the opposite is true. One may say that Haskell is not quite pure
_because_ it has recursive let.
On 10/07/2013, at 8:42 PM, Andreas Abel wrote:
>>
>>> Hear, hear! In OCaml, I can (and often do) write
>>>
>>> let (x,s) = foo 1 [] in
>>> let (y,s) = bar x s in
>>> let (z,s) = baz x y s in ...
I really wish you wouldn't do that.
After reading Dijkstra's paper on the f
On 10.07.13 11:42 AM, Ertugrul Söylemez wrote:
I think we are all aware that shadowing is
a bad idea, no matter whether you do it through Identity or
non-recursive let.
WHAT??
[This is Richard Bird's WHAT?? when someone said that using folds is
like programming in assembly language.]
o...@okmij.org wrote:
> > If you would like to write
> >
> > let (x,s) = foo 1 [] in
> > let (y,s) = bar x s in
> > let (z,s) = baz x y s in
> >
> > instead, use a state monad.
>
> Incidentally I did write almost exactly this code once. Ironically, it
> was meant as a lead-on to the St
> If you would like to write
>
> let (x,s) = foo 1 [] in
> let (y,s) = bar x s in
> let (z,s) = baz x y s in
>
> instead, use a state monad.
Incidentally I did write almost exactly this code once. Ironically, it
was meant as a lead-on to the State monad.
But there have been other ca
I think that a non-non recursive let could be not compatible with the pure
nature of Haskell.
Let is "recursive" because, unlike in the case of other
languages, variables are not locations for storing values, but the
expressions on the right side of the equality themselves. And obviously it
is not
On 10.07.2013 10:16, Ertugrul Söylemez wrote:
o...@okmij.org wrote:
Hear, hear! In OCaml, I can (and often do) write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in ...
In Haskell I'll have to uniquely number the s's:
let (x,s1) =
o...@okmij.org wrote:
> Hear, hear! In OCaml, I can (and often do) write
>
> let (x,s) = foo 1 [] in
> let (y,s) = bar x s in
> let (z,s) = baz x y s in ...
>
> In Haskell I'll have to uniquely number the s's:
>
> let (x,s1) = foo 1 [] in
> let (y,s2) = ba
In my opinion, when you are rebinding a variable with the same name,
there is usually another way to structure your code which eliminates
the variable.
If you would like to write:
let x = foo input in
let x = bar x in
let x = baz x in
instead, write
baz . bar . foo $ input
If y
Hi Oleg,
just now I wrote a message to haskell-pr...@haskell.org to propose a
non-recursive let. Unfortunately, the default let is recursive, so we
only have names like let' for it. I also mentioned the ugly workaround
(<- return $) that I was shocked to see the first time, but use myself
s
Andreas wrote:
> The greater evil is that Haskell does not have a non-recursive let.
> This is source of many non-termination bugs, including this one here.
> let should be non-recursive by default, and for recursion we could have
> the good old "let rec".
Hear, hear! In OCaml, I can (and often
19 matches
Mail list logo