1 Jun 2007 01:05

```Derek Elkins after a long chain which began:

>>> This is a crazy idea I've been working on: overload the syntax "x y" so
>>> it can mean function application "f x = f(x)" or multiplication "x y =
>>> x*y".

> ... This change would -definitely- lead to massive ambiguity and
> potentially lead to unresolvable cases.

My favourite example of a guaranteed mess is the implementation of Peano-
Church numerals as polymorphic functions in Haskell. You can multiply them,
you can act with one upon another one as well. But the multiplication is
the composition, and the functional application is the (inverted)
exponentiation! I belive that trying to produce something similar to the
proposal above would result in a True Disgrace.

Jerzy Karczmarczuk
```
1 Jun 2007 01:09

### Re: Just for a laugh...

```On Thu, May 31, 2007 at 11:36:54PM +0200, Tomasz Zielonka wrote:
> You can imitate the C++ code using the FFI libraries:
>
>     import Foreign.Storable
>     import Foreign
>     import Data.Word
>     import Data.Bits
>
>     getDoubleBits :: Double -> IO String
>     getDoubleBits d = alloca \$ \ptr -> do
>         poke ptr d
>         bs <- peekArray (sizeOf d) (castPtr ptr :: Ptr Word8)
>         return . concatMap (concatMap (show . fromEnum) . flip map [7,6..0] . testBit) \$ bs
>
> (I'm not sure this code prints bits in the right order).
> You can generalize this to
>     getStorableBits :: Storable a => a -> IO String

Note also that you can use unsafePerformIO to safely get pure functions
doing both these operations.
--

--
David Roundy
Department of Physics
Oregon State University
```
1 Jun 2007 01:13

### Re: Just for a laugh...

```
On May 31, 2007, at 15:47 , Andrew Coppin wrote:

> If you're bored... can you come up with a solution to this?
>
> http://warp.povusers.org/ProgrammingChallenge.html

Is it me, or does this look like a job for Data.Binary?

--

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH
```
1 Jun 2007 01:19

### Re: Just for a laugh...

On 5/31/07, Brandon S. Allbery KF8NH <allbery <at> ece.cmu.edu> wrote:

On May 31, 2007, at 15:47 , Andrew Coppin wrote:

> If you're bored... can you come up with a solution to this?
>
> http://warp.povusers.org/ProgrammingChallenge.html

Is it me, or does this look like a job for Data.Binary?

It's not just you.
When I read it I thought "First I'd steal code from Data.Binary..."

```_______________________________________________
```
1 Jun 2007 01:35

### Re: Implementing Mathematica

```Jon Harrop after myself:

>>  The semantic pattern-matcher within an algebraic package, is worlds
>>  apart from the syntactic/structural pattern-matcher of Haskell.
>
> Can you elaborate on this?
>
> I would imagine that the pattern matcher in a term-level Haskell interpreter
> would be quite similar to one from a toy Mathematica-like rewriter.
>
> Also, what aspects of this do you think would take more than 4 days?

Well, I don't know what is your definition of "toy". I can make in about
15 minutes a toy atomic bomb, using Lego.
Certainly, there is a possibility and need for syntactic pattern matching,
as in Haskell, although the identification of common terms is so important
that I would rather use a unification procedure, like in logic languages.
But this is not enough for computer algebra. OK, if you wish some SIMPLE
examples (among infinitely more) of something beyond...

* the simplification of rational expressions, beginning with the reduction
of (x^2-1)/(1+x)-x = 1, ending with a full polynomial factorizer...
Gathering of all the 'x in  a+x+b+x+ ... + x + ... so as to get M*x is
already not so trivial, and requires some decisions. Will you keep your
expressions sorted? How?...
* sin(z)^2 + ... + cos(z)^2 should simplify to 1 + ... independently of z,
so the equivalence of shared expressions should be treated seriously.

We are usually not interested in 'term-level' trivialities.

If you look at the plethora of pattern-matching functions in Mathematica,
all those MemberQ, MatchQ, FreeQ, all those DeleteCases, the functions which
give you the *position* at which a given pattern occurs within a formula,
etc., you become a bit modest. If you add to it the possibility/necessity
of renaming the variables in patterns present within the Function[{x}...]
formulae, you see that just assimilating the documentation needs something
like 4 days. Of course, this is not restricted to Mathematica. All Comp.
Algebra systems have such tools.

But, OK, I am old, tired and slow. There are, fortunately for us, some
people very fast and efficient.

Jerzy Karczmarczuk.

PS. Somebody (A. Coppin?) said that Mathematica not without reason costs
10000.
Weeeeelll, less than 2000, and for students there are much cheaper possibi-
lities. I am the last to make free ads for Wolfram, I recommend the usage
of Axiom and Maxima to my students, but there is no need to say publicly
some dubious truths about commercial software.
```
1 Jun 2007 03:52

### Re: RE: [Haskell] boilerplate boilerplate

```Actually, standalone deriving doesn't really solve the boilerplate
boilerplate problem.  My original complaint here is that I don't want to
explicitly declare a deriving (Data,Typeable) for every type used
somewhere inside a larger type I am using.  In this particular case, I
am using SYB to autogenerate/autoparse XML.  The Atom/RSS datatype has a
lot of elements in it.  Having to do an explicit declaration of deriving
(Data,Typeable) for each of them is just a tremendous beat-down no
matter where I do it.

A simple solution to the problem is just to have the compiler
automatically derive Data and Typeable for all classes.  Perhaps
initially there is some compiler flag like -fSYB.

Slightly more elegant would be to not automatically derive if the user
has done so explicitly and to add syntax to the deriving clause like
"deriving ... not (Data,Typeable)" to tell the compiler that these
instances should be unavailable for this type.

A substantially more general/elegant solution would be for the compiler
to derive instances automatically for any classes whose methods I use
and for which there has been no explicit contradictory declaration.  But
I assume that is harder and having Data and Typeable means you can use
SYB and not worry so much about deriving instances anymore.

Most elegant would be for the user to be able to add derivable classes
via import declarations, but again simply having Data and Typeable is a
95% solution and the perfect should not be the enemy of the good.

-Alex-

Simon Peyton-Jones wrote:
> | does that help to keep it on the radar?-)
> | claus
>
> Indeed!  But please modify the wiki.  Email has a half life of about 1 day!
>
> S
> _______________________________________________
>
```
1 Jun 2007 03:54

```stefan:
> Al,
>
> >Has there been any work on extending Haskell's type system with
> >structural subtyping?
>
>   Koji Kagawaga. Polymorphic variants in Haskell. In Andres Loeh,
> editor, Proceedings of the 2006 ACM SIGPLAN Workshop on Haskell,
> Portland, Oregon, USA, September 17, 2006, pages 37--47. ACM Press,
> 2006. [1]
>
> >What is the canonical solution to the expression problem in Haskell?
>
> Not canonical but Loeh and Hinze have proposed open data types:
>

For a short term solution, we used Typeable + type classes to provide a
open Message data type. Similar techniques are used in Simon Marlow's
extensible exceptions paper.

-- An open Message type
class Typeable a => Message a

--
-- A wrapped value of some type in the Message class.
--
data SomeMessage = forall a. Message a => SomeMessage a

--
-- And now, unwrap a given, unknown Message type, performing a (dynamic)
-- type check on the result.
--
fromMessage :: Message m => SomeMessage -> Maybe m
fromMessage (SomeMessage m) = cast m

-- Don
```
1 Jun 2007 04:07

### Re: What puts False before True?

```On Thu, 31 May 2007 13:51:20 -0700, you wrote:

>I think it's mathematical convention more than the C convention Haskell
>is agreeing with.

I think so, too. In Boolean algebra (which predates computers, much less
C), FALSE has traditionally been associated with 0, and TRUE with 1. And
since 1 > 0, TRUE > FALSE.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
```
1 Jun 2007 04:33

### Re: What puts False before True?

```
> >I think it's mathematical convention more than the C convention Haskell
> >is agreeing with.
>
>I think so, too. In Boolean algebra (which predates computers, much less
>C), FALSE has traditionally been associated with 0, and TRUE with 1. And
>since 1 > 0, TRUE > FALSE.
The question, however, still remains: why False = 0 and True 1? I
appreciate that it's so in boolean algebra but why? Why not True = 0
and False = 1?
A Boolean value denotees veracity whereas an ordered value concerns
magnitude (priority), indeed, order!!
Thanks,
Paul
```
1 Jun 2007 04:40

```
Some time ago I noticed that a function I was writing had the exact
type as liftM2, and I so I ended up generalizing a monad.  I thought I
should document it really well, and the result is this:

http://www.downstairspeople.org/darcs/partial/Partial.pdf

\$ darcs get http://www.downstairspeople.org/darcs/partial

I would appreciate any feedback.  Is this even original?

--Lane
```

Gmane