jerzy.karczmarczuk | 1 Jun 2007 01:05
Picon
Favicon

Re: Crazy idea: overloading function application notation

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 
David Roundy | 1 Jun 2007 01:09
Favicon
Gravatar

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
Brandon S. Allbery KF8NH | 1 Jun 2007 01:13
Picon
Favicon

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
Creighton Hogg | 1 Jun 2007 01:19
Picon

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..."


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
jerzy.karczmarczuk | 1 Jun 2007 01:35
Picon
Favicon

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. 
Alex Jacobson | 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>   
Donald Bruce Stewart | 1 Jun 2007 03:54
Picon
Picon
Favicon
Gravatar

Re: Has anyone looked into adding subtyping to Haskell?

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
Steve Schafer | 1 Jun 2007 04:07
Gravatar

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/
PR Stanley | 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 
Christopher Lane Hinson | 1 Jun 2007 04:40
Gravatar

New (?) Partial Monad


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