Bas van Dijk | 4 Mar 08:59 2009
Picon

Re: Field labels that do updates

2009/2/27 Ramin Honary <ramin.honary@...>:
> I have written a couple of small, experimental virtual machines in Haskell,
> and I always use the State monad with the virtual machine data type as the
> state.
>    data VM a = VM { getAlpha :: Int , getBeta :: String , getGamma :: a }
> which is all well and good, but I inevitably end up writing code like this
> along with it:
>     putAlpha a (VM _ b c) = (VM a b c)
>     putBeta  b (VM a _ c) = (VM a b c)
>     putGamma  c (VM a b _) = (VM a b c)
> Its useful because you can just create one monadic function that updates the
> state and pass one of the "put" functions as a parameter.
>     updateVM :: (x -> VM a -> VM b) -> x -> State (VM b) ()
>     updateVM  putFunc value = do { state <- get ; put (putFunc value state)
> }
>
> ...some algorithm...
>     do updateVM putAlpha 12
>        updateVM putBeta "Hello"
>        return somthing
>
> But writing the "put" functions become tedious for virtual machines with
> more fields in their type, especially if you need to add a field to the data
> type in the future. Could there be syntactic sugar added to generate a list
> of functions that update the fields of a data type?
>    data VM a = VM { getAlpha/putAlpha :: Int , getBeta/putBeta :: String ,
> getGamma/putGamma :: a }
> Where the slash operator is optional, but if included in the code will cause
> the compiler to generate functions of the given names that update those
> fields.
(Continue reading)

Conal Elliott | 20 Mar 19:51 2009
Picon

Re: [Proposal] Move most of Control.Monad to Control.Applicative

Also, return, ap, liftM, liftM2, ....  Already discussed?

On Fri, Jan 30, 2009 at 9:03 AM, Thomas Davie <tom.davie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi,
 Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives.  Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible.

My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives:

mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b]
mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f ()
sequence :: (Applicative f) => [f a] -> f [a]
sequence_ :: (Applicative f) => [f a] -> f ()

filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]
mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c])
zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c]
zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f ()
replicateA :: (Applicative f) => Int -> f a -> f [a]
replicateA_ :: (Applicative f) => Int -> f a -> f ()

when :: (Applicative f) => Bool -> f () -> f ()
unless :: (Applicative f) => Bool -> f () -> f ()

I may have missed some.

Bob
_______________________________________________
Haskell-prime mailing list
Haskell-prime <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
Conal Elliott | 20 Mar 20:02 2009
Picon

Specific denotations for pure types

I just learned on #haskell that Int has implementation/machine-dependent semantics.  I'd always assumed that pure (non-imperative) types have specific denotational models, so that for instance the denotation of something of type Int is either bottom or a (smallish) integer.  Since precise & simple denotation is at the heart of how I think about programming, and Haskell is my favorite language, I'm startled and disappointed.  I knew we didn't have a denotational semantics for Haskell, but I'd previously assumed it was just a matter of working out the details.

Has implementation-independent denotation been discussed for Haskell' ?

Thanks,

  - Conal

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
Achim Schneider | 20 Mar 23:02 2009
Picon

Re: [Proposal] Move most of Control.Monad to Control.Applicative

Conal Elliott <conal@...> wrote:

> return
>
pure!

There's the Other Prelude[1], which is enough fun to be taken seriously.

[1] http://www.haskell.org/haskellwiki/The_Other_Prelude

--

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
Achim Schneider | 20 Mar 23:17 2009
Picon

Re: Specific denotations for pure types

Conal Elliott <conal@...> wrote:

> I'd always assumed that pure (non-imperative) types have
> specific denotational models, so that for instance the denotation of
> something of type Int is either bottom or a (smallish) integer.
>
IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a
clearly defined, but still utterly under-specified semantic. The idea
is that if you want to be safe, you can just use Integer and only be
bounded by the implementation's address width and swap space (I heard
that Integers break at MAX_INT^MAX_INT). The other idea is that Int is
a number type small enough to be as fast as possible, which, in
practise, means "fits into a register, together with some tag", which
excuses Int's existence where Int32 and Int64 are around.

I'm all for defaulting to Integer and providing Natural (as an
potentially-unbounded alternative to Nat, which'd be one bit wider than
Int)... the (usually meagre) performance gains you can get by choosing
Int over Integer are worth an explicit type annotation, and with
Integer, you get non-modulo semantics, by default. Is that what you
want?

--

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
Conal Elliott | 20 Mar 23:21 2009
Picon

Re: [Proposal] Move most of Control.Monad to Control.Applicative

Exactly.  and <*>, liftA, liftA2, ...

On Fri, Mar 20, 2009 at 3:02 PM, Achim Schneider <barsoap-S0/GAf8tV78@public.gmane.org> wrote:
Conal Elliott <conal-R2YG1wQAgWFeoWH0uzbU5w@public.gmane.org> wrote:

> return
>
pure!

There's the Other Prelude[1], which is enough fun to be taken seriously.

[1] http://www.haskell.org/haskellwiki/The_Other_Prelude


_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
Conal Elliott | 20 Mar 23:38 2009
Picon

Re: Specific denotations for pure types

What I want is a specific, simple language-defined denotation for Haskell's pure types and for pure expressions having those types.

I guess currently the denotation of Int is something like 'MachineInfo -> Z + bottom' rather than the Z+bottom I thought it was.   Or, to remove the junk values, some kind of dependent type 'Pi info :: WadOfMachineInfo -> Int info + bottom', vs a type like Z32+bottom.  Similarly for other pure (not as pure as I thought) types.  Even the denotation of Bool & () are influenced by the denotation of Int, since Bool & () expressions can contain Int expressions.  Does the (denotational) semantics of every Haskell type indeed include 'MachineInfo ->' ?

  - Conal

On Fri, Mar 20, 2009 at 3:17 PM, Achim Schneider <barsoap-S0/GAf8tV78@public.gmane.org> wrote:
Conal Elliott <conal <at> conal.net> wrote:

> I'd always assumed that pure (non-imperative) types have
> specific denotational models, so that for instance the denotation of
> something of type Int is either bottom or a (smallish) integer.
>
IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a
clearly defined, but still utterly under-specified semantic. The idea
is that if you want to be safe, you can just use Integer and only be
bounded by the implementation's address width and swap space (I heard
that Integers break at MAX_INT^MAX_INT). The other idea is that Int is
a number type small enough to be as fast as possible, which, in
practise, means "fits into a register, together with some tag", which
excuses Int's existence where Int32 and Int64 are around.

I'm all for defaulting to Integer and providing Natural (as an
potentially-unbounded alternative to Nat, which'd be one bit wider than
Int)... the (usually meagre) performance gains you can get by choosing
Int over Integer are worth an explicit type annotation, and with
Integer, you get non-modulo semantics, by default. Is that what you
want?

--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


_______________________________________________
Haskell-prime mailing list
Haskell-prime-HC+Z4NTRIlBAfugRpC6u6w@public.gmane.org
http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
Achim Schneider | 20 Mar 23:51 2009
Picon

Re: Specific denotations for pure types

Conal Elliott <conal@...> wrote:

> Even the denotation of Bool & () are influenced
> by the denotation of Int, since Bool & () expressions can contain Int
> expressions.
>
Now you've lost me... they definitely shouldn't be. Otherwise, I could
be equally well coding in C.

In my mind, there's somewhere the equivalent of

data () = ()

and

data Bool = True | False

, which might, of course, be represented using machine-integers, but
have ADT semantics.

--

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
Achim Schneider | 21 Mar 00:03 2009
Picon

Re: [Proposal] Move most of Control.Monad to Control.Applicative

Conal Elliott <conal@...> wrote:

> Exactly.  and <*>, liftA, liftA2, ...
> 
I think it's safe to say that there's a general consensus that Functor
not being a superclass of Monad is a regrettable historical ward that
ought to be fixed... the problem with fixing it is that it opens up a
whole can of worms, only starting with whether or not Pointed should be
a class by itself: While the Proper Way might be to include all of
category-extras in the Prelude, the Proper Way might not at all be the
Right Way.

--

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
Lennart Augustsson | 21 Mar 00:03 2009
Picon

Re: Specific denotations for pure types

Int provides minimum of -2^29..2^29-1, and as far as I know the
overflow/underflow semantics is implementation dependent.

Personally, I try to use Integer, unless I'm forced to use Int.

  -- Lennart

On Fri, Mar 20, 2009 at 11:17 PM, Achim Schneider <barsoap@...> wrote:
> Conal Elliott <conal@...> wrote:
>
>> I'd always assumed that pure (non-imperative) types have
>> specific denotational models, so that for instance the denotation of
>> something of type Int is either bottom or a (smallish) integer.
>>
> IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a
> clearly defined, but still utterly under-specified semantic. The idea
> is that if you want to be safe, you can just use Integer and only be
> bounded by the implementation's address width and swap space (I heard
> that Integers break at MAX_INT^MAX_INT). The other idea is that Int is
> a number type small enough to be as fast as possible, which, in
> practise, means "fits into a register, together with some tag", which
> excuses Int's existence where Int32 and Int64 are around.
>
> I'm all for defaulting to Integer and providing Natural (as an
> potentially-unbounded alternative to Nat, which'd be one bit wider than
> Int)... the (usually meagre) performance gains you can get by choosing
> Int over Integer are worth an explicit type annotation, and with
> Integer, you get non-modulo semantics, by default. Is that what you
> want?
>
> --
> (c) this sig last receiving data processing entity. Inspect headers
> for copyright history. All rights reserved. Copying, hiring, renting,
> performance and/or quoting of this signature prohibited.
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime@...
> http://www.haskell.org/mailman/listinfo/haskell-prime
>

Gmane