Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: using HS to writing/managing a selfmade filesystem on a
real partition? (Silent Leaf)
2. Re: Type depending on value (Dmitriy Matrosov)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 May 2016 17:41:32 +0200
From: Silent Leaf <silent.le...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] using HS to writing/managing a
selfmade filesystem on a real partition?
Message-ID:
<CAGFccjNqu4pZoKNA+=7cfm5z0y0dy6sxnudu2oexyqys68v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Well I plan on writing an FS with Haskell, aka, both "hardware" handling,
(be it in a file (virtual) or on a partition), and filesys operations
(read, write, etc). From there, if I wrote the FUSE in C entirely, i'd go
with rewriting a ton of code that would be far from easy to duplicate from
Haskell.
I used to code in C regularly, but I plan on staying in Haskell for the
time being. Still, you're right, probably better using the existing
bindings. I'll update it if i find bugs, which i hope i won't, I'm not even
sure I'd be up to it, but I'm just beginning anyway --and the code doesn
seem too heavy.
Anyway I'm rambling ^^ Thanks a lot for all those informations!
( And If anyone has good tutorial on FUSE, I'm still interested!)
Le mardi 10 mai 2016, Sylvain Henry <sylv...@haskus.fr> a ?crit :
> Yes you can call Haskell code from C:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-ghc.html#foreign-export-ghc
>
> If you really want to use Haskell, I would go full Haskell to avoid
complications (you can update the FUSE bindings if necessary). On the other
hand, if you plan to distribute your FS implementation to a non-Haskell
audience, maybe it would be better to write it fully in C.
>
>
> On 10/05/2016 20:56, Silent Leaf wrote:
>
> Thanks! FUSE seems a perfect way to do what I wanna do.
>
> Hypothetically, what if I wanted to bypass the Haskell bindings, directly
use FUSE in C, but write most of the actual operations in Haskell?
> AKA, is it possible to call haskell functions/programs *from* C code? And
have all individual calls to the Haskell parts be allowed to share private
data, rather than being independent, isolated calls?
>
> It's just an idea, I figured since writing a fuse filesystem in C doesn't
seem too complicated (i found a tutorial, and it just looks like what the
Haskell bindings is proposing, except well in theory one has to write
everything in C) and i figured perhaps it'd be better/faster, possibly less
buggy (the Haskell bindings are tagged experimental, of which i couldn't
tell the true interpretation, but which doesn't seem terribly appealing at
first sight) to write the FUSE in C, *except* for, well most of the actual
"doing something" code, aka the FS operations, which would be written in
Haskell.
>
> AKA, the final program would start with C, but under the hood use Haskell
for most of the meaningful code. This, of course, if such a thing is even
possible in the first place! And easily, needless to say. Considering for
that matter as I said that the Haskell parts should be able to save private
data of its own without having to "start over" the "situation analysis" for
each individual call to one of the filesystem operations.
>
> Thanks a lot again!
>
> Le lundi 9 mai 2016, Sylvain Henry <sylv...@haskus.fr> a ?crit :
>> Hi,
>>
>> You don't have to write a kernel module (which would better be written
in C), you can do everything in userspace and in Haskell with FUSE:
https://en.wikipedia.org/wiki/Filesystem_in_Userspace
>> It seems to already have Haskell bindings:
https://hackage.haskell.org/package/HFuse-0.2.4.5/docs/System-Fuse.html
>>
>> To implement the file system operations, you can use binary (
https://hackage.haskell.org/package/binary), Foreign.Ptr, Data.Bits, etc.
You can write data on any real partition by using the associated block
devices (e.g., /dev/sda1).
>>
>> Sylvain
>>
>> On 09/05/2016 20:50, Silent Leaf wrote:
>>
>> 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)
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160511/c5763c9a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 12 May 2016 12:16:42 +0300
From: Dmitriy Matrosov <sgf....@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Type depending on value
Message-ID:
<CAFdVUFmRNJA=e6_pb-s-rx7436pzrry1juphjpxxqaayuc+...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> {-# LANGUAGE DataKinds, GADTs, StandaloneDeriving, Rank2Types, PolyKinds,
> FlexibleInstances, MultiParamTypeClasses, FunctionalDependencies,
> ScopedTypeVariables #-}
>
> data Nat = Z | S Nat
> deriving (Show)
On Fri, May 6, 2016 at 2:24 PM, Marcin Mrotek
<marcin.jan.mro...@gmail.com> wrote:
> You could define SNat as something
> newtype SNat (n :: Nat) = SNat Nat
> deriving (Show)
> to be on the safer side, and then define SNatClass and natVal as something
> like:
> class SNatClass (n :: Nat) where
> singN :: SNat n
>
> instance SNatClass Z where
> singN = SNat Z
>
> instance SNatClass n => SNatClass (S n) where
> singN = SNat (S n)
> where SNat n = (singN :: SNat n)
>
> natVal :: forall n proxy. SNatClass n => proxy n -> Nat
> natVal _ = case (singN :: SNat n) of SNat n -> n
Hi.
Hm.. but such singleton definition differs from mine and i can't get it
working. Your singleton defines function `type -> singleton`:
*Main> singN :: SNat ('S 'Z)
SNat (S Z)
and function `type -> Nat`:
*Main> natVal (undefined :: SNat ('S 'Z))
S Z
Mine singleton:
> data SNat2 :: Nat -> * where
> SZ :: SNat2 'Z
> SN :: SNat2 n -> SNat2 ('S n)
> deriving instance Show (SNat2 n)
>
> class SNatClass2 (a :: Nat) where
> singN2 :: SNat2 a
>
> instance SNatClass2 'Z where
> singN2 = SZ
> instance SNatClass2 n => SNatClass2 ('S n) where
> singN2 = SN singN2
>
> natVal2 :: forall p n. SNatClass2 n => p n -> Nat
> natVal2 _ = case singN2 :: SNat2 n of
> SZ -> Z
> SN SZ -> S Z
does this too:
*Main> singN2 :: SNat2 ('S 'Z)
SN SZ
*Main> natVal2 (undefined :: SNat2 ('S 'Z))
S Z
But mine singleton also defines function `singleton -> type`:
*Main> :t SN SZ
SN SZ :: SNat2 ('S 'Z)
which yours does not:
*Main> :t SNat (S Z)
SNat (S Z) :: SNat n
or in other words:
*Main> :t SN SZ :: SNat2 'Z
<interactive>:1:1:
Couldn't match type ?'S 'Z? with ?'Z?
Expected type: SNat2 'Z
Actual type: SNat2 ('S 'Z)
In the expression: SN SZ :: SNat2 Z
but
*Main> :t SNat (S Z) :: SNat 'Z
SNat (S Z) :: SNat 'Z :: SNat 'Z
Then when i try to define recursive function on singletons, i need that
relation:
> data Vec :: * -> Nat -> * where
> Nil :: Vec a 'Z
> Cons :: a -> Vec a n -> Vec a ('S n)
> deriving instance Show a => Show (Vec a n)
>
> natVec2 :: SNat2 n -> Vec Int n
> natVec2 SZ = Nil
> natVec2 (SN n) = Cons 1 (natVec2 n)
as i understand, here (in `natVec2`) pattern matching on value level
introduces type equalities (n ~ 'Z) or (n ~ 'S n) at type level
correspondingly.
But with your singleton it can't be done that way. I've tried to use witness
(well, i've probably used it wrong, but still..), but can't figure out how to
specify "if (n ~ 'S m), then" at type level:
> data SingInst (n :: Nat) where
> SingInst :: SNatClass n => SingInst n
>
> singInst :: forall p n. SNatClass n => p ('S n) -> SingInst n
> singInst _ = case (singN :: SNat ('S n)) of
> SNat _ -> SingInst
>
> natVec :: forall p n. SNatClass2 n => p n -> Vec Int n
> natVec _ = case (singN :: SNat n) of
> SNat Z -> Nil
> SNat (S n) -> natVec (singInst (singN :: SNat n))
Is there a way to define `natVec` with your singleton?
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 95, Issue 18
*****************************************
