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
Note that for non-recursive lets
let' x1 = e1
x2 = e2
is sequential and *not* the same as the parallel
let' (x1, x2) = (e1, e2)
The first is
(\ x1 -> (\x2 -> ...) e2) e1
and the second is
(\ (x1,x2) -> ...) (e1, e2)
On 11.07.2013 13:36, Doug McIlroy wrote:
By analogy to ML,
By analogy to ML, which has "let" and "let rec", where the latter
corresponds to Haskell's "let", one is led to "let nonrec". I
would definitely not like "shadow", for it means that new
variable does NOT cast a shadow on its definining expression.
I fear also that "let nonrec" by any name would in
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 11/07/2013, at 11:09 AM, Donn Cave wrote:
> let x = t + 1 in
> let y = x in
> let x = y + 1 in x
>
Still no cigar.
nhc98 v1.16
Program:
main = print $ (let t = 0 in let x = t + 1 in let y = x in let x = y + 1 in x)
Output:
2
___
Ha
On 11/07/2013, at 4:00 AM, Donn Cave wrote:
> I've gone to some trouble to dig up an nhc98 install (but can't seem to
> find one among my computers and GHC 7 won't build the source thanks to
> library re-orgs etc.) Because, I vaguely recall that nhc98's rules
> were different here? Anyone in a p
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
quoth Andreas Abel ,
...
> I would doubt that nhc98 would interpret let xs = 0 : xs differently
> than ghc if it implemented anything close to the Haskell 98 standard.
What I (so vaguely) remember was a compile error, for some reuse of
an identifier where GHC permitted it. I suppose you're ri
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.]
On 10.07.13 6:00 PM, Donn Cave wrote:
quoth Alberto G. Corona,
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 possible for a variable-exp
Totality checking will generate a lot of false positives.
One would like an analysis that prints an error message if an expression
is *definitely* looping in all cases. While I have studied termination,
I have not studied non-termination analyses. It is harder than
termination. For terminat
Donn Cave wrote:
> > 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 possible for a variable-expression to be two expressions at
quoth Alberto G. Corona,
> 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 possible for a variable-expression to be two expressions at
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
28 matches
Mail list logo
