Re: [Haskell-cafe] Function Precedence

[Henning Thielemann]

On Wed, 2 Apr 2008, Hans Aberg wrote:

Show could be implemented by writing out the function closures, but I 
think the reason it is not there is that it would create overhead in 
compiled code.


It would also not give referential transparent answers, because the same 
function can be implemented in different ways:

  http://www.haskell.org/haskellwiki/Show_instance_for_functions
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Henning Thielemann]

On Wed, 2 Apr 2008, Hans Aberg wrote:

But one should also be able to write (f+g)(x). - This does not work in 
Haskell, because Num requires an instance of Eq and Show.


You could define these instances with undefined function implementations 
anyway. But also in a more cleaner type hierarchy like that of 
NumericPrelude you should not define this instance, because it would open 
new surprising sources of errors:

  http://www.haskell.org/haskellwiki/Num_instance_for_functions
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: hdbc-odbc 1.1.4.1

[John Goerzen]

Hi folks,

HDBC-ODBC 1.1.4.1 has been uploaded to http://software.complete.org/hdbc-odbc 
and to Hackage.

Bryn Keller reported a build problem on Windows with GHC 6.8.x, which has 
been fixed.

-- John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Role based access control via monads or arrows or... something

[Luke Palmer]

2008/4/2 porrifolius <[EMAIL PROTECTED]>:
>   (7) ideally required permissions would appear (and accumulate) in type
>  signatures via inference so application code knows which are required and
>  type checker can reject static/dynamic role constraint violations

If you mean what I think you mean by "dynamic", that these are runtime
permissions,
then you're not going to get the type checker to check them... of course.  What
did you mean by dynamic?

>  I've attempted a solution using arrows based loosely upon ideas in [1] and
>  [2].  I can't figure out how to make it work, even if I did get it working I
>  now suspect it can be done far more simply, and I don't think it could ever
>  provide feature (7).  For what it's worth it's attached.
>
>  Ideally you kind folk could help me come up with a type-level solution to
>  satisfy (7), so you could have something like:
>  deptAveSal :: (HasPerms subject? Read Salary [person]?, HasPerm subject? Read
>  Employees dept?, HasRole subject? Manager dept?) => Department -> Salary

What comes to mind is that you could pass proofs around which
represent required permissions.  The hard part is coming up with a
data type algebra for expressing your "theorems" (permission
requirements).   If you want a rich system of permissions, it's pretty
unlikely that you'll get inference.

data HasRole role dept = HasRole -- do not expose this constructor
data HasPerm perm obj dept = HasPerm -- nor this one

class Department d where

deptAveSal :: (Department dept)
   => HasPerm ReadPerm Employees dept
   -> HasRole ManagerRole dept
   -> dept
   -> Salary

And then dole out HasRoles and HasPerms through your module interface.

However, I'm pretty sure any solution to (7) will be unsatisfactory to
you, considering your long list of requirements.  Haskell's type
system is not SQL, it will have a hard time supporting these things.
If you're interested in programming with type-safe permissions you
might want to look into dependent types (Epigram, Agda 2), but those
languages are not what you would consider "mature" or "fast"  (it
takes 1 second to verify that 113 is prime in Agda 2... now you see
what I mean?).  It would be an academic exercise.

Here's my ill-informed advice (since I don't know what problem you're
trying to solve, only what solution you want to have):  Forget (7),
stay away from arrows for this, and avoid overengineering (this kind
of problem especially likes to attract overengineers).

My hunch is that you only need two things:  a data type witnessing a
permission.  That is, don't worry about the subject? stuff; if the
program can get its hands on a witness of a permission, then it has
that permission.   I would start with KISS, just a plain
unparameterized data type:

-- keep this type abstract and do not expose the constructors
data Perm = ReadSalaryPermission Employee
  | ...

And then maybe introduce separation and type parameters as you start
to use them and see where the logical boundaries are.

Of the possible ways you can put this into a monad, I would say
"Access t" is a computation which results in a value of type t after
receiving witnesses of required permissions.  I considered:

data Access a = Access { value :: a, required :: Set Perm }

But I like to avoid ad-hoc checks like this and actually put the
checks right in the code.

newtype Access' a = Access' (Set Perm -> Maybe a)

Or:

data Access'' a
= Result a
| NeedPermissions (Set PermSpec) (Set Perm -> Access'' a)

Or something like that.  Let the computation figure out how to verify
the permissions.  Notice how Perm and PermSpec are different in the
last example, because of the witness model.  You don't want to give
someone the permissions to do something when you're just trying to
tell them what permissions they need.

In particular, though, there is nothing arrow-like about this problem.
 Arrows abstract the notion of function, and this problem is all about
values.

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] installing ghc-6.8.2

[michael]

Apologies to Ian, I think I sent him direct mail on my first attempt to
reply.
Adding those lines to mk/build.mk did not work.
I hope Idon't have to build a newer gcc. This is what I have right now.
[EMAIL PROTECTED]:~/src/gcc$ gcc -v

Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)



On Thu, Apr 03, 2008 at 12:50:46AM +0100, Ian Lynagh wrote:
> On Wed, Apr 02, 2008 at 07:12:16PM -0400, [EMAIL PROTECTED] wrote:
> > 
> > so it's this line that seems of the most interesting
> > 
> > cc1: error: unrecognized option `-fno-unit-at-a-time'
> 
> It looks like your version of ghc isn't designed to be used with the
> version of gcc you have.
> 
> Putting this in mk/build.mk ought to let the build go through:
> 
> SRC_HC_OPTS = -fasm
> GhcStage1HcOpts = -fasm
> 
> 
> Thanks
> Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: FW: Haskell

[Lennart Augustsson]

Mark Jones brought higher order polymorphism to Haskell.

On Wed, Apr 2, 2008 at 8:08 AM, Janis Voigtlaender <
[EMAIL PROTECTED]> wrote:

> apfelmus wrote:
>
> > Janis Voigtlaender wrote:
> >
> >  Loup Vaillant wrote:
> > >
> > >   Thanks to some geniuses (could someone name them?), we have type
> > > > classes and higher order types in Haskell (and even more).
> > > >
> > >
> > >
> > > As far as names go:
> > >
> > >  for type classes, of course Wadler, but also Blott and Kaes.
> > >
> > >  for higher order types, well, where to start?
> > >
> >
> >
> > Girard and Reynolds?
> >
>
> Yes, that's the obvious suspects, of course. But I'm not sure I would
> say they brought polymorphism (assuming that's what is meant by "higher
> order types") to Haskell. Not in the same way Wadler and co. brought
> type classes, quite specifically, to Haskell.
>
> --
> Dr. Janis Voigtlaender
> http://wwwtcs.inf.tu-dresden.de/~voigt/
> mailto:[EMAIL PROTECTED]
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] installing ghc-6.8.2

[Ian Lynagh]

On Wed, Apr 02, 2008 at 07:12:16PM -0400, [EMAIL PROTECTED] wrote:
> 
> so it's this line that seems of the most interesting
> 
> cc1: error: unrecognized option `-fno-unit-at-a-time'

It looks like your version of ghc isn't designed to be used with the
version of gcc you have.

Putting this in mk/build.mk ought to let the build go through:

SRC_HC_OPTS = -fasm
GhcStage1HcOpts = -fasm


Thanks
Ian

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module

[Ian Lynagh]

On Mon, Mar 31, 2008 at 03:47:04PM +0200, Alexey Rodriguez Yakushev wrote:
> 
> The Data instance that Derive generates is as follows:
> 
> > instance (Data ctx a,
> >   Data ctx (BinTree a),
> >   Sat (ctx (BinTree a))) =>
> >   Data ctx (BinTree a) where
> 
> Note the recursive |Data ctx (BinTree a)| in the context.

This looks like it is related to these tickets:

http://hackage.haskell.org/trac/ghc/ticket/1470
http://hackage.haskell.org/trac/ghc/ticket/1735


Thanks
Ian

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] installing ghc-6.8.2

[michael]

It seems there is no ghc 6.8.2 for my version of debian. So I am
compiling from source. 
I ran config with no problem. make generated some errors. I omit all
output except the end. Let me know if Ileft something important out
please.


make all
/usr/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing  -ignore-package
Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp
-c System/FilePath/Posix.hs -o System/FilePath/Posix.o  -ohi
System/FilePath/Posix.hi
cc1: error: unrecognized option `-fno-unit-at-a-time'
<>
make[2]: *** [System/FilePath/Posix.o] Error 1
make[1]: *** [boot] Error 2
make: *** [stage1] Error 1


so it's this line that seems of the most interesting

cc1: error: unrecognized option `-fno-unit-at-a-time'

any tips on how to deal with this would be most helpful.

Michael Litchard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Role based access control via monads or arrows or... something

[porrifolius]

Hello.

I've been playing around trying to write a framework to support/enforce access 
control to resources.  So far my efforts have yielded little but bruised 
forehead and compressed plaster-board.

What I'd like is a solution that:
  (1) prevents access to resources except via a fine-grained permissions 
checking gateway

  (2) supports on-the-fly permissions eg Bob can see Fred's salary

  (3) supports dynamic role constraints eg Bob can't be both appointor and 
appointee of secret agent status

  (4) allows lack of permission to optionally act as a filter rather than 
cause an abort, eg Bob viewing all salaries returns Fred's but doesn't return 
Tom's rather than aborting altogether because Bob lacks the permission over 
Tom

  (5) well defined behaviour when checking permissions for actions that change 
permissions

  (6) it must be pure, no need for IO.

  (7) ideally required permissions would appear (and accumulate) in type 
signatures via inference so application code knows which are required and 
type checker can reject static/dynamic role constraint violations 


I've attempted a solution using arrows based loosely upon ideas in [1] and 
[2].  I can't figure out how to make it work, even if I did get it working I 
now suspect it can be done far more simply, and I don't think it could ever 
provide feature (7).  For what it's worth it's attached.


Ideally you kind folk could help me come up with a type-level solution to 
satisfy (7), so you could have something like:
deptAveSal :: (HasPerms subject? Read Salary [person]?, HasPerm subject? Read 
Employees dept?, HasRole subject? Manager dept?) => Department -> Salary

Failing that how to do it in a more simple fashion?  I now think that a 
State-like monad exposing only functions taking values in a wrapper type that 
carries required permissions may be sufficient, but still probably couldn't 
satisfy (7).

Failing that my existing attempt has me stumped for a few reasons:
  how do I get hold of the subject and resource so I can build the correct 
permission in Test?  eg the Person whose Salary is needed in salary, and 
who's trying to get it

  where do I get the System from in Test?  eg fakeSystem in personByName

  how to implement the filter functionality in RBAC?  Parametric over 
container types?

I think that perhaps the Validator would need to be a monad that holds the 
initial state of the System to provide a stable set of permissions/roles and 
that the subject and System should also be threaded through the arrows for 
use/modification.


Any help you can offer for my aching cranium will be _much_ appreciated.
Thanks.


[1] Encoding Information Flow in Haskell - Peng Li, Steve Zdancewic. 
http://www.seas.upenn.edu/~lipeng/homepage/flowarrow.html
[2] A Library for Secure Multi-threaded Information Flow in Haskell - 
Alejandro Russo, Tsa-chung Tsai, John Hughes. 
http://www.cs.chalmers.se/~russo/publications.html
{-# LANGUAGE
  FunctionalDependencies,
  MultiParamTypeClasses
  #-}

module RBAC (
  Arrow (),
  Validator (..),
  apply,
  require,
  applyRequire,
  check
  ) where

import   Control.Arrow (
first,
pure,
(>>>)
)
import qualified Control.Arrow as A
import   Data.Set (
Set
)
import qualified Data.Set as S (
empty,
fromList,
singleton,
union
)


require :: (A.Arrow a) => p -> Arrow v p a b b
require p = Arr { computation = pure id
, permissions = S.singleton p
}

apply :: (A.Arrow a, Ord p) => (b -> c) -> Arrow v p a b c
apply = pure

applyRequire :: (A.Arrow a, Ord p) => (b -> c) -> p -> Arrow v p a b c
applyRequire f p = apply f >>> require p

-- filter and filter' use permissionHeld... perhaps permissionHeld is
-- implemented by knot-tying the set of permissions that get checked
-- in the process of executing the arrow back in as an input.  Perhaps
-- there should be permissions and filterPermissions in the arrow so
-- only the filterPermissions are passed back in.
--filter :: (A.Arrow a) => p -> Arrow v p a b (Maybe b)
--filter p = Arr { computation = pure if permissionHeld p 
--  then Just 
--  else const Nothing
--   , permissions = S.singleton p
--   }

-- Filters out each element of the list for which the constructed
-- permission isn't held.  Would be nice if this could be generalised
-- to any container, not just lists.
--filter' :: (A.Arrow a) => (b -> p) -> Arrow v p a [b] [b]
--filter' pf = error "filter': not implemented" 

data Arrow v p a b c = Arr { computation :: a b c
   , permissions :: Set p
   }

instance (Ord p, A.Arrow a) => A.Arrow (Arrow v p a) where
  pure f = Arr { computation = pure f
   

RE: [Haskell-cafe] Template Haskell -- when are things evaluated?

[Simon Peyton-Jones]

| > I'm reading the following rule from your answer:
| >
| >  [|exp|] normally returns the unevaluated AST of exp. However, if exp
| contains
| >  local variables, these are lifted using Language.Haskell.TH.lift (i.e.
| evaluated
| >  before lifting).
| >
| >  Is that correct?
| >
| >
| >  / Emil
|
| Yes, that seems to be true. I'm not an expert in the internals of TH
| though, so I have inferred that rule by extensive use of TH ;).
|
| SPJ can confirm if it's right.

Sorry, been busy with the ICFP deadline.

I think you are asking this:

module M(f) where

  f :: Int -> Q Exp
  f x = let  expensive :: Int -> Int
 expensive p = p*p + x*x

in let y = expensive x

in [| y+1 |]

module Test where
  import M
  test n = n + $(f 4)

When compiling module Test, TH will evaluate (f 4), returning a syntax tree 
which it will splice in place of the call $(f 4).  What expression will it 
return?  Two candidates:

  $(f 4) -->  24+1
  $(f 4) -->  expensive 4 + 1

In TH you get the former, which is I think what you understood.  Why?  Apart 
from anything else, 'expensive' isn't even in scope in module Test -- it was a 
local binding inside the invocation of f.  Second, this is partly what staging 
is about; you get to specify when you want things to be done. If you want the 
splice to contain the call to expensive (rather than its result), you'll need 
to float out expensive to the top level (which means lambda-lifting).  And then 
you can say this:

  expensive :: Int -> Int -> Int
  expensive x p = p*p + x*x

  f :: Int -> Q Exp
  f x = let y = [| expensive x x |]

in [| $y+1 |]

By putting the call in a quote we delay its evaluation.

If someone felt like transcribing this little thread into a FAQ-like thing on 
the GHC user wiki (I'm disconnected at the moment) that would be a fine thing 
to do.  Thanks.

Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Function Precedence

[Loup Vaillant]

2008/4/2, Dan Piponi <[EMAIL PROTECTED]>:
> On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
>  >  All you'd have to do is to give the inner most function the highest
>  > precdence
>
>
> What's the innermost function in "f g x" here?
>
>  test :: (a -> b -> c) -> a -> b -> c
>  test f g x = f g x

g (if I followed correctly). But we have a problem:

If I want f g x to be parsed as f (g x), I would probably want,
f g x y to be parsed as f (g x y), considering g as the innermost
function, again.

I'm almost certain that it would render type inference impossible, and
maybe partial application as well. (id 4 is a total application, but
id (\x -> x+1) is a partial one...)

The only choices left are right associativity or left associativity.

Loup
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Function Precedence

[Dan Piponi]

On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
>  All you'd have to do is to give the inner most function the highest
> precdence

What's the innermost function in "f g x" here?

test :: (a -> b -> c) -> a -> b -> c
test f g x = f g x
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FW: Haskell

[Martin DeMello]

On Tue, Apr 1, 2008 at 3:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:
> Nor did I use to take
> perfectly working code and refactor it until it cried for mercy, and then
> stay awake wondering if there was some abstraction out there I was missing
> that would really make it sing.

I find myself doing this in Scheme and Ruby too - it's actually one of
my rules-of-thumb for picking languages that I'd like to invest in.

martin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 16:30, Brandon S. Allbery KF8NH wrote:

While we're at it, what about adding even more classes, like "group"
or "ring"? Algebra in a whole class hierachy. :-)


Only ambition required :-).


http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion  
--- go nuts.


There is a Math Prelude, but perhaps one can simplify and divide into  
parts that refines the current Prelude, and stuff built on top of a  
refined Prelude. The problem with the current one is that for example  
Num claims (+), insists on Eq and Show, and there is no way to get  
rid of those requirements. So inserting some classes, like  
AdditiveSemiMonoid would be less ambitious than writing a whole new  
algebra oriented Prelude. Perhaps a better chance of success.


  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Brandon S. Allbery KF8NH]

On Apr 2, 2008, at 10:27 , Hans Aberg wrote:

On 2 Apr 2008, at 16:20, Loup Vaillant wrote:



While we're at it, what about adding even more classes, like "group"
or "ring"? Algebra in a whole class hierachy. :-)


Only ambition required :-).


http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion  
--- go nuts.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 16:20, Loup Vaillant wrote:

class AdditiveSemiMonoid a where
  (+) :: a -> a -> a


Err, why *semi* monoid? Plain "monoid" would not be accurate?


A monoid has a unit:
  class (AdditiveSemiMonoid a) => AdditiveMonoid a where
o :: a

The semimonoid is also called semigroup, I think.



While we're at it, what about adding even more classes, like "group"
or "ring"? Algebra in a whole class hierachy. :-)


Only ambition required :-).

It is probably easier to make a copy of Prelude.hs to say  
NewPrelude.hs, and modify it directly, by inserting intermediate  
classes.


  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Loup Vaillant]

2008/4/2, Hans Aberg <[EMAIL PROTECTED]>:
> On 2 Apr 2008, at 14:27, [EMAIL PROTECTED]
> wrote:
>
> > > It would be better to write a new Prelude. :-)
> >
> > Oh, yes, our common dream...
>
>  One may not need to write a wholly new Prelude, by something like:
>
>  module NewPrelude where
>
>  import Prelude hiding -- Num, (+).
>
>  class AdditiveSemiMonoid a where
>   (+) :: a -> a -> a

Err, why *semi* monoid? Plain "monoid" would not be accurate?


While we're at it, what about adding even more classes, like "group"
or "ring"? Algebra in a whole class hierachy. :-)


Loup
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 14:27, [EMAIL PROTECTED] wrote:


It would be better to write a new Prelude. :-)


Oh, yes, our common dream...


One may not need to write a wholly new Prelude, by something like:

module NewPrelude where

import Prelude hiding -- Num, (+).

class AdditiveSemiMonoid a where
  (+) :: a -> a -> a

...

class (Eq a, Show a, AdditiveSemiMonoid a) => Num a where
(+)  :: a -> a -> a

-- Stuff of Prelude using Num.

Then import NewPrelude instead, and

instance AdditiveSemiMonoid (a -> b) where
  f + g = \x -> f(x) + g(x)

or something.

  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 14:27, [EMAIL PROTECTED] wrote:
That is possible, of course - I did that, too. But it means that  
the  syntax and semantics do not work together; an invitation to  
pitfalls.  So this ought to be avoided, except if there are no  
other workarounds.


I am more tolerant.


The pragmatics is to decide whether to program Haskell, or making a  
new language. I am interested in the latter, but realistically nobody  
will singly be able prdocue the programingg capacity that the now  
mature Haskell has.



The question - for me - is not an interplay between
syntax and semantics, ...


That interplay, between notation and notions, is very important in  
math, as if the do not flow together, one will not be able to  
describe very complex logical structures.



...syntax here is irrelevant, the fact that (+) is a
popular infix operator plays no role. The calamity comes from the  
fact that

it is not possible to write serious and "natural" instances of Eq and
Show for functions, ...


A correct Eq would require a theorem prover. Show could be  
implemented by writing out the function closures, but I think the  
reason it is not there is that it would create overhead in compiled  
code.



...and that for God knows which reasons, the Num instance
demands them ! This requirement is not rational, although intuitive.


Probably pragmatics. More general implementations were not considered  
at the time.



But
I violated it several times, when I needed arithmetic for lazy  
infinite

objects... So, I can't say that this should be avoided. I don't see
"obvious" pitfalls therein.


The pitfall is when somebody which does not know the code well tries  
to use it. Define a library with

  false = True
  true = False
Perfectly logical, but it will be thwarted by peoples expectations.


It would be better to write a new Prelude. :-)


Oh, yes, our common dream...


Such changes will require a new standard. Haskell seems rather fixed,  
so it will perhaps then happen in a new language. :-)


  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[jerzy . karczmarczuk]

Hans Aberg comments my remark to his observation: 

But one should also be able to write (f+g)(x). - This does not  work  in 
Haskell, because Num requires an instance of Eq and Show.


So, declare them, even if they are vacuous. I did it several times,  I am
still alive, so no need to say "this does not work".


That is possible, of course - I did that, too. But it means that the  
syntax and semantics do not work together; an invitation to pitfalls.  So 
this ought to be avoided, except if there are no other workarounds.


I am more tolerant. The question - for me - is not an interplay between
syntax and semantics, syntax here is irrelevant, the fact that (+) is a
popular infix operator plays no role. The calamity comes from the fact that
it is not possible to write serious and "natural" instances of Eq and
Show for functions, and that for God knows which reasons, the Num instance
demands them ! This requirement is not rational, although intuitive. But
I violated it several times, when I needed arithmetic for lazy infinite
objects... So, I can't say that this should be avoided. I don't see
"obvious" pitfalls therein. 


It would be better to write a new Prelude. :-)


Oh, yes, our common dream... 

Jerzy Karczmarczuk 



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 13:51, [EMAIL PROTECTED] wrote:
But one should also be able to write (f+g)(x). - This does not  
work  in Haskell, because Num requires an instance of Eq and Show.


So, declare them, even if they are vacuous. I did it several times,  
I am

still alive, so no need to say "this does not work".


That is possible, of course - I did that, too. But it means that the  
syntax and semantics do not work together; an invitation to pitfalls.  
So this ought to be avoided, except if there are no other workarounds.


It would be better to write a new Prelude. :-)

  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[jerzy . karczmarczuk]

Hans Aberg writes: 


...
But one should also be able to write (f+g)(x). - This does not work  in 
Haskell, because Num requires an instance of Eq and Show.


So, declare them, even if they are vacuous. I did it several times, I am
still alive, so no need to say "this does not work". 

Jerzy Karczmarczuk 



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Hans Aberg]

On 2 Apr 2008, at 11:22, Henning Thielemann wrote:

It seems me it may come from an alteration of math conventions:
Normally (x) = x, and function application is written as f(x), except
for a few traditional names, like for example sin x. So if one
reasons that f(x) can be simplified to f x, then f g x becomes short
for f(g)(x) = (f(g))(x).


In functional analysis you write e.g. D f(x) meaning (D f)(x) not D 
(f(x)),

so I wouldn't say there is any convention of precedence of function
application in mathematics.


When I take a quick look into Hörmander's book on distributions, then  
he writes (D f)(phi), and not D f(phi). So there might be a  
difference between math that is drawn towards pure or applied math.



Even more, in functional analysis it is common
to omit the parentheses around operator arguments, and since there  
are a

lot of standard functions like 'sin', ...


I think that in RTL, one do that as well: x tau, instead of (x)tau.


...I wouldn't say that using argument
parentheses is more common than omitting them.(Btw. in good old ZX
Spectrum BASIC it was also allowed to omit argument parentheses.)


Math usage is probably in minority these days. As I noted, looking  
into books on axiomatic set theory, one construct tuplets it so that  
(x) = x. So it seems possible, although for function application f(z)  
seems the normal notation.


But one should also be able to write (f+g)(x). - This does not work  
in Haskell, because Num requires an instance of Eq and Show.


  Hans

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function Precedence

[Henning Thielemann]

On Tue, 1 Apr 2008, Hans Aberg wrote:

> On 1 Apr 2008, at 12:40, PR Stanley wrote:
> > Why can't we have function application implemented outwardly
> > (inside-out). So
> > f g x would be applied with
> > gx first followed by its return value passed to f instead of
> > putting g x in brackets.
>
> It seems me it may come from an alteration of math conventions:
> Normally (x) = x, and function application is written as f(x), except
> for a few traditional names, like for example sin x. So if one
> reasons that f(x) can be simplified to f x, then f g x becomes short
> for f(g)(x) = (f(g))(x).

In functional analysis you write e.g. D f(x) meaning (D f)(x) not D(f(x)),
so I wouldn't say there is any convention of precedence of function
application in mathematics. Even more, in functional analysis it is common
to omit the parentheses around operator arguments, and since there are a
lot of standard functions like 'sin', I wouldn't say that using argument
parentheses is more common than omitting them. (Btw. in good old ZX
Spectrum BASIC it was also allowed to omit argument parentheses.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: FW: Haskell

[Janis Voigtlaender]

Loup Vaillant wrote:

By "higher order types", I meant the type of runST (ST monad),
or dpSwich (in yampa). I meant things like
"(forall a, a-> b) -> a -> b"


That's then usually called "higher-rank polymorphic types", just in case
you need more keywords for literature search ;-)

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: FW: Haskell

[Loup Vaillant]

2008/4/2, Janis Voigtlaender <[EMAIL PROTECTED]>:
> apfelmus wrote:
>
> > Janis Voigtlaender wrote:
> >
> > > Loup Vaillant wrote:
> > > >  Thanks to some geniuses (could someone name them?), we have type
> > > > classes and higher order types in Haskell (and even more).
> > >
> > > As far as names go:
> > >
> > >  for type classes, of course Wadler, but also Blott and Kaes.
> > >
> > >  for higher order types, well, where to start?
> >
> > Girard and Reynolds?
>
>  Yes, that's the obvious suspects, of course. But I'm not sure I would
>  say they brought polymorphism (assuming that's what is meant by "higher
>  order types") to Haskell. Not in the same way Wadler and co. brought
>  type classes, quite specifically, to Haskell.

By "higher order types", I meant the type of runST (ST monad),
or dpSwich (in yampa). I meant things like
"(forall a, a-> b) -> a -> b", and maybe existential types as well.

But now you mention it, I don't know who came up with mere parametric
polymorphism. (Hindley, Damas, Milner?)

Anyway, thanks for the names (now I have more papers to swallow :-).
Loup
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: FW: Haskell

[Janis Voigtlaender]

apfelmus wrote:

Janis Voigtlaender wrote:


Loup Vaillant wrote:


  Thanks to some geniuses (could someone name them?), we have type
classes and higher order types in Haskell (and even more).



As far as names go:

 for type classes, of course Wadler, but also Blott and Kaes.

 for higher order types, well, where to start?



Girard and Reynolds?


Yes, that's the obvious suspects, of course. But I'm not sure I would
say they brought polymorphism (assuming that's what is meant by "higher
order types") to Haskell. Not in the same way Wadler and co. brought
type classes, quite specifically, to Haskell.

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe