Silent Leaf | 1 Jun 00:18 2016
Picon

why is there no typeclass common to all containers?

All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions.
So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.
So, do i miss something? Is there in fact a class of that kind? If so why not?
Thanks in advance! :)

<div><p>All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions.<br>So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.<br>So, do i miss something? Is there in fact a class of that kind? If so why not?<br>Thanks in advance! :)
</p></div>
Patrick Pelletier | 28 May 08:53 2016

documenting individual method arguments with Haddock

In Haddock, individual function arguments can be documented like this:

f  :: Int      -- ^ The 'Int' argument
    -> Float    -- ^ The 'Float' argument
    -> IO ()    -- ^ The return value

Since a typeclass method is very much like a function, I assumed I could 
document individual arguments of methods the same way.  For example:

-- | Class representing a connection to a collection of bulbs.
-- In the case of a LAN connection, this would be all bulbs on the LAN.
-- In the case of a cloud connection, this would be all bulbs associated
-- with the cloud account for a particular access token.
class Connection t where
   -- | Retrieve information about some or all lights.  Corresponds to
   -- <http://api.developer.lifx.com/docs/list-lights List Lights> endpoint.
   -- Beware that on a  <at> LanConnection <at> , it takes time for lights to be
   -- discovered, so the list of lights will be empty immediately after
   -- the connection is created.
   listLights :: t                  -- ^ The connection.
                 -> [Selector]      -- ^ The lights to list.
                 -> [InfoNeeded]    -- ^ A hint about what information 
is desired
                                    -- in the results.  This hint is used
                                    -- by  <at> LanConnection <at> , but is ignored by
                                    --  <at> CloudConnection <at> .
                 -> IO [LightInfo]

However, when I generate documentation (using Haddock 2.17.2, via "stack 
haddock"), the text "A hint about what information is desired" doesn't 
appear anywhere in the generated documentation.

Is there a way I can include this sort of per-argument documentation for 
my typeclass methods?

Thanks,

--Patrick

Alex Belanger | 26 May 15:53 2016
Picon
Gravatar

Re: How to best handle classes of types, interactions and listing of different types?

Monoid would fit the picture as far as "concatenating" the same type go. What you could do is have constructors that defines which types can be concatenated together then only that wrapper type implements the final Monoid instance.

On May 26, 2016 9:44 AM, "Silent Leaf" <silent.leaf0 <at> gmail.com> wrote:
I understand your example. Still it's useless if we need the value of the multiplied vectors, more than just a list of their lengths after the operation, unless i missed something.

At any rate; I'm trying to create a representation of mathematical sets. The tricky part being, they're precisely capable to handle any kind of content, including themselves. But I think I went too overboard, trying to handle the idea of sets that could contain strictly any type (at once). In practice, the basic elements will be rather similar, and known enough at least so that I can merely use ADTs for the various "types" of elements, and same for sets themselves.
If needed I can create two instances of monoids, one for And, one for Or, using newtype wrappers. It's vaguely a hassle but anyway it'll only be useful if i have to create functions that could work on both monoids (separately), which would be interesting enough so i don't merely duplicate the job.
There's also the possibility i need to use existing functions already using monoids...
For now I think i'll be ok with ADTs and one common wrapper for all elements.

Thanks still, I'll think about your idea, it's rather interesting.


Le mardi 24 mai 2016, Daniel Bergey <bergey <at> alum.mit.edu> a écrit :
> On 2016-05-23 at 12:06, Silent Leaf <silent.leaf0 <at> gmail.com> wrote:
>> Say there's a class, many types that can instantiate it. Then, i in fact need to be able
>> to concatenate (mappend would be ideal!), make lists of values of different types, all
>> instantiating the class.
>
> In most cases, when Haskell beginners want to make a list that contains
> several types from a single type class, there's a better way to organize
> the code.  If you post your code, I'll try to suggest a specific
> solution.
>
> In general, try to find a simple data type that captures the same fields
> & functions as an unknown type that is part of the type class.  Here's
> an example.
>
> We have a type class for vectors in a metric space, and instances for
> 2D, 3D, etc.
>
>> class Metric v where
>>     length :: v -> Double
>>     (*^) :: Double -> v -> v
>
> This class has the law:  s * length v == length (s *^ v)
>
> Instead of a heterogeneous list [ V2 1 2, V3 3 4 5, V4 6 7 8 9], we make
> a list that just has the length of each vector, and lets us multiply
> those lengths by a scalar.  In this case, we don't even need to write a
> new data type, the type is simply Double.  We can write:
>
>> [ length (V2 1 2), length (V3 3 4 5), length (V4 6 7 8 9) ]
>
> And (*) gives us what Metric does with (*^).  Of course, with your
> class, it's probably not so obvious how to transform the class this way.
>
> It's certainly possible to make a record with functions as members,
> moving in the object-oriented direction.  Existential types (with a
> class constraint inside the data constructor) are even more rarely used.
>
> cheers,
> bergey
>

_______________________________________________
Beginners mailing list
Beginners <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

<div>
<p dir="ltr">Monoid would fit the picture as far as "concatenating" the same type go. What you could do is have constructors that defines which types can be concatenated together then only that wrapper type implements the final Monoid instance.</p>
<div class="gmail_quote">On May 26, 2016 9:44 AM, "Silent Leaf" &lt;<a href="mailto:silent.leaf0 <at> gmail.com">silent.leaf0 <at> gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="quote">I understand your example. Still it's useless if we need the value of the multiplied vectors, more than just a list of their lengths after the operation, unless i missed something.<br><br>At any rate; I'm trying to create a representation of mathematical sets. The tricky part being, they're precisely capable to handle any kind of content, including themselves. But I think I went too overboard, trying to handle the idea of sets that could contain strictly any type (at once). In practice, the basic elements will be rather similar, and known enough at least so that I can merely use ADTs for the various "types" of elements, and same for sets themselves.<br>If needed I can create two instances of monoids, one for And, one for Or, using newtype wrappers. It's vaguely a hassle but anyway it'll only be useful if i have to create functions that could work on both monoids (separately), which would be interesting enough so i don't merely duplicate the job.<br>There's also the possibility i need to use existing functions already using monoids...<br>For now I think i'll be ok with ADTs and one common wrapper for all elements.<br><br>Thanks still, I'll think about your idea, it's rather interesting.<div class="elided-text">
<br><br>Le&nbsp;mardi 24 mai 2016, Daniel Bergey &lt;<a href="mailto:bergey <at> alum.mit.edu" target="_blank">bergey <at> alum.mit.edu</a>&gt; a &eacute;crit&nbsp;:<br>&gt; On 2016-05-23 at 12:06, Silent Leaf &lt;<a href="mailto:silent.leaf0 <at> gmail.com" target="_blank">silent.leaf0 <at> gmail.com</a>&gt; wrote:<br>&gt;&gt; Say there's a class, many types that can instantiate it. Then, i in fact need to be able<br>&gt;&gt; to concatenate (mappend would be ideal!), make lists of values of different types, all<br>&gt;&gt; instantiating the class.<br>&gt;<br>&gt; In most cases, when Haskell beginners want to make a list that contains<br>&gt; several types from a single type class, there's a better way to organize<br>&gt; the code.&nbsp; If you post your code, I'll try to suggest a specific<br>&gt; solution.<br>&gt;<br>&gt; In general, try to find a simple data type that captures the same fields<br>&gt; &amp; functions as an unknown type that is part of the type class.&nbsp; Here's<br>&gt; an example.<br>&gt;<br>&gt; We have a type class for vectors in a metric space, and instances for<br>&gt; 2D, 3D, etc.<br>&gt;<br>&gt;&gt; class Metric v where<br>&gt;&gt;&nbsp; &nbsp; &nbsp;length :: v -&gt; Double<br>&gt;&gt;&nbsp; &nbsp; &nbsp;(*^) :: Double -&gt; v -&gt; v<br>&gt;<br>&gt; This class has the law:&nbsp; s * length v == length (s *^ v)<br>&gt;<br>&gt; Instead of a heterogeneous list [ V2 1 2, V3 3 4 5, V4 6 7 8 9], we make<br>&gt; a list that just has the length of each vector, and lets us multiply<br>&gt; those lengths by a scalar.&nbsp; In this case, we don't even need to write a<br>&gt; new data type, the type is simply Double.&nbsp; We can write:<br>&gt;<br>&gt;&gt; [ length (V2 1 2), length (V3 3 4 5), length (V4 6 7 8 9) ]<br>&gt;<br>&gt; And (*) gives us what Metric does with (*^).&nbsp; Of course, with your<br>&gt; class, it's probably not so obvious how to transform the class this way.<br>&gt;<br>&gt; It's certainly possible to make a record with functions as members,<br>&gt; moving in the object-oriented direction.&nbsp; Existential types (with a<br>&gt; class constraint inside the data constructor) are even more rarely used.<br>&gt;<br>&gt; cheers,<br>&gt; bergey<br>&gt;
</div>
<br>_______________________________________________<br>
Beginners mailing list<br><a href="mailto:Beginners <at> haskell.org">Beginners <at> haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br><br>
</blockquote>
</div>
</div>
Cezar Elnazli | 23 May 22:26 2016
Picon

All About Monads

Hello,

I am currently going through "All About Monads" on the Haskell Wiki. I see that
it also has a Github repository[1]. However, the repository seems outdated to
the point where the Makefile no longer works (I was not able to build the wiki),
some (if not most) of the examples no longer compile, or they do so with warnings
(e.g. example12.hs), and even the formatting of the published article on the wiki
seems broken.

What I'm asking is if the repository I mentioned is the correct one, and if it
makes any sense to send a pull request or if it is worth the effort to fork it
and update the code.

Thanks!

[1]: https://github.com/dag/all-about-monads

Silent Leaf | 23 May 18:06 2016
Picon

How to best handle classes of types, interactions and listing of different types?

Hi! I'm still studying the theory of Haskell, but i also wanted to start dabbling with guideless coding, all by myself, and it happens experience is just as much important as theoretical knowledge! I'm not surprise mind you :P

Say there's a class, many types that can instantiate it. Then, i in fact need to be able to concatenate (mappend would be ideal!), make lists of values of different types, all instantiating the class.

I'm a bit lost on this. There are at least two sorts of ways to handle said group of types, but i'm not certain either is best, and i'm not even very much satisfied about either. Plus they don't specifically differ as regards handling of listing or otherwise interacting *between* different instances of the same class (or alternately, different types born from the same Type constructor).

First idea i had, was based on making a class indeed, as well i just love this type of polymorphism (visavis other paradigms). Each type would only have to instantiate the key metshods, and no need of wrappers to use said methods, so on this respect it's pretty great.
However, as soon as we want operations between values of different types, it rather gets tricky.
The only way i know of to make a heterogeneous list is to use ExistentialQuantificators, create a newtype (or data?) wrapper for the class, allowing for any type to be in, without parameters.
Now, the problem i have with this, is the wrapping: if i wanna make a list of types, i gotta wrap all values, and if this list becomes member of a superlist of the same polymorphic type, i gotta wrap this very sublist again with the "class wrapper". Maybe i'm imagining problems and i won't actually need to touch too much to the wrapping if i write the correct functions or instances, but from where i am, permanent wrapping seems tiresome, very much in fact removes the purpose of a class: to allow polymorphic functions without need to wrap the types of inputs/outputs inside a newtype.

Which lead me to the second solution: forget the class, and make a type constructor that basically gets a list of key-methods and one field for the wrapped type. Basically it amounts to OOP, at least it seems so. I'm not really a big fan of the thing, and eventually i realized it wouldn't help me more visavis trans-type methods, especially an idea of one or more monoidal instances for the class, or the type constructor that replaces it.
(Actually I'm not wholly certain as of how I'm supposed to handle Type constructors instead of classes, as I only know how to make heterogeneous out of a class, not out of a type constructor, even if its polymorphic key-methods are fields included in it. (hope i'm being clear enough, don't hesitate telling me otherwise!)

So, as I'm kinda beginner as regards actual coding, i'm asking advice on the subject. Maybe the problem is in how i look at the problem, and I shouldn't even be there trying to do what i try to do. Any alternative solution or viewpoint is heartily welcome!
I resume my problem once more: how to handle cross-type interactions and grouping when they only have a class in common, and if possible without having to use ExistentialQuantificators, unless there's a way to keep the wrappers far away, invisible, automatic.

Thanks a lot in advance! (Ideas of specialized tutorials are also very much welcome!)

<div><p>Hi! I'm still studying the theory of Haskell, but i also wanted to start dabbling with guideless coding, all by myself, and it happens experience is just as much important as theoretical knowledge! I'm not surprise mind you :P<br><br>Say there's a class, many types that can instantiate it. Then, i in fact need to be able to concatenate (mappend would be ideal!), make lists of values of different types, all instantiating the class.<br><br>I'm a bit lost on this. There are at least two sorts of ways to handle said group of types, but i'm not certain either is best, and i'm not even very much satisfied about either. Plus they don't specifically differ as regards handling of listing or otherwise interacting *between* different instances of the same class (or alternately, different types born from the same Type constructor).<br><br>First idea i had, was based on making a class indeed, as well i just love this type of polymorphism (visavis other paradigms). Each type would only have to instantiate the key metshods, and no need of wrappers to use said methods, so on this respect it's pretty great.<br>However, as soon as we want operations between values of different types, it rather gets tricky.<br>The only way i know of to make a heterogeneous list is to use ExistentialQuantificators, create a newtype (or data?) wrapper for the class, allowing for any type to be in, without parameters.<br>Now, the problem i have with this, is the wrapping: if i wanna make a list of types, i gotta wrap all values, and if this list becomes member of a superlist of the same polymorphic type, i gotta wrap this very sublist again with the "class wrapper". Maybe i'm imagining problems and i won't actually need to touch too much to the wrapping if i write the correct functions or instances, but from where i am, permanent wrapping seems tiresome, very much in fact removes the purpose of a class: to allow polymorphic functions without need to wrap the types of inputs/outputs inside a newtype.<br><br>Which lead me to the second solution: forget the class, and make a type constructor that basically gets a list of key-methods and one field for the wrapped type. Basically it amounts to OOP, at least it seems so. I'm not really a big fan of the thing, and eventually i realized it wouldn't help me more visavis trans-type methods, especially an idea of one or more monoidal instances for the class, or the type constructor that replaces it.<br>(Actually I'm not wholly certain as of how I'm supposed to handle Type constructors instead of classes, as I only know how to make heterogeneous out of a class, not out of a type constructor, even if its polymorphic key-methods are fields included in it. (hope i'm being clear enough, don't hesitate telling me otherwise!)<br><br>So, as I'm kinda beginner as regards actual coding, i'm asking advice on the subject. Maybe the problem is in how i look at the problem, and I shouldn't even be there trying to do what i try to do. Any alternative solution or viewpoint is heartily welcome!<br>I resume my problem once more: how to handle cross-type interactions and grouping when they only have a class in common, and if possible without having to use ExistentialQuantificators, unless there's a way to keep the wrappers far away, invisible, automatic.<br><br>Thanks a lot in advance! (Ideas of specialized tutorials are also very much welcome!)
</p></div>
Silent Leaf | 20 May 18:36 2016
Picon

How to write console apps? Can't find any library, tutorial... at all

All in the title!

I'm seeking a way to write a console app that isn't just asking questions one line after another with putStr and getLine. More something like Vim or Emacs when they're in the terminal (i don't wanna create a text ed, but it's the kind of programs i'm seeking to write: which takes up all the space on the screen, where you can write at many different places, and keyboard-driven, up to why not mouse- too, if the terminal (and haskell bindings) allow it.

So, does anyone know any library to do this? Any tutorial, maybe? I'm seeking for hours, but every time i type stuff like "console application haskell" in google, it just gives me irrelevant answers --as is the trend it seems subjectively, of those last months, with our bestest G-friend. :(

thanks a lot in advance for anything!

<div><p>All in the title!<br><br>I'm seeking a way to write a console app that isn't just asking questions one line after another with putStr and getLine. More something like Vim or Emacs when they're in the terminal (i don't wanna create a text ed, but it's the kind of programs i'm seeking to write: which takes up all the space on the screen, where you can write at many different places, and keyboard-driven, up to why not mouse- too, if the terminal (and haskell bindings) allow it.<br><br>So, does anyone know any library to do this? Any tutorial, maybe? I'm seeking for hours, but every time i type stuff like "console application haskell" in google, it just gives me irrelevant answers --as is the trend it seems subjectively, of those last months, with our bestest G-friend. :(<br><br>thanks a lot in advance for anything!
</p></div>
Tilmann | 19 May 15:12 2016
Picon
Picon

Code golf

given:

inputA :: IO String

inputB :: IO String

update :: String -> String -> IO ()

Is there an elegant way to refactor / code golf this:

doIt :: IO ()
doIt = do
   a <- inputA
   b <- inputB
   update a b

liftM2 doesn't work in this case..

Thank you!
Mihai Maruseac | 19 May 01:46 2016
Picon
Gravatar

ANNOUNCE: Haskell Communities and Activities Report (30th ed., May 2016)

On behalf of all the contributors, we are pleased to announce that the

           Haskell Communities and Activities Report
                (30th edition, May 2016)

is now available, in PDF and HTML formats:

  http://haskell.org/communities/05-2016/report.pdf
  http://haskell.org/communities/05-2016/html/report.html

All previous editions of HCAR can be accessed on the wiki at
https://wiki.haskell.org/Haskell_Communities_and_Activities_Report

Many thanks go to all the people that contributed to this report,
both directly, by sending in descriptions, and indirectly, by doing
all the interesting things that are reported. We hope you will find
it as interesting a read as we did.

If you have not encountered the Haskell Communities and Activities
Reports before, you may like to know that the first of these reports
was published in November 2001. Their goal is to improve the
communication between the increasingly diverse groups, projects, and
individuals working on, with, or inspired by Haskell. The idea behind
these reports is simple:

  Every six months, a call goes out to all of you enjoying Haskell to
  contribute brief summaries of your own area of work. Many of you
  respond (eagerly, unprompted, and sometimes in time for the actual
  deadline) to the call. The editors collect all the contributions
  into a single report and feed that back to the community.

When we try for the next update, six months from now, you might want
to report on your own work, project, research area or group as well.
So, please put the following into your diaries now:

========================================
                     End of September 2016:
           target deadline for contributions to the
        November 2016 edition of the HCAR Report
========================================

Unfortunately, many Haskellers working on interesting projects are so
busy with their work that they seem to have lost the time to follow
the Haskell related mailing lists and newsgroups, and have trouble even
finding time to report on their work. If you are a member, user or
friend of a project so burdened, please find someone willing to make
time to report and ask them to "register" with the editors for a simple
e-mail reminder in November (you could point us to them as well, and we
can then politely ask if they want to contribute, but it might work
better if you do the initial asking). Of course, they will still have to
find the ten to fifteen minutes to draw up their report, but maybe we
can increase our coverage of all that is going on in the community.

Feel free to circulate this announcement further in order to
reach people who might otherwise not see it. Enjoy!

--

-- 
Mihai Maruseac (MM)
"If you can't solve a problem, then there's an easier problem you can
solve: find it." -- George Polya
Tushar Tyagi | 18 May 12:24 2016
Picon
Gravatar

Understanding Monads: Help with 20 Intermediate Haskell Exercises

Hi,

In order to wrap my head around Applicatives and Monads, I started doing the
exercises at http://blog.tmorris.net/posts/20-intermediate-haskell-exercises/

The main class being used for the questions is:
class Misty m where banana :: (a -> m b) -> m a -> m b unicorn :: a -> m a furry' :: (a -> b) -> m a -> m b
Question #13 asks to create the following function:


apple :: (Misty m) => m a -> m (a -> b) -> m b
After thinking for around an hour for this, I could not crack it and tried
looking at other people's solutions, two of which are:


apple = banana . flip furry'
apple ma mab = banana (\ab -> furry' ab ma) mab

I also tried hoogle to see what this function is in the real world, and the
underlying implementation in the source code. Turns out, one of the
applicatives uses this flip technique (monads use a different one):

(<**>) = liftA2 (flip ($))
Although the code compiles with the solutions, I am still not able to wrap my
head around them.

For instance, from what I understand from composition, the output of one function
becomes the input of the next one. But the input and outputs of these functions vary:

banana :: Misty m => (a -> m b) -> m a -> m b
flip furry' :: Misty m => m a -> (a -> b) -> m b

banana . flip furry' :: Misty m => m a -> m (a -> b) -> m b
I am thinking that the entire `(a -> b) -> m b` in flip furry' is being sent to banana
as the first argument: (a -> m b)
, but what happens after that?

In the second solution, the types pass, i.e. the lambda is basically furry' which has the type
a -> ... -> m b, exactly what is needed in the call to banana. But where will it get the
function ab? And how will banana work with the second argument? The definition in the
class requires it to be `m a`, but here we are passing it `m a -> m b`.

Sorry for such a long post, but I want to understand this wizardry .

Thanks,
Tushar
<div><div dir="ltr">
<div>
<div>Hi,<br><br>
</div>In order to wrap my head around Applicatives and Monads, I started doing the <br>exercises at <a href="http://blog.tmorris.net/posts/20-intermediate-haskell-exercises/">http://blog.tmorris.net/posts/20-intermediate-haskell-exercises/</a> <br><br>
</div>The main class being used for the questions is:<br><div>
<span class="">class</span> <span class="">Misty</span> m <span class="">where</span>
<span class="">  banana ::</span> (a <span class="">-&gt;</span> m b) <span class="">-&gt;</span> m a <span class="">-&gt;</span> m b
<span class="">  unicorn ::</span> a <span class="">-&gt;</span> m a<span class=""></span>
<span class="">  furry' ::</span> (a <span class="">-&gt;</span> b) <span class="">-&gt;</span> m a <span class="">-&gt;</span> m b
<span><br>Question #13 asks to create the following function:</span><br><br><span class="">apple ::</span> (<span class="">Misty</span> m) <span class="">=&gt;</span> m a <span class="">-&gt;</span> m (a <span class="">-&gt;</span> b) <span class="">-&gt;</span> m b
<span class=""><br></span><span class=""><span class=""><span>After thinking for around an hour for this, I could not crack it and tried <br>looking at other people's solutions, two of which are:</span><br></span><br><span class="">apple <span class="">=</span> banana <span class="">.</span> <span class="">flip</span> furry'<br>apple ma mab = banana (\ab -&gt; furry' ab ma) mab<br><br></span></span><span class=""></span><span class="">I also tried hoogle to see what this function is in the real world, and the <br>underlying implementation in the source code. Turns out, one of the <br>applicatives uses this flip technique (monads use a different one):<br><br></span><span class="">(&lt;**&gt;) = liftA2 (flip ($))</span><span></span><br><span class=""><span>Although the code compiles with the solutions, I am still not able to wrap my<br>head around them. <br><br></span></span><span class=""><span>For instance, from what I understand from composition, the output of one function <br>becomes the input of the next one. But the input and outputs of these functions vary:<br><br><span>banana :: Misty m =&gt; (a -&gt; m b) -&gt; m a -&gt; m b<br>flip furry' :: Misty m =&gt; m a -&gt; (a -&gt; b) -&gt; m b<br><br>banana . flip furry' :: Misty m =&gt; m a -&gt; m (a -&gt; b) -&gt; m b<br></span></span></span><span><span>I am thinking that the entire <span>`(a -&gt; b) -&gt; m b</span>` in <span>flip furry</span>'</span> </span><span>is being sent to <span>banana </span><br>as the first argument: <span>(a -&gt; m b)</span></span>, <span>but what happens after that?</span><br><br><span>In the second solution, the types pass, i.e. the lambda is basically <span>furry'</span> which has the type<br><span>a -&gt; ... -&gt; m b</span>, exactly what is needed in the call to <span>banana</span>. But where will it get the <br>function <span>ab</span>? And how will banana work with the second argument? The definition in the <br>class requires it to be <span>`m a`</span>, but here we are passing it <span>`m a -&gt; m b`</span>.</span><br>Sorry for such a long post, but I want to understand this wizardry . <br><br>
</div>
<div>Thanks,<br>
</div>
<div>Tushar<br>
</div>
</div></div>
Silent Leaf | 14 May 23:39 2016
Picon

can I use "pure" all the time instead of "return" now?

All in the title; Since the change in GHC, 7.10 i think, where all Monad instances had to have Applicative instances too, in theory all monads must have a pure method that should be identical to return, right?

My subjectively superficial reason for preferring pure (and caring about the issue in the first place) is twofold: shorter (i know, i know, still the shorter, the quicker to read and then understand in the code) and, mostly, less semantically-awkward --honestly the name "stains" the functional semantics in Monadic code, in my opinion, but that's just personal. (For those who know, it feels like the "new" operator in JS (OO class-instanciation semantical imitation))

Of course now I'm perfectly used to, have no trouble seeing it for what it is all the time, not mixing it up with some imperative-like "return" concept.
Yet i don't really like it much at all, so I wanted to know to which extent it is safe to always use pure even in explicitly Monadic contexts.

Thankx in advance!

<div><p>All in the title; Since the change in GHC, 7.10 i think, where all Monad instances had to have Applicative instances too, in theory all monads must have a pure method that should be identical to return, right?<br><br>My subjectively superficial reason for preferring pure (and caring about the issue in the first place) is twofold: shorter (i know, i know, still the shorter, the quicker to read and then understand in the code) and, mostly, less semantically-awkward --honestly the name "stains" the functional semantics in Monadic code, in my opinion, but that's just personal. (For those who know, it feels like the "new" operator in JS (OO class-instanciation semantical imitation))<br><br>Of course now I'm perfectly used to, have no trouble seeing it for what it is all the time, not mixing it up with some imperative-like "return" concept.<br>Yet i don't really like it much at all, so I wanted to know to which extent it is safe to always use pure even in explicitly Monadic contexts.<br><br>Thankx in advance!
</p></div>
Silent Leaf | 9 May 20:50 2016
Picon

using HS to writing/managing a selfmade filesystem on a real partition?

Mostly all in the title.

I have a project of developing a personal filesystem, possibly at first virtual (the file(s) representing a virtual partition formatted with my filesystem, would be saved in a host filesys, eg ext4 or whatever), but probably in the end not virtual, directly working on the contents of a real partition.

Can haskell do that kind of thing, aka writing data on a partition directly (without using a known filesys), etc? Is it at least more or less adapted for this task (not talking about performances, unless the consequences be a *really* slow filesys), aka doable, easily doable, relatively speaking (aka not worse than with another language)?
Incidentally, if i wanted Linux to recognize the filesys, i've heard one has to write a module and put it in connection with the kernel or something. could haskell do that?

if that's a "no" somewhere for one of my questions, which parts can't be written in haskell (without horrible performances or code very very hard to write), and can they be written in C (or whatever) as foreign functions? which parts would that represent for the whole program?

Thanks a lot in advance!

PS: just in case, tips on sources of information on how to do any of the above will be extremely appreciated! (even if it's in, say C, for that matter, providing there's a way to translate the steps into a haskell program)

<div><p>Mostly all in the title.<br><br>I have a project of developing a personal filesystem, possibly at first virtual (the file(s) representing a virtual partition formatted with my filesystem, would be saved in a host filesys, eg ext4 or whatever), but probably in the end not virtual, directly working on the contents of a real partition.<br><br>Can haskell do that kind of thing, aka writing data on a partition directly (without using a known filesys), etc? Is it at least more or less adapted for this task (not talking about performances, unless the consequences be a *really* slow filesys), aka doable, easily doable, relatively speaking (aka not worse than with another language)?<br>Incidentally, if i wanted Linux to recognize the filesys, i've heard one has to write a module and put it in connection with the kernel or something. could haskell do that?<br><br>if that's a "no" somewhere for one of my questions, which parts can't be written in haskell (without horrible performances or code very very hard to write), and can they be written in C (or whatever) as foreign functions? which parts would that represent for the whole program?<br><br>Thanks a lot in advance!<br><br>PS: just in case, tips on sources of information on how to do any of the above will be extremely appreciated! (even if it's in, say C, for that matter, providing there's a way to translate the steps into a haskell program)
</p></div>

Gmane