[Haskell-cafe] Is there any movement/need in new 'base' package and co?
It is clear, that current 'core' Haskell packages bear some weight of legacy and back-compatibility, and accumulates garbage/problems over time. Some of the garbage can be dropped and some was here for so long, that it can't be dropped without major buzz. For example, we have *Monad* type-class, that is hardwired into Haskell syntax. However, it allows arbitrary fail by definition, and not all monads should provide this option. Still, it is almost impossible to move the method into separate interface, as every *Monad* instance will have to be rewritten. Lack of standard packed text/binary string type is also a problem. It is not so problem on itself, as problem of support: different io packages, parser tools and so on have to choose what string type to use, which lead to fragmentation of library field. Hierarchy of numeric classes is also often questioned. More points of problems may be found if one will study Hackage long enough. So, the questions arise: - When problems will ruin the language? - When and which actions are needed to avoid this? - If major rewrite will be initiated, what problems it should target? - And how to make the transition easier? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
Your idea looks _much_ better from code clarity point of view, but it's unclear to me, how to deal with it internally and in error messages. I'm not a compiler guy, though. Worse, it does not allow to set up fixity relative to operator that is not in scope and it will create unnecessary intermodule dependencies. One should fall back to numeric fixities for such cases, if it is needed. On 08/13/2012 11:26 PM, Ryan Ingram wrote: When I was implementing a toy functional languages compiler I did away with precedence declarations by number and instead allowed the programmer to specify a partial order on declarations; this seems to be a much cleaner solution and avoids arbitrary precedences between otherwise unrelated operators defined in different modules. You could write statements like -- define + and - to have the same precedence infixl + - -- define * to have higher precedence than + infixl * above + -- define / to have the same precedence as * infixr / equal * -- $ is right-associative infixr $ -- you can also separate precedence from fixity declaration precedence $ below + -- function application has higher precedence than all operators by default, but you can override that infixl . above APP -- == is non-associative infix == Here's some parses with this system: a + b - c = (a+b)-c f.x.y z == g w = (((f.x).y) z) == (g w) a == b == c = parse error (non-associative operator) a * b / c = parse error (left-associative/right-associative operators with same precedence) a == b $ c = parse error (no ordering known between == and $) a $ b + c = a $ (b+c) I think this is a much cleaner way to solve the problem and I hope something like it makes it into a future version of Haskell. -- ryan On Sun, Aug 12, 2012 at 11:46 AM, Евгений Пермяков permea...@gmail.com mailto:permea...@gmail.com wrote: fixity declaration has form *infix(l|r)? [Digit]* in haskell. I'm pretty sure, that this is not enough for complicated cases. Ideally, fixity declarations should have form *infix(l|r)? [Digit](\.(+|-)[Digit])** , with implied infinitely long repeated (.0) tail. This will allow fine tuning of operator priorities and much easier priority selection. For example, it may be assumed, that bit operations like (..) operator have hightest priority and have priorities like 9.0.1 or 9.0.2, anti-lisps like ($) have lowest priority like 0.0.1, control operators have base priority 1.* and logic operations like () have priority of 2.* and it will be possibly to add new operators between or above all (for example) control operators without moving fixity of other ones. Agda2 language supports wide priority range, but still without 'tails' to my knowledge. Is there any haskell-influenced language or experimental syntactic extension that address the issue? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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
[Haskell-cafe] overloading integer literals
During development some toy base library I found impossible to use
Numeric literals. Quick search showed, that one need both fromInteger in
scope (reasonable) and, as I understand, access to Integer type from
'base' package ('base' for clarity later). It is perfectly reasonable if
we assume that every module must depend on 'base'. However, with
ghc-prim and NoIplicitPrelude it is not necessary this way. One may wish
to drop 'base' dependency entirely. Currently, the only workaround I
found is to use cast from string literals (that works perfectly okay) or
use unboxed literals like 0xBB## (of unboxed type). Both solutions look
dirty, especially in pattern guards.
Is there any better solution or movement to improve RebindableSyntax
facilities ? for example, moving out classes for RebindableSyntax into
ghc-prim package and tuning them so all syntax facilities in base could
be defined in terms of RebindableSyntax would be great.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixity declaration extension
On 08/14/2012 02:52 PM, Ryan Ingram wrote: On Tue, Aug 14, 2012 at 1:04 AM, Евгений Пермяков permea...@gmail.com mailto:permea...@gmail.com wrote: Your idea looks _much_ better from code clarity point of view, but it's unclear to me, how to deal with it internally and in error messages. I'm not a compiler guy, though. How to deal with it internally: It's pretty easy, actually. The hardest part is implementing an extensible partial order; once you have that and you can use it to drive comparisons, parsing is not hard. Basically, at each step when you read an operator token, you need to decide to shift, that is, put it onto a stack of operations, reduce, that is, apply the operator at the top of the stack (leaving the current token to check again at the next step), or give a parse error. The rules for deciding which of those to do are pretty simple: Yes, I can guess it. This way. however, is linearly dependent in time from number of operators in scope. It is clearly much worse then looking into Map OperatorName Fixity . But changing numeric fixity in Map when adding operator somewhere in between existing stack is also linearly - dependent. Of course, associated penalties are small if few operators are in scope. It is unclear for me, how heavy associated penalties will be for both cases. I would expect modules to declare locally relative fixities between operators imported from different modules if and only if it was relevant to that module's implementation. Noway. Monoid, Monad and Functor are absolutely independent typeclasses and defined in different modules. There is, however, type [], which has instances for all three typeclasses, so operators for all three of them have to play together. Thus, when you create typeclass and operator-combinators for it, you should add them to entire set of operators on all hackages, as you never know, which typeclass instances will give some yet unknown types. So, rules for such cases must exists, and leaving priorities undefined is not a good way. In most cases I expect the non-ordering to be resolved by adding parentheses, not by declaring additional precedence directives; for example, even though (a == b == c) would be a parse error due to == being non-associative, both ((a == b) == c) and (a == (b == c)) are not. The same method of 'just add parentheses where you mean it' fixes any parse error due to incomparable precedences. I hate lisp-like syntax. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fixity declaration extension
fixity declaration has form *infix(l|r)? [Digit]* in haskell. I'm pretty sure, that this is not enough for complicated cases. Ideally, fixity declarations should have form *infix(l|r)? [Digit](\.(+|-)[Digit])** , with implied infinitely long repeated (.0) tail. This will allow fine tuning of operator priorities and much easier priority selection. For example, it may be assumed, that bit operations like (..) operator have hightest priority and have priorities like 9.0.1 or 9.0.2, anti-lisps like ($) have lowest priority like 0.0.1, control operators have base priority 1.* and logic operations like () have priority of 2.* and it will be possibly to add new operators between or above all (for example) control operators without moving fixity of other ones. Agda2 language supports wide priority range, but still without 'tails' to my knowledge. Is there any haskell-influenced language or experimental syntactic extension that address the issue? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Detecting numeric overflows
Can someone tell me if there are any primitives, that used to detect machine type overflows, in ghc haskell ? I perfectly understand, that I can build something based on preconditioning of variables, but this will kill any performance, if needed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Detecting numeric overflows
On 07/31/2012 12:04 AM, Artyom Kazak wrote: Евгений Пермяков permea...@gmail.com писал в своём письме Mon, 30 Jul 2012 09:47:48 +0300: Can someone tell me if there are any primitives, that used to detect machine type overflows, in ghc haskell ? I perfectly understand, that I can build something based on preconditioning of variables, but this will kill any performance, if needed. In GHC.Prim — primitives addIntC# and subIntC#: addIntC# :: Int# - Int# - (#Int#, Int##) Add with carry. First member of result is (wrapped) sum; second member is 0 iff no overflow occured. subIntC# :: Int# - Int# - (#Int#, Int##) Subtract with carry. First member of result is (wrapped) difference; second member is 0 iff no overflow occured. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Still no way to detect overflow in *. Strangely enough, I found some relevant descriptions in *.pp in dev branch, so I expect them in 7.6.1. They applies to native-size Word and Int only. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative functors with branch/choice ?
well... This code is both demonstration for use case and more sane
class + instance
typeclass name is selected quite randomly, may be native speaker will
select a better one
module Actuative where
import Control.Applicative
import System.IO
import System.IO.Error
-- | minimal complete definition : select
class Applicative f = Actuative f where
-- | select computation conditionally . Side effects of only one two
alternative take place
select :: f (Either a b) -- ^ selector
- f (a - c) -- ^ first alternative
- f (b - c) -- ^ second alternative
- f c
-- | correct possible error
correct :: f (Either a b) - f (a - b) - f b
correct i l = select i l (pure (\x - x))
-- | similiar for select, but mimics ArrowChoice
branch :: f (Either a b) - f (a - c) - f (b - d) - f (Either
c d)
branch i l r = select i (pure (\f x - Left (f x)) * l) (pure (\f x
- Right (f x)) * r)
-- | execute only if Left
onLeft :: f (Either a b) - f (a - c) - f (Either c b)
onLeft i l = branch i l (pure (\x - x))
-- | execute only if Right
onRight :: f (Either a b) - f (b - c) - f (Either a c)
onRight i r = branch i (pure (\x - x)) r
-- | This is streaming parser combinators for writing LR (k) grammars
newtype Parse a = Parse { runParse :: Handle - IO a }
-- | this function is one of reasons. If EOF occurs, we should produce
result. If not, we should continue parsing. Monadic interface, however,
gives too much freedom.
next :: Parse (Maybe Char)
next = Parse $ \h - catchIOError (fmap Just $ hGetChar h) (const $
return Nothing)
instance Functor Parse where
fmap f s = pure f * s
instance Applicative Parse where
pure a = Parse $ \_ - return a
(Parse l) * (Parse r) = Parse $ \h - do
lr - l h
rr - r h
return $ lr rr
-- instance for Actuative.
instance Actuative Parse where
select (Parse i) (Parse l) (Parse r) = Parse $ \h - do
ir - i h
case ir of
Left lv - do
lr - l h
return $ lr lv
Right rv - do
rr - r h
return $ rr rv
On 07/26/2012 12:48 PM, Ross Paterson wrote:
On Wed, Jul 25, 2012 at 09:22:23PM +0100, Евгений Пермяков wrote:
So, it seems for me, that Applicative API should be extended with
typeclass for making choice what actions to execute depending on result
of some test (pattern matching). Is there any reasonable definition of
such typeclass or clear explanation, why such typeclass is unneeded?
The possible extension may look somehow like this:
class Applicative a = Branching a where
branch :: a (Either b c) - (a b - a d) - (a c - a d) - a d
Do you have any instances in mind?
___
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] Applicative functors with branch/choice ?
May be difference will be more clear with this example ? import Control.Monad.State instance (Functor m, Monad m) = Actuative (StateT s m) where select i l r = do iv - i case iv of Left lv - l = \lf - return (lf lv) Right rv - r = \rf - return (rf rv) select' xs fs gs = sel $ xs * fs * gs where sel (Left a) f _ = f a sel (Right b) _ g = g b increment :: Monad m = StateT Int m (() - ()) increment = get = (put . (+1)) return (const ()) the difference may be seen clearly, when you run in ghci *Actuative runState (select' (return $ Left ()) increment (increment * increment * increment)) 0 ((),4) *Actuative runState (select (return $ Left ()) increment (increment * increment * increment)) 0 ((),1) Not sure, what categorical concept is model for this type class On 07/26/2012 03:14 PM, Twan van Laarhoven wrote: On 26/07/12 12:40, Евгений Пермяков wrote: class Applicative f = Actuative f where -- | select computation conditionally . Side effects of only one two alternative take place select :: f (Either a b) -- ^ selector - f (a - c) -- ^ first alternative - f (b - c) -- ^ second alternative - f c Can't you already define this function in terms of Applicative itself? I.e. select xs fs gs = sel $ xs * fs * gs where sel (Left a) f _ = f a sel (Right b) _ g = g b No. Well, a function with same type signature may be defined in terms of Applicative, as you demonstrated. However, look how select will work with instance for IO, defined like this instance Actuative IO where select i l r = do ir - i case ir of Left lv - do lf - l return $ lf lv Right rv - do rf - r return $ rf rv As you can see, if I use select definition with Control.Applicative.*, I'll execute both l and r and the only choice will be, what result to drop. Both l and r, however, will be executed, and their side effects will take place. With select from my code only one action will be executed, depending on result of i, and only effects of one of actions (either l or r) will take place. I'm not sure, what categorical concept will correspond to this typeclass. I assume that your intent is that `select` behaves differently from the one I defined here. But you need to specify in what way. Suppose it should work like if-then-else. Then you would perhaps have these laws: select (Left $ x) f g = f $ x select (fmap swapEither x) f g = select x g f I think this is a useful class to have, and I would support adding something like it to the standard library. Perhaps the arguments should be swapped to the same order as either, to give class Functor f = Selective f where eitherF :: f (a - c) - f (b - c) - f (Either a b) - f c The laws would then be: eitherF f g . fmap swapEither = eitherF g f eitherF f g . fmap Left = f eitherF f g . fmap Right = g -- follows from the other two laws every Monad is an instance via defaultEitherF ls rs xs = either ls rs = xs Twan ___ 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
[Haskell-cafe] Applicative functors with branch/choice ?
Let assume, that some computation takes argument and produces value Either a b. This computation may be represented in for different forms computePure :: a - Either b c computeMonad :: a - m (Either b c) computeApplicative :: app a - app (Either b c) computeArrow :: arr a (Either b c) = And now, having result, we need to execute several actions, making a choice, what actions to perform for Left and Right tags of Either. Pure function and monads are easy, as there is way to pattern-match on value and take actions depending on result. There is an extension to Arrow class that do the job -- ArrowChoice. However, I cannot find any way to make choice for Applicative. It seems that both Applicative and Alternative are not suited for it. So, it seems for me, that Applicative API should be extended with typeclass for making choice what actions to execute depending on result of some test (pattern matching). Is there any reasonable definition of such typeclass or clear explanation, why such typeclass is unneeded? The possible extension may look somehow like this: class Applicative a = Branching a where branch :: a (Either b c) - (a b - a d) - (a c - a d) - a d ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lambda-bot installation problem: gentoo trickery problem
When I try cabal-install lambdabot (gentoo linux/amd64, ghc installed with portage), it runs fine until compiler tries to link readline package (some template haskell?). The problem caused by dirty trick, used in gentoo: the /usr/lib64/libreadline is a fake with script, redirecting ld to /lib64 . GHC is not redirected but simply fails with message can't load .so/.DLL for: readline (/usr/lib64/libreadline.so: invalid ELF header). So, the question is: is there any workaround? Copying library look like an option, but it is very, very dirty one. Is there a way to say ghc, which libreadline.so it should load? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
