Re: [Haskell-cafe] Re: FW: Haskell
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
Re: [Haskell-cafe] Re: FW: Haskell
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
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] Function Precedence
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
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] Function Precedence
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
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
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
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
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
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? rant While we're at it, what about adding even more classes, like group or ring? Algebra in a whole class hierachy. :-) /rant Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Precedence
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. rant 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
On Apr 2, 2008, at 10:27 , Hans Aberg wrote: On 2 Apr 2008, at 16:20, Loup Vaillant wrote: rant 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
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] FW: Haskell
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] Re: Function Precedence
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] Re: Function Precedence
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] Template Haskell -- when are things evaluated?
| 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
[Haskell-cafe] Role based access control via monads or arrows or... something
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
, permissions =
Re: [Haskell-cafe] SYB with class: Bug in Derive.hs module
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
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' ghc: 129595956 bytes, 17 GCs, 2640537/5069484 avg/max bytes residency (3 samples), 20M in use, 0.00 INIT (0.00 elapsed), 0.67 MUT (0.76 elapsed), 0.11 GC (0.14 elapsed) :ghc 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
Re: [Haskell-cafe] installing ghc-6.8.2
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
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/http://wwwtcs.inf.tu-dresden.de/%7Evoigt/
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
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] Role based access control via monads or arrows or... something
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
[Haskell-cafe] ANN: hdbc-odbc 1.1.4.1
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] Function Precedence
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
