
1234
Administrator

On Thu, Aug 8, 2013 at 7:40 AM, Timon Gehr <[hidden email]> wrote:
You make the distinction between "evaluate",
Which essentially means applying reduction rules to an expression until the result is a value.
and "execute" or "run", etc. This is not functional.
How would you know?
I think
Jerzy is alluding to the fact that we don't have a denotational
semantics for IO. So I'm not sure I understand your response. Are you
pointing out that some subspace of IO programs admit such a semantics
via an easy inspection?
'putStr "c"' is a pure value.
I infer you're in the latter camp. Would you then speak of 'effectful' values vs 'nulleffectful' ones? What oral syntax would you actually use?
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


I have the impression that a nice part of our dispute comes from the
fact that despite our ambitions, and a decent /technical/ level of
understanding of what we are talking about, most of us are (and I am one
of the worst...) 
 pitiful philosophers...
Really bad...
Confusing the contents and the function/role of the entities,
using ambiguous definitions (and confounding objects with their
definitions),
et j'en passe.
Sigh.
I decided to reread some philosophical texts, and I suggest one for your
evening reading.
"Indiscrete Thoughts" by GianCarlo Rota, published by Birkhäuser in
1997. Available on the Web.
Rota was an active *mathematician* and teacher, and the sense of
mathematical constructs was very important for him. It is a very
refreshing book, you won't be disappointed.
(It contains also some personal views of Rota on his fellows
mathematicians. And the analysis of the difference between characters
who are "problem solvers", as contrasted with "theoreticians"... Rota
was a strong personality, full of "obsessions", and his ideas on the
soundness of formal thinking may not convince you, but you should find
them interesting. And you will find inside that for Rota the term
"should" is very important, even if it impossible to define...)
Many thanks to Olivier Danvy, who recommended me this book!
Jerzy Karczmarczuk
Caen, France.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


KimEe Yeoh comments my reading
suggestion:
Shall I also give the line numbers, KimEe? The book of Rota is
divided into parts and chapters, with titles. It is not so difficult
to find quickly that something may (or not) interest you. What is a
"relevant" chapter in a collection of philosophical essays?
You might skip the "biographies" of some mathematicians, with some
unpleasant fragments, if you are not interested.
I liked a few others.
Part II, Ch. VII: "The Pernicious Influence of Mathematics Upon
Philosophy" is an inspired attack addressed at the "analytical
philosophers" who felt really offended! (This is a reprint from the
Journal of Metaphysics, published also in the book "18
Unconventional Essays on the Nature of Mathematics", Springer, ed.
by Reuben Hersh. I also recommend it [also on the Web], it is
plenty of serious wisdom, although sometimes hard to read.)
This chapter deals with the nonphilosophical essence of logic, with
the "philosophical vacuity" of formal definitions. Very inspiring.
For Rota the question of IDENTITY is more important than that of
EXISTENCE. The chapter XII: "Syntax, Semantics, and the Problem of
the Identity of Mathematical Items" (p. 151) begins his presentation
of the subject, which continues later. Rota exposes some reasoning
based on his favourite philosophical topic, the phenomenology,
continuing previous sections. This may not convince you (e.g. if you
are an orthodox materialist...), but you might learn something.
The chapter about /Fundierung/ (XV, p. 172) in which Rota fights
against the reductionism, may give you a headache. But you should
survive.
Anyway, /a ciascuno il suo/.
Jerzy K.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On 06.08.2013 10:46, Adam Gundry wrote:
> On 06/08/13 06:14, J. Stutterheim wrote:
>> Suppose we now have the opportunity to change the name of the
>> `return` function in Monad, what would be a "better" name for it?
>> (for some definition of better)
>
> Rather than proposing a different name, I'm going to challenge the
> premise of your question. Perhaps it would be better if `return` had no
> name at all. Consider the following:
>
> return f `ap` s `ap` t
>
> f <$> s <*> t
>
> do { sv < s
> ; tv < t
> ; return (f sv tv) }
Indeed, I wished the 0ary case would be more alike to the unary and
binary case, cf.
return f0
f1 <$> a1
f2 <$> a1 <*> a2
What is needed is a nice syntax for "idiom brackets".
> These are all different ways of spelling
>
> f s t
>
> plus the necessary applicative or monadic bureaucracy. But why couldn't
> we write just the plain application, and let the type system deal with
> the plumbing of effects?
I would not think this is practically possible. For instance, if
f :: a > b > c
then it could be a binary function or a unary function in the context
monad reading from a, thus, application
f x
is ambiguous or too sensitive, especially with type inference.
> I realise that this may be too open a research area for your project...

Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D80538 Munich, GERMANY
[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


On 13/08/13 17:38, Andreas Abel wrote:
> Indeed, I wished the 0ary case would be more alike to the unary and binary
> case, cf.
>
> return f0
> f1 <$> a1
> f2 <$> a1 <*> a2
You could always write the above as
pure f0
pure f1 <*> a1
pure f2 <*> a1 <*> a2
Twan
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


 Indeed, I wished the 0ary case would be more alike to the unary and
 binary case, cf.

 return f0
 f1 <$> a1
 f2 <$> a1 <*> a2

 What is needed is a nice syntax for "idiom brackets".
Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree on their syntax, and someone would like to offer a patch.
Something like
( f a1 a2 )
perhaps?
Simon
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


I particularly like she's (her?) syntax for Alternative. Not sure whether or not Idris has that. Applicative tuples would be nice too, something like (a,b,c) translating to liftA3 (,,) a b c . And operators too, liftA2 (+) a b as ( a + b ) ?
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


Simon PeytonJones < [hidden email]> writes:
>  Indeed, I wished the 0ary case would be more alike to the unary
>  and binary case, cf.
> 
>  return f0
>  f1 <$> a1
>  f2 <$> a1 <*> a2
> 
>  What is needed is a nice syntax for "idiom brackets".
>
> Indeed. I'm quite open to adding idiom brackets to GHC, if everyone
> can agree on their syntax, and someone would like to offer a patch.
>
> Something like
> ( f a1 a2 )
> perhaps?
I can make a patch after people agree on everything.
There's also http://hackage.haskell.org/package/applicativequoters with
its template haskell nastiness
h> :m +Control.Applicative.QQ.Idiom
h> :set XQuasiQuotes
h> [i (,) "THX" "BYE" ]
[('T','B'),('T','Y'),('T','E'),('H','B'),('H','Y'),('H','E'),('X','B'),('X','Y'),('X','E')]

lelf
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe


If we're adding applicative brackets, it would be nice to have something like ⦇⦈ as options via UnicodeSyntax. When playing around with She, I found it much easier to read than the ASCII version, especially when I needed to combine them:
((a + b) + (c * d)) ⦇⦇a + b⦈ + ⦇c * d⦈⦈ Coincidentally, She is the perfect way to experiment with idiom brackets while thinking about a patch like this. I found it very illustrative just to go through old code and see what could really be improved and what couldn't. For me personally, I certainly found *some* code became more readable, but not quite as much as I expected.
_______________________________________________
HaskellCafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskellcafe

1234
