Re: [Haskell-cafe] object oriented technique
Tillmann,
Thank you for your detailed reply. It was a real eye opener. I
hadn't seen anything like that before.
It seems that your ShapeClass is very similar to, and plays the same
role as, the Class ShapeC from my example. I wonder if that was how
haskellers implemented shared functions before type classes were
invented.
One advantage that I see in your approach is that you only need one
function, "call", that can be used to dereference any method in
ShapeClass. In my example, I needed to define ShapeC ShapeD instances
for both draw and copyTo.
I suppose one nice aspect of using a type class is that the copyTo
method can be applied to a Rectangle to give another Rectangle, or to
a Circle, or to a generic ShapeD to give a generic ShapeD. The copyTo
function in your example produces a generic shape.
Thanks again for your help.
Tad
On Wed, Mar 30, 2011 at 2:57 AM, Tillmann Rendel
wrote:
> Hi,
>
> Steffen Schuldenzucker wrote:
>>
>> data Shape = Shape {
>> draw :: String
>> copyTo :: Double -> Double -> Shape
>> }
>
> Tad Doxsee wrote:
>>
>> Suppose that the shape class has 100 methods and that 1000 fully
>> evaluated shapes are placed in a list.
>
> The above solution would store the full method table with each object.
> Instead, we could share the method tables between objects. An object would
> then uniformly contain two pointers: One pointer to the method table, and
> one poiner to the internal state.
>
> {-# LANGUAGE ExistentialQuantification, Rank2Types #-}
>
> data Object methods = forall state . Object {
> methods :: methods state,
> state :: state
> }
>
> Calling a method requires dereferencing both pointers.
>
> call :: (forall state . methods state -> state -> a) ->
> (Object methods -> a)
> call method (Object methods state) = method methods state
>
>
> Using this machinery, we can encode the interface for shapes.
>
> data ShapeClass state = ShapeClass {
> draw :: state -> String,
> copyTo :: state -> Double -> Double -> Shape
> }
>
> type Shape = Object ShapeClass
>
>
> An implementation of the interface consists of three parts: A datatype or
> the internal state, a method table, and a constructor.
>
> data RectangleState = RectangleState {rx, ry, rw, rh :: Double}
>
> rectangleClass :: ShapeClass RectangleState
> rectangleClass = ShapeClass {
> draw = \r ->
> "Rect (" ++ show (rx r) ++ ", " ++ show (ry r) ++ ") -- "
> ++ show (rw r) ++ " x " ++ show (rh r),
> copyTo = \r x y -> rectangle x y (rw r) (rh r)
> }
>
> rectangle :: Double -> Double -> Double -> Double -> Shape
> rectangle x y w h
> = Object rectangleClass (RectangleState x y w h)
>
>
> The analogous code for circles.
>
> data CircleState = CircleState {cx, cy, cr :: Double}
>
> circleClass :: ShapeClass CircleState
> circleClass = ShapeClass {
> draw = \c ->
> "Circ (" ++ show (cx c) ++ ", " ++ show (cy c)++ ") -- "
> ++ show (cr c),
> copyTo = \c x y -> circle x y (cr c)
> }
>
> circle :: Double -> Double -> Double -> Shape
> circle x y r
> = Object circleClass (CircleState x y r)
>
>
> Rectangles and circles can be stored together in usual Haskell lists,
> because they are not statically distinguished at all.
>
> -- test
> r1 = rectangle 0 0 3 2
> r2 = rectangle 1 1 4 5
> c1 = circle 0 0 5
> c2 = circle 2 0 7
>
> shapes = [r1, r2, c1, c2]
>
> main = mapM_ (putStrLn . call draw) shapes
>
>
> While this does not nearly implement all of OO (no inheritance, no late
> binding, ...), it might meet your requirements.
>
> Tillmann
>
> PS. You could probably use a type class instead of the algebraic data type
> ShapeClass, but I don't see a benefit. Indeed, I like how the code above is
> very explicit about what is stored where. For example, in the code of the
> rectangle function, it is clearly visible that all shapes created with that
> function will share a method table.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computational Physics in Haskell
31.03.2011 08:57, Mihai Maruseac пишет: On Thu, Mar 31, 2011 at 1:50 AM, KC wrote: I'd also like to know of any Haskell programs for theoretical/computational physics. H! Maybe converting such programs to Haskell. On Wed, Mar 30, 2011 at 11:23 AM, Azeem -ul-Hasan wrote: I started learning Haskell a little while ago. Although I am a novice I am still in love with it. I am physics major and primarily interested in Theoretical Physics and would like to use Haskell in this area. So, I just know to what has been done in this area, are there any libraries for simulating physical process in Haskell etc. Don't know if this is what you're looking for but I found this pages: [1], [2], [3]. Maybe one of them will contain what you're looking for. [1]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:physics [2]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:scientific%20simulation [3]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:simulation I think that Aivika[3] doesn't suit this task, although it can integrate the ordinary differential equations but they are relatively slow as the focus was mainly on the hybrid simulation and DES. As far as I understand, the fields are quite different. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computational Physics in Haskell
On Thu, Mar 31, 2011 at 1:50 AM, KC wrote: > I'd also like to know of any Haskell programs for > theoretical/computational physics. > > H! > > Maybe converting such programs to Haskell. > > > On Wed, Mar 30, 2011 at 11:23 AM, Azeem -ul-Hasan wrote: >> I started learning Haskell a little while ago. Although I am a novice I am >> still in love with it. >> I am physics major and primarily interested in Theoretical Physics and would >> like to use Haskell in this area. So, I just know to what has been done in >> this area, are there any libraries for simulating physical process in >> Haskell etc. > Don't know if this is what you're looking for but I found this pages: [1], [2], [3]. Maybe one of them will contain what you're looking for. [1]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:physics [2]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:scientific%20simulation [3]: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:simulation -- Mihai ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wed, Mar 30, 2011 at 21:07, Ivan Lazar Miljenovic < ivan.miljeno...@gmail.com> wrote: > On 31 March 2011 14:51, John Millikin wrote: > > Linux, OSX, and (probably?) FreeBSD use UTF8. > > For Linux, doesn't it depend upon the locale rather than forcing UTF-8? > In theory, yes. There are environment to specify the locale encoding, and some applications attempt to obey them. In practice, no. Both Qt and GTK+ use UTF8 internally, and react poorly when run on a non-UTF8 system. Every major distribution sets the locale encoding to UTF8. Setting a non-UTF8 encoding requires digging through various undocumented configuration files, and even then many applications will simply ignore it and use UTF8 anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to optmize this code?
Thank you very much for the suggestions. giba ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 31 March 2011 14:51, John Millikin wrote: > Linux, OSX, and (probably?) FreeBSD use UTF8. For Linux, doesn't it depend upon the locale rather than forcing UTF-8? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to optmize this code?
On Wed, Mar 30, 2011 at 2:39 PM, Gilberto Garcia wrote: > fkSum :: Int -> [Int] -> Int > fkSum a [] = 0 > fkSum a (b) = foldl (+) 0 (filter (\x -> isMultiple x b) [1..a]) Daniel Fischer and Yves Parès gave you good suggestions about implementing a different, better algorithm for you problem. However, there's one small thing about your current code. Instead of foldl, you should use foldl' (use "import Data.List"), which is strict in the accumulator. Most of the time you want foldl' instead of foldl. You can learn more about the list folds here [1]. HTH, [1] http://www.haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wednesday, March 30, 2011 9:07:45 AM UTC-7, Michael Snoyman wrote: > > Thanks to you (and everyone else) for the informative responses. For > now, I've simply hard-coded in UTF-8 encoding for all non-Windows > systems. I'm not sure how this will play with OSes besides Windows and > Linux (especially Mac), but it's a good stop-gap measure. > > Linux, OSX, and (probably?) FreeBSD use UTF8. It's *possible* for a Linux file path to contain arbitrary bytes, but every application I've ever seen just gives up and writes [[invalid character]] symbols when confronted with such. OSX's chief weirdness is that its GUI programs swap ':' and '/' when displaying filenames. So the file "hello:world.txt" will show up as "hello/world.txt" in Finder. It also performs Unicode normalization on your filenames, which is mostly harmless but can have unexpected results on unicode-naïve applications like rsync.** I don't know how its normalization interacts with invalid file paths, or whether it even allows such paths to be written. Window's weirdness is its multi-root filesystem, and also that it distinguishes between absolute and non-relative paths. The Windows path "/foo.txt" is *not* absolute and *not* relative. I've never been able to figure out how Windows does Unicode; it seems to have a half-dozen APIs for it, all subtly different, and not a single damn one displays anything but "???.txt" when I download anything east-Asian. I *do* think it would be incredibly useful to provide alternatives to > all the standard operations on FilePath which used opaque datatypes > and properly handles filename encoding. I noticed John Millikin's > system-filepath package[1]. Do people have experience with it? It > seems that adding a few functions like getDirectoryContents, plus > adding a version of toString which performs some character decoding, > would get us pretty far. > system-filepath was my frustration with the somewhat bizarre behavior of some functions in "filepath"; I designed it to match the Python os.path API pretty closely. I don't think it has any client code outside of my ~/bin , so changing its API radically shouldn't cause any drama. I'd prefer filesystem manipulation functions be put in a separate library (perhaps "system-directory"?), to match the current filepath/directory split. If it's to contain encoding-aware functions, I think they should be Text-only. The existing String-based are just to interact with legacy functions in System.IO, and should be either renamed to "toChar8/fromChar8" or removed entirely. My vote to the second -- if someone needs Char8 strings, they can convert from the ByteString version explicitly. -- -- | Try to decode a FilePath to Text, using the current locale encoding. If -- the filepath is invalid in the current locale, it is decoded as ASCII and -- any non-ASCII bytes are replaced with a placeholder. -- -- The returned text is useful only for display to the user. It might not be -- possible to convert back to the same or any 'FilePath'. toText :: FilePath -> Text -- | Try to encode Text to a FilePath, using the current locale encoding. If -- the text cannot be represented in the current locale, returns 'Nothing'. fromText :: Text -> Maybe FilePath -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wednesday, March 30, 2011 12:18:48 PM UTC-7, Bas van Dijk wrote: > It would also be great to have a package which combines the proper > encoding/decoding of filepaths of the system-filepath package with the > type-safety of the pathtype package: > http://hackage.haskell.org/package/pathtype > Does that package actually work well? I don't see how it can; it's not possible to determine whether a path like "/foo/bar" or "C:\foo\bar" refers to a file or directory, so any user input has to be [[ Path ar fd ]]. And since the filesystem's out of our control, even functions like [[ checkType :: Path ar fd -> IO (Either (FilePath ar) (DirPath ar)) can't provide any meaningful result. And that's before getting into UNIX symlinks, which can be files and directories at the same time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 175
Welcome to issue 175 of the HWN, a newsletter covering developments in the [1]Haskell community. This release covers the week of March 20 - 26. You can find the HTML version at: http://bit.ly/gs9Rr8 Announcements Wren Ng Thornton [2]announced the release of unix-bytestring: Unix/Posix-specific functions for ByteStrengs. John Lato [3]announced an incremental update to the ListLike package. "This version adds newtype wrappers for strict and lazy ByteString, CharString, and CharStringLazy..." Mario Blazevic [4]announced the release of incremental-parser, which provides the usual set of Applicative and monad combinators with a few twists that make it unique. Duncan Coutts [5]announced the release of version 0.16.3 of c2hs, the FFI preprocessor tool. Jeff Wheeler [6]announced a new release of Yi, the text editor written in and extensible in Haskell. Christiaan Baaij [7]announced an incremental upgrade to 0.1.3.0 to CLaSH. Mario Blazevic [8]announced updates to monad-parallel, monad-coroutine, and SCC (Streaming Component Combinators). John Millikin [9]announced an update to enumerator to version 0.4.8. Quotes of the Week * Squarism: wo utilizing any tricks, i want 20 miljon rabbits to mate with each other once.. how many mate event will there be * mm_freak: using combinators instead of explicit recursion can be justified with about the same reasoning as using 'while' instead of explicit 'goto' in imperative programming * monochrom: <$> is pronounced Jacquelin von Brionée * geheimdienst: what does a pirate say when starting a sentence, then suddenly being hit in the nadgers? arr- ow! * monochrom: 1985 is way more than a decade ago * copumpkin: matlab is horrible as far as language design goes[.] it's fairly convenient for doing stuff in but I need to shower after every time I use it Top Reddit Stories * Debugging trick From (self.haskell), scored 60 with 11 comments. Read on [10]reddit. * Your friendly Haskell JSON library's encoding performance just got 4x faster From (serpentine.com), scored 45 with 2 comments. Read on [12]reddit. Read the [13]original post. * A monad for deterministic parallelism (ICFP'2011 submission) From (community.haskell.org), scored 41 with 8 comments. Read on [14]reddit. Read the [15]original post. * Haskell servers benchmarked against node/ruby/python/php/java. From (docs.yesodweb.com), scored 36 with 12 comments. Read on [16]reddit. Read the [17]original post. * The Yesod Framework and the Case of the Eight Level Monad Transformer Stack From (docs.yesodweb.com), scored 35 with 16 comments. Read on [18]reddit. Read the [19]original post. * Improving Persistent Performance (Yesod Blog) From (docs.yesodweb.com), scored 29 with 1 comments. Read on [20]reddit. Read the [21]original post. * Fast, clean Haskell bindings to Google's Snappy library From (hackage.haskell.org), scored 22 with 8 comments. Read on [22]reddit. Read the [23]original post. * Open Quark on Github (Haskell like Lang on the JVM) From (github.com), scored 15 with 3 comments. Read on [24]reddit. Read the [25]original post. * EclipseFP 2.0.4 released: supports GHC 7 From (jpmoresmau.blogspot.com), scored 15 with 7 comments. Read on [26]reddit. Read the [27]original post. * Demonstrating a Time Leak in Arrowized FRP From (blog.edwardamsden.com), scored 14 with 12 comments. Read on [28]reddit. Read the [29]original post. Top StackOverflow Answers * [30]Reading large file in haskell ? votes: 19 The construct "seq x x" is always useless. If y = seq x x and I force y then this forces x then returns x. This is equivalent to y=x and forcing y. Thus "seq forceEval forceEval" does nothing more than "forceEval". The error with your use of a fold is a common one. You are using a fold to perform a count of the bytes in the input. You should be using ... * [31]What to call a function that splits lists? votes: 12 I believe the function you're describing is breakBefore from the list-grouping package. Data.List.Grouping: http://hackage.haskell.org/packages/archive/list-grouping/0.1.1/doc/html/Data-Li st-Grouping.html ghci:: breakBefore even [3,1,4,1,5,9,2,6,5,3,5,8,9,7,9,3,2,3,8,4,6,2,6] [[3,1],[4,1,5,9],[2],[6,5,3,5],[8,9,7,9,3],[2,3],[8],[4],[6],[2],[6]] Top StackOverflow Questions * [32]Haskell record syntax votes: 16, answers: 1 * [33]Reading large file in haskell? votes: 12, answers: 1 * [34]Haskell laziness - how do I force the IO to happen sooner? votes: 9, answers: 3
[Haskell-cafe] pool, persistent, persistent-sqlite: Space leak
Hello Michael, hello fellow Haskellers, there seems to be a space leak in either 'pool', 'persistent' or 'persistent-sqlite'. From the behaviour I suspect the bug to be in 'pool'. When I run a transaction in an infinite loop, my program keeps eating more and more memory, even if the transaction itself doesn't do anything: forever $ runSqlPool (return ()) pool This doesn't happen for non-pooled connections, i.e. the following code runs in constant space as expected: forever $ runSqlConn (return ()) conn Versions are pool-0.0.1, persistent-0.4.2, persistent-sqlite-0.4.0. It happens for both file and in-memory databases. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ghci] unknown symbol in base-unicode-symbols-0.2.1.2 ...
I can reproduce the problem on my system with GHC-7.0.3. The flag old-base is meant for base libraries before 3.0.3.1 which didn't export a Control.Category module. It looks like I accidentally inverted the logic of the flag. What is weird is that is still builds okay on my system. I would expect that, given the inverted flag logic, Control.Category.Unicode would be missing from the installed package's exposed module list. I fixed the logic of the flag and the bug appears to be gone. I uploaded the fixed version 0.2.1.3. Thanks for the bug report! On 31 March 2011 00:05, John Obbele wrote: > On Wed, Mar 30, 2011 at 10:37:47PM +0200, John Obbele wrote: >> I'm having a problem in GHCi when loading modules relying on the >> base-unicode-symbols package. My prompt gives me the following >> message: >> >> >> ghci $ >> Loading package base-unicode-symbols-0.2.1.2 ... linking ... : >> /home/john/.cabal/lib/base-unicode-symbols-0.2.1.2/ghc-7.0.2/HSbase-unicode-symbols-0.2.1.2.o: >> unknown symbol >> `__stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziCategoryziUnicode_' >> ghc: unable to load package `base-unicode-symbols-0.2.1.2' > > > Oki, so I'm answering to myself: the base-unicode-symbols cabal > file introduces a quirk concerning 'base' version which hides the > symbols in Control.Category.Unicode. > >>> base-unicode-symbols.cabal -- line 42-46 > if !flag(old-base) > build-depends: base >= 3.0 && < 4.4 > else > build-depends: base >= 3.0.3.1 && < 4.4 > exposed-modules: Control.Category.Unicode > > I should contact the maintainer about this … ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computational Physics in Haskell
I'd also like to know of any Haskell programs for theoretical/computational physics. H! Maybe converting such programs to Haskell. On Wed, Mar 30, 2011 at 11:23 AM, Azeem -ul-Hasan wrote: > I started learning Haskell a little while ago. Although I am a novice I am > still in love with it. > I am physics major and primarily interested in Theoretical Physics and would > like to use Haskell in this area. So, I just know to what has been done in > this area, are there any libraries for simulating physical process in > Haskell etc. > Azeem Ul Hasan > School of Science and Engineering, > Lahore University of Management Sciences, > Lahore, Pakistan > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accessing to a Haskell type in C
On Wed, Mar 30, 2011 at 5:27 PM, Yves Parès wrote:
> Hello,
>
> To access a haskell type from C code, do we have to make this type instance
> of Storable (and so to also define an homomorph structure on the C side), or
> does FFI specifies some C function to enable C code to access the fields, or
> even some GHC-specific functions? (Even if I'd prefer a portable way)
>
> I mean, if I have the type:
>
> data Character = Character {
> pos :: (Float, Float),
> size :: Float,
> sprite :: Image
> }
>
> Do I compulsorily have to double its definition on C side:
>
> stuct CCharacter {
> float x;
> float y;
> float size;
> Image sprite;
> }
>
> and then make Character instance of Storable, which will make the program
> *copy* Characters to CCharacters each time that I must call a C function to,
> say, draw a character?
>
I haven't needed to access Haskell data from C, but the way I see it
you have two choices:
* Write a Storable instance for your Haskell type, as you said. Be
sure to use the Haskell CTypes as intermediaries so you don't go crazy
on the other side.
* StablePtr magic and foreign-exported wrapper functions to do all of
your data-manipulation in Haskell. There's less duplication this way,
but perhaps more boiler-plate. Plus you need to manage the lifetime of
the StablePtr.
I don't know of anything else off-hand. Most people focus on going the
other way (using C types in Haskell).
Antoine
> ___
> 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] Accessing to a Haskell type in C
Hello,
To access a haskell type from C code, do we have to make this type instance
of Storable (and so to also define an homomorph structure on the C side), or
does FFI specifies some C function to enable C code to access the fields, or
even some GHC-specific functions? (Even if I'd prefer a portable way)
I mean, if I have the type:
data Character = Character {
pos :: (Float, Float),
size :: Float,
sprite :: Image
}
Do I compulsorily have to double its definition on C side:
stuct CCharacter {
float x;
float y;
float size;
Image sprite;
}
and then make Character instance of Storable, which will make the program
*copy* Characters to CCharacters each time that I must call a C function to,
say, draw a character?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ArrowLoop and streamprocessors
> So loop really doesn't seem to help here, but I couldn't find another > way either to feed outputs back into the system. > What I need is: > Either A B ~> Either C B -> A ~> C > > Does such a thing exist? At this point you don't really have enough structure to define such a feedback loop. Since you have streams of different rates, you need to find some common ground to merge them. The path taken by Reactive is to assign a timestamp to events, and ensure that merging preserves time ordering. Of course you'll immediately run into the problem of simultaneous occurrences, and it depends on the context how you want to resolve them. Also, what you're trying to achieve looks similar to Peakachu, so you might want to check it out, especially the Program abstraction [1]. It even has a feedback combinator with a slightly different signature. Gergely [1] http://hackage.haskell.org/packages/archive/peakachu/0.3.0/doc/html/FRP-Peakachu-Program.html -- http://www.fastmail.fm - mmm... Fastmail... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ghci] unknown symbol in base-unicode-symbols-0.2.1.2 ...
On Wed, Mar 30, 2011 at 10:37:47PM +0200, John Obbele wrote: > I'm having a problem in GHCi when loading modules relying on the > base-unicode-symbols package. My prompt gives me the following > message: > > >> ghci $ > Loading package base-unicode-symbols-0.2.1.2 ... linking ... : > /home/john/.cabal/lib/base-unicode-symbols-0.2.1.2/ghc-7.0.2/HSbase-unicode-symbols-0.2.1.2.o: > unknown symbol > `__stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziCategoryziUnicode_' > ghc: unable to load package `base-unicode-symbols-0.2.1.2' Oki, so I'm answering to myself: the base-unicode-symbols cabal file introduces a quirk concerning 'base' version which hides the symbols in Control.Category.Unicode. >> base-unicode-symbols.cabal -- line 42-46 if !flag(old-base) build-depends: base >= 3.0 && < 4.4 else build-depends: base >= 3.0.3.1 && < 4.4 exposed-modules: Control.Category.Unicode I should contact the maintainer about this … regards, /john ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ArrowLoop and streamprocessors
Hi all, I'm playing around a bit with arrows (more specifically, something like a CPS style streamprocessor as described in "Generalising Monads to Arrows" by John Hughes). A part of my program takes inputs/signals from 2 sources. The sources don't produce output at the same rate, and this part is able to handle inputs independently. So I figured I need Either A B ~> O for this part. handleA :: A ~> O handleB :: B ~> O someBox :: Either A B ~> O someBox = handleA ||| handleB So far so good. Now, further downstream (someBox >>> otherBox) there is. otherBox :: O ~> Either C B Let's say C are "normal" outputs, and B are control signals that need to get wired back to someBox. Control signals are rare, so maybe there's 1000 C outputs and only 1 B output in a certain timeframe. Also note that in this CPS style streamprocessing, there's no 1-on-1 relation between input and output, so on 1 input (O), otherBox might produce 2 outputs (2 times C), or 4 outputs (3 times C and 1 time B). To "wire back" B's to someBox, I'm pretty sure I need to use ArrowLoop. But (loop :: a (b, d) (c, d) -> a b c) uses tuples, which means the processing will only continue when both inputs are available. So if I turn someBox into (A, B) ~> O and otherBox into O ~> (C, B), the processing will instantly halt, waiting for a B to arrive after the A comes in. I know about the 'delay' trick that usually works for loops, where an output value is just inserted before the actual outputs, but that won't help in my case, because otherBox doesn't produce B's at the same rate that someBox receives A's, so by inserting a dummy B, someBox will only "run" once. Also, there's no relation between the number of A inputs someBox receives and the number of inputs for otherBox, so I also can't have otherBox just insert "noop" signals after every "run". So loop really doesn't seem to help here, but I couldn't find another way either to feed outputs back into the system. What I need is: Either A B ~> Either C B -> A ~> C Does such a thing exist? Thanks, Mathijs PS: I remember reading about (unfortunately didn't get the examples working) Reactive (FRP), which has the concept of Events and Behaviors I think Yampa has something like it too. A Behavior has a value at all times, which was updated by Events. That sounds a bit like it might solve my problem, since I need something that contains "Latest Control Signal was X" that updates when B's are produced, but that doesn't have to be put "on the wire" as a stream of events (because I can't determine how many events to put to match incoming A's. However, I hope there is another solution because I found Reactive and Yampa quite hard to grasp. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ghci] unknown symbol in base-unicode-symbols-0.2.1.2 ...
Hi everyone ! I'm having a problem in GHCi when loading modules relying on the base-unicode-symbols package. My prompt gives me the following message: >> ghci $ GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m +System.USB Prelude System.USB> newCtx Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. Loading package text-0.11.0.5 ... linking ... done. Loading package base-unicode-symbols-0.2.1.2 ... linking ... : /home/john/.cabal/lib/base-unicode-symbols-0.2.1.2/ghc-7.0.2/HSbase-unicode-symbols-0.2.1.2.o: unknown symbol `__stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziCategoryziUnicode_' ghc: unable to load package `base-unicode-symbols-0.2.1.2' Prelude System.USB> I thought this was due to me screwing around cabal/ghc-pkg caches but after a fresh install of Fedora15-alpha / cabal update / cabal install usb I'm still getting the same error. Moreover, a quick `nm HSbase-unicode-symbols-*.o | grep ControlziCategoryziUnicode` give me the following output. >> nm HSbase-unicode-symbols-0.2.1.2.o | grep -C 4 'ControlziCategoryziUnicode_' 0070 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziApplicativeziUnicode 0040 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziApplicativeziUnicode_ 0120 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziArrowziUnicode 00d8 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziArrowziUnicode_ U __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziCategoryziUnicode_ 01b8 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziMonadziUnicode 0188 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_ControlziMonadziUnicode_ 0250 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_DataziBoolziUnicode 0220 T __stginit_basezmunicodezmsymbolszm0zi2zi1zi2_DataziBoolziUnicode_ Could someone please explain to me what's happening ? regards, /John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 30 March 2011 18:07, Michael Snoyman wrote: > On Wed, Mar 30, 2011 at 9:26 AM, Jason Dagit wrote: >> >> >> On Tue, Mar 29, 2011 at 11:52 PM, Michael Snoyman >> wrote: >>> >>> Hi all, >>> >>> I think this is a well-known issue: it seems that there is no >>> character decoding performed on the values returned from the functions >>> in System.Directory (getDirectoryContents specifically). I could >>> manually do something like (utf8Decode . S8.pack), but that presumes >>> that the character encoding on the system in question is UTF8. So two >>> questions: >>> >>> * Is there a package out there that handles all the gory details for >>> me automatically, and simply returns a properly decoded String (or >>> Text)? >>> * If not, is there a standard way to determine the character encoding >>> used by the filesystem, short of hard-coding in character encodings >>> used by the major ones? >> >> I started to write a thoughtful reply, but I found that the answers here sum >> up everything I was going to say: >> http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux >> This same issue comes up from time to time for darcs and, if I recall >> correctly, the solution has been to treat unix file paths as arbitrary bytes >> whenever possible and to escape non-ascii compatible bytes when they occur. >> Otherwise it can be hard to encode them in textual patch descriptions or >> xml (where an encoding is required and I believe utf8 is a standard >> default). >> I wish you luck. It's not as easy problem, at least on unix. I've heard >> that windows has a much easier time here as MS has provided a standard for >> it. >> Jason > > Thanks to you (and everyone else) for the informative responses. For > now, I've simply hard-coded in UTF-8 encoding for all non-Windows > systems. I'm not sure how this will play with OSes besides Windows and > Linux (especially Mac), but it's a good stop-gap measure. > > I *do* think it would be incredibly useful to provide alternatives to > all the standard operations on FilePath which used opaque datatypes > and properly handles filename encoding. I noticed John Millikin's > system-filepath package[1]. Do people have experience with it? It > seems that adding a few functions like getDirectoryContents, plus > adding a version of toString which performs some character decoding, > would get us pretty far. > > Michael > > [1] http://hackage.haskell.org/package/system-filepath > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > It would also be great to have a package which combines the proper encoding/decoding of filepaths of the system-filepath package with the type-safety of the pathtype package: http://hackage.haskell.org/package/pathtype Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Computational Physics in Haskell
I started learning Haskell a little while ago. Although I am a novice I am still in love with it. I am physics major and primarily interested in Theoretical Physics and would like to use Haskell in this area. So, I just know to what has been done in this area, are there any libraries for simulating physical process in Haskell etc. Azeem Ul Hasan School of Science and Engineering, Lahore University of Management Sciences, Lahore, Pakistan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wed, Mar 30, 2011 at 9:26 AM, Jason Dagit wrote: > > > On Tue, Mar 29, 2011 at 11:52 PM, Michael Snoyman > wrote: >> >> Hi all, >> >> I think this is a well-known issue: it seems that there is no >> character decoding performed on the values returned from the functions >> in System.Directory (getDirectoryContents specifically). I could >> manually do something like (utf8Decode . S8.pack), but that presumes >> that the character encoding on the system in question is UTF8. So two >> questions: >> >> * Is there a package out there that handles all the gory details for >> me automatically, and simply returns a properly decoded String (or >> Text)? >> * If not, is there a standard way to determine the character encoding >> used by the filesystem, short of hard-coding in character encodings >> used by the major ones? > > I started to write a thoughtful reply, but I found that the answers here sum > up everything I was going to say: > http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux > This same issue comes up from time to time for darcs and, if I recall > correctly, the solution has been to treat unix file paths as arbitrary bytes > whenever possible and to escape non-ascii compatible bytes when they occur. > Otherwise it can be hard to encode them in textual patch descriptions or > xml (where an encoding is required and I believe utf8 is a standard > default). > I wish you luck. It's not as easy problem, at least on unix. I've heard > that windows has a much easier time here as MS has provided a standard for > it. > Jason Thanks to you (and everyone else) for the informative responses. For now, I've simply hard-coded in UTF-8 encoding for all non-Windows systems. I'm not sure how this will play with OSes besides Windows and Linux (especially Mac), but it's a good stop-gap measure. I *do* think it would be incredibly useful to provide alternatives to all the standard operations on FilePath which used opaque datatypes and properly handles filename encoding. I noticed John Millikin's system-filepath package[1]. Do people have experience with it? It seems that adding a few functions like getDirectoryContents, plus adding a version of toString which performs some character decoding, would get us pretty far. Michael [1] http://hackage.haskell.org/package/system-filepath ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to optmize this code?
If I'm not wrong : sum [1..n] = (n² + n)/2 2011/3/30 Daniel Fischer > On Wednesday 30 March 2011 16:39:49, Gilberto Garcia wrote: > > Hi Haskellers, > > > > I was solving this problem from project euler to study haskell. > > I came up whit the following solution and I was wondering if there is > > a more optimized and concise solution. > > Yes. There's a constant-time formula for summing the multiples of k <= a > (those are [k, 2*k .. (a `quot` k) * k], > so the sum is k* sum [1 .. (a `quot` k)], > try to find a formula for sum [1 .. n]), then you need the > http://en.wikipedia.org/wiki/Inclusion–exclusion_principle > > If you're looking for multiples of any of few numbers, it's very simple > then. For longer lists (say you want to sum the multiples of any of 30 > numbers), you have to be clever implementing the inclusion-exclusion > algorithm to keep the running time low, sometimes other methods may be > faster then (fkSum (10^7) [2 .. 30] for example). > > > > > fkSum :: Int -> [Int] -> Int > > fkSum a [] = 0 > > fkSum a (b) = foldl (+) 0 (filter (\x -> isMultiple x b) [1..a]) > > > > isMultiple :: Int -> [Int] -> Bool > > isMultiple a [] = False > > isMultiple a (x:xs) = if (mod a x == 0) then True else isMultiple a xs > > > > Thanks in advance > > ggarcia > > ___ > 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] CURL and upload a file
i had a very similar problem recently. thanks for posting the curl- based solution. if you are interested in a haskell-only version (at least without curl), check out https://github.com/marcmo/andSync/blob/master/test/Upload.hs the most of the code came from cabal since they have code to upload to hackage. but their solution didn't quite work for me since my webserver is kind a picky and always choked on some unexpected CRLF so i had to adapt is somehow. cheers, oliver On Mar 29, 12:42 am, Evgeny Dzhurinsky wrote: > I found the solution - the header "expect" is not processed by the > server well, so I have had to explicitly set it to empty value - and > then it worked! > > -- > regards > Eugene Dzhurinsky > > ___ > Haskell-Cafe mailing list > Haskell-C...@haskell.orghttp://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] how to optmize this code?
On Wednesday 30 March 2011 16:39:49, Gilberto Garcia wrote: > Hi Haskellers, > > I was solving this problem from project euler to study haskell. > I came up whit the following solution and I was wondering if there is > a more optimized and concise solution. Yes. There's a constant-time formula for summing the multiples of k <= a (those are [k, 2*k .. (a `quot` k) * k], so the sum is k* sum [1 .. (a `quot` k)], try to find a formula for sum [1 .. n]), then you need the http://en.wikipedia.org/wiki/Inclusion–exclusion_principle If you're looking for multiples of any of few numbers, it's very simple then. For longer lists (say you want to sum the multiples of any of 30 numbers), you have to be clever implementing the inclusion-exclusion algorithm to keep the running time low, sometimes other methods may be faster then (fkSum (10^7) [2 .. 30] for example). > > fkSum :: Int -> [Int] -> Int > fkSum a [] = 0 > fkSum a (b) = foldl (+) 0 (filter (\x -> isMultiple x b) [1..a]) > > isMultiple :: Int -> [Int] -> Bool > isMultiple a [] = False > isMultiple a (x:xs) = if (mod a x == 0) then True else isMultiple a xs > > Thanks in advance > ggarcia ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how to optmize this code?
Hi Haskellers, I was solving this problem from project euler to study haskell. I came up whit the following solution and I was wondering if there is a more optimized and concise solution. fkSum :: Int -> [Int] -> Int fkSum a [] = 0 fkSum a (b) = foldl (+) 0 (filter (\x -> isMultiple x b) [1..a]) isMultiple :: Int -> [Int] -> Bool isMultiple a [] = False isMultiple a (x:xs) = if (mod a x == 0) then True else isMultiple a xs Thanks in advance ggarcia ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Regarding two platforms build error.
Haskell Platform 2010.1 with ghc 6.12.1 worked quite well. Problem solved. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamically linked executables
I'm pretty sure it's not possible under OS X, and just as sure that it would be really nice, because some OS X libraries I'd like to link to (JACK OS X in particular), don't provide static libraries. On Mon, Mar 28, 2011 at 1:14 PM, Anakim Border wrote: > Hi, > > I'm trying to understand if it's possible to build dynamically linked > executables under Mac OS X (10.6) with GHC 7. > > Looking here: > > http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport > > it seems like the support is already present. > > Inside ghc-7.1.20110325 sources (the latest development snapshots as I > write), I find the following: > > # Do we support shared libs? > PlatformSupportsSharedLibs = $(if $(filter $(TARGETPLATFORM),\ > i386-unknown-linux x86_64-unknown-linux \ > i386-unknown-freebsd x86_64-unknown-freebsd \ > i386-unknown-openbsd x86_64-unknown-openbsd \ > i386-unknown-mingw32 \ > i386-unknown-solaris2 \ > i386-apple-darwin powerpc-apple-darwin),YES,NO) > > which seems to indicate the contrary. > > GHC bug tracker, finally, doesn't show any open ticket on the matter. > > Anyone has more details about this? > > > Thanks, > > AB > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Two Haskell Platforms on single machine.
I had to use two Haskell Platforms at once in the Windows environment. We use Haskell Platform 2011.1 as our main build platform. It provide real benefits for code with GADTs so we ported most of our code there. Right now we cannot switch back or it would be quite a regress. We also have some heavy type level computation code in one of our programs so we have to use Haskell Platform 2010.2 with ghc 6.12.3 as 7.0.2 is quite slow at that. And now I have some strange error (it didn't appear when I used only one of Haskell platforms): -- ghc-6.12.3 -O2 -odir objs -hidir objs -stubdir objs -o CGen.exe -fcontext-stack=100 --make CGen.hs Linking CGen.exe ... realgcc.exe: USERNA: Invalid argument C:\PROGRA~1\HASKEL~1\201020~1.0\lib\..\mingw\bin\windres: "C:\PROGRA~1\HASKEL~1\ 201020~1.0\lib\..\mingw\bin\gcc exited with status 1 -- When I looked at the dump in hex, I encountered that "USERNA" string contains "USERNAM^H" byte sequence, actually. I cannot look at ghc -v5 as I get another error: -- Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.10.4 Using binary package database: C:\PROGRA~1\HASKEL~1\201020~1.0\lib\package.conf.d\package.cache ... ... (I deleted much of the lines) ... Deleting: *** Deleting temp dirs: Deleting: : hPutChar: invalid argument (character is not in the code page) -- I use localized version of Windows XP so it appears that ghc cannot print some name with russian characters in it. And here I stuck. I cannot find source of one error because of another error. Could anyone help me? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
On Wed, Mar 30, 2011 at 6:52 AM, Tad Doxsee wrote: > Greg, > > Thanks for your help. Is there any significant difference between > using existential quantification > > data ShapeD = forall s. ShapeC => ShapeD s > > versus a GADT > > data ShapeD where > ShapeD :: ShapeC s => s -> ShapeD > > I'm not sure I understood what you meant by "You don't need to write > more typeclass instances this way." Sorry, I misspoke -- they're equivalent. Personally I find the existential easier to read. G -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 30 March 2011 10:20, Tako Schotanus wrote: >> http://www.haskell.org/pipermail/libraries/2009-August/012493.html >> I took from this discussion that FilePath really should be a pair of the >> actual filename ByteString, and the printable String (decoded from the >> ByteString, with encoding specified by the user's locale). The conversion >> from ByteString to String (and vice versa) is not guaranteed to be lossless, >> so you need to remember both. My understanding is that the ByteString is the one "source of truth" about what the file is called, and you can derive the String from that by assuming some encoding, which is what I proposed in my earlier message. I guess that as an optimisation you could cache the String decoded with a particular encoding as well, but to my mind it's not obviously worth it. > I'm not sure that I agree with that. Why does it have to be loss-less? > The problem, more likely, is the fact that FilePath is just a simple string. > Maybe we should go the way of Java where cross-platform file access is based > upon a File (or the new Path) type? An opaque Path type has been discussed before and would indeed help a lot, but it would break backwards compatibility in a fairly major way. It might be worth it, though. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
Hi,
Steffen Schuldenzucker wrote:
data Shape = Shape {
draw :: String
copyTo :: Double -> Double -> Shape
}
Tad Doxsee wrote:
Suppose that the shape class has 100 methods and that 1000 fully
evaluated shapes are placed in a list.
The above solution would store the full method table with each object.
Instead, we could share the method tables between objects. An object
would then uniformly contain two pointers: One pointer to the method
table, and one poiner to the internal state.
{-# LANGUAGE ExistentialQuantification, Rank2Types #-}
data Object methods = forall state . Object {
methods :: methods state,
state :: state
}
Calling a method requires dereferencing both pointers.
call :: (forall state . methods state -> state -> a) ->
(Object methods -> a)
call method (Object methods state) = method methods state
Using this machinery, we can encode the interface for shapes.
data ShapeClass state = ShapeClass {
draw :: state -> String,
copyTo :: state -> Double -> Double -> Shape
}
type Shape = Object ShapeClass
An implementation of the interface consists of three parts: A datatype
or the internal state, a method table, and a constructor.
data RectangleState = RectangleState {rx, ry, rw, rh :: Double}
rectangleClass :: ShapeClass RectangleState
rectangleClass = ShapeClass {
draw = \r ->
"Rect (" ++ show (rx r) ++ ", " ++ show (ry r) ++ ") -- "
++ show (rw r) ++ " x " ++ show (rh r),
copyTo = \r x y -> rectangle x y (rw r) (rh r)
}
rectangle :: Double -> Double -> Double -> Double -> Shape
rectangle x y w h
= Object rectangleClass (RectangleState x y w h)
The analogous code for circles.
data CircleState = CircleState {cx, cy, cr :: Double}
circleClass :: ShapeClass CircleState
circleClass = ShapeClass {
draw = \c ->
"Circ (" ++ show (cx c) ++ ", " ++ show (cy c)++ ") -- "
++ show (cr c),
copyTo = \c x y -> circle x y (cr c)
}
circle :: Double -> Double -> Double -> Shape
circle x y r
= Object circleClass (CircleState x y r)
Rectangles and circles can be stored together in usual Haskell lists,
because they are not statically distinguished at all.
-- test
r1 = rectangle 0 0 3 2
r2 = rectangle 1 1 4 5
c1 = circle 0 0 5
c2 = circle 2 0 7
shapes = [r1, r2, c1, c2]
main = mapM_ (putStrLn . call draw) shapes
While this does not nearly implement all of OO (no inheritance, no late
binding, ...), it might meet your requirements.
Tillmann
PS. You could probably use a type class instead of the algebraic data
type ShapeClass, but I don't see a benefit. Indeed, I like how the code
above is very explicit about what is stored where. For example, in the
code of the rectangle function, it is clearly visible that all shapes
created with that function will share a method table.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wed, Mar 30, 2011 at 11:01, Alistair Bayley wrote: > On 30 March 2011 20:53, Max Bolingbroke wrote: > >> On 30 March 2011 07:52, Michael Snoyman wrote: >> > I could >> > manually do something like (utf8Decode . S8.pack), but that presumes >> > that the character encoding on the system in question is UTF8. So two >> > questions: >> >> Funnily enough I have been thinking about this quite hard recently, >> and the situation is kind of a mess and short of implementing PEP383 >> (http://www.python.org/dev/peps/pep-0383/) in GHC I can't see how to >> make it easier on the programmer. As Jason points out the best you can >> really do is probably: >> >> 1. Treat Strings that represent filenames as raw byte sequences, even >> though they claim to be strings >> >> 2. When presenting such Strings to the user, re-decode them by using >> the current locale encoding (which will typically be UTF-8). You >> probably want to have some means of avoiding decoding errors here too >> -- ignoring or replacing undecodable bytes -- but presently this is >> not so straightforward. If you happen to be on a system with GNU Iconv >> you can use it's "C//TRANSLIT//IGNORE" encoding to achieve this, >> however. >> > > > http://www.haskell.org/pipermail/libraries/2009-August/012493.html > > I took from this discussion that FilePath really should be a pair of the > actual filename ByteString, and the printable String (decoded from the > ByteString, with encoding specified by the user's locale). The conversion > from ByteString to String (and vice versa) is not guaranteed to be lossless, > so you need to remember both. > > I'm not sure that I agree with that. Why does it have to be loss-less? The problem, more likely, is the fact that FilePath is just a simple string. Maybe we should go the way of Java where cross-platform file access is based upon a File (or the new Path) type? That way the internal representation could use whatever necessary to ensure a unique reference to a file or directory while at the same time providing a way to get a human-readable representation. Going from strings to file/path types would need the correct encodings to work. Cheers, -Tako PS: Just lurking here most of the time because I'm still a total Haskell noob, you can ignore me without risk. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] object oriented technique
On Wed, Mar 30, 2011 at 6:52 AM, Tad Doxsee wrote:
> Greg,
>
> Thanks for your help. Is there any significant difference between
> using existential quantification
>
> data ShapeD = forall s. ShapeC => ShapeD s
>
> versus a GADT
>
> data ShapeD where
> ShapeD :: ShapeC s => s -> ShapeD
The difference is purely syntactical. Use whichever you like better.
(There may be portability ramifications. I'm not sure if other
compilers implement ExistentialQuantification and/or GADTs.)
>
> I'm not sure I understood what you meant by "You don't need to write
> more typeclass instances this way."
>
> Thanks for pointing out the Control.Exception library. It was very
> helpful. Earlier, I was trying to figure out
> how to use Data.Dynamic for down-casting and couldn't get what I
> wanted. The Data.Typeable usage in Control.Exception is what I was
> looking for.
>
> Tad
>
>
> On Tue, Mar 29, 2011 at 12:57 AM, Gregory Collins
> wrote:
>> On Tue, Mar 29, 2011 at 7:49 AM, Tad Doxsee wrote:
>>> class ShapeC s where
>>> draw :: s -> String
>>> copyTo :: s -> Double -> Double -> s
>>>
>>> -- needs {-# LANGUAGE GADTs #-}
>>> data ShapeD where
>>> ShapeD :: ShapeC s => s -> ShapeD
>>>
>>> Is the above the standard method in Haskell for creating an extensible
>>> heterogeneous list of "objects" that share a common interface? Are there
>>> better
>>> approaches? (I ran into a possible limitation to this approach that I plan
>>> to ask about later if I can't figure it out myself.)
>>
>> The usual way to do this is:
>>
>> {-# LANGUAGE ExistentialQuantification #-}
>> data SomeShape = forall s . ShapeClass s => SomeShape s
>>
>> You don't need to write more typeclass instances this way. If you give
>> "SomeShape" a "ShapeClass" instance also, you can treat them
>> uniformly. The downside to these approaches is that any additional
>> information about the original concrete type is obliterated -- to get
>> OO-style downcasting you need "Typeable" support, and it isn't free.
>>
>> For an example of code which uses this idiom, see the exceptions
>> support from the base library:
>> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html
>>
>> G
>> --
>> Gregory Collins
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
--
Work is punishment for failing to procrastinate effectively.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 30 March 2011 20:53, Max Bolingbroke wrote: > On 30 March 2011 07:52, Michael Snoyman wrote: > > I could > > manually do something like (utf8Decode . S8.pack), but that presumes > > that the character encoding on the system in question is UTF8. So two > > questions: > > Funnily enough I have been thinking about this quite hard recently, > and the situation is kind of a mess and short of implementing PEP383 > (http://www.python.org/dev/peps/pep-0383/) in GHC I can't see how to > make it easier on the programmer. As Jason points out the best you can > really do is probably: > > 1. Treat Strings that represent filenames as raw byte sequences, even > though they claim to be strings > > 2. When presenting such Strings to the user, re-decode them by using > the current locale encoding (which will typically be UTF-8). You > probably want to have some means of avoiding decoding errors here too > -- ignoring or replacing undecodable bytes -- but presently this is > not so straightforward. If you happen to be on a system with GNU Iconv > you can use it's "C//TRANSLIT//IGNORE" encoding to achieve this, > however. > http://www.haskell.org/pipermail/libraries/2009-August/012493.html I took from this discussion that FilePath really should be a pair of the actual filename ByteString, and the printable String (decoded from the ByteString, with encoding specified by the user's locale). The conversion from ByteString to String (and vice versa) is not guaranteed to be lossless, so you need to remember both. Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On 30 March 2011 07:52, Michael Snoyman wrote: > I could > manually do something like (utf8Decode . S8.pack), but that presumes > that the character encoding on the system in question is UTF8. So two > questions: Funnily enough I have been thinking about this quite hard recently, and the situation is kind of a mess and short of implementing PEP383 (http://www.python.org/dev/peps/pep-0383/) in GHC I can't see how to make it easier on the programmer. As Jason points out the best you can really do is probably: 1. Treat Strings that represent filenames as raw byte sequences, even though they claim to be strings 2. When presenting such Strings to the user, re-decode them by using the current locale encoding (which will typically be UTF-8). You probably want to have some means of avoiding decoding errors here too -- ignoring or replacing undecodable bytes -- but presently this is not so straightforward. If you happen to be on a system with GNU Iconv you can use it's "C//TRANSLIT//IGNORE" encoding to achieve this, however. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Wed, Mar 30, 2011 at 09:26, Jason Dagit wrote: > > > On Tue, Mar 29, 2011 at 11:52 PM, Michael Snoyman wrote: > >> Hi all, >> >> I think this is a well-known issue: it seems that there is no >> character decoding performed on the values returned from the functions >> in System.Directory (getDirectoryContents specifically). I could >> manually do something like (utf8Decode . S8.pack), but that presumes >> that the character encoding on the system in question is UTF8. So two >> questions: >> >> * Is there a package out there that handles all the gory details for >> me automatically, and simply returns a properly decoded String (or >> Text)? >> * If not, is there a standard way to determine the character encoding >> used by the filesystem, short of hard-coding in character encodings >> used by the major ones? >> > > I started to write a thoughtful reply, but I found that the answers here > sum up everything I was going to say: > > http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux > > This same issue comes up from time to time for darcs and, if I recall > correctly, the solution has been to treat unix file paths as arbitrary bytes > whenever possible and to escape non-ascii compatible bytes when they occur. > Otherwise it can be hard to encode them in textual patch descriptions or > xml (where an encoding is required and I believe utf8 is a standard > default). > > I wish you luck. It's not as easy problem, at least on unix. I've heard > that windows has a much easier time here as MS has provided a standard for > it. > All the more reason it seems to make this available in the standard package, so people don't have to figure out how to the conversions each time (for all the different OSes with whcih they might not have any experience etc) . All modern Linuxes use UTF8 by default anyway so in the beginning one could assume UTF8 and later change the system to be able to make more intelligent decisions (like checking environment variables for per-user settings). A way to override the assumptions made would be necessary too I guess. -Tako ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding-aware System.Directory functions
On Tue, Mar 29, 2011 at 11:52 PM, Michael Snoyman wrote: > Hi all, > > I think this is a well-known issue: it seems that there is no > character decoding performed on the values returned from the functions > in System.Directory (getDirectoryContents specifically). I could > manually do something like (utf8Decode . S8.pack), but that presumes > that the character encoding on the system in question is UTF8. So two > questions: > > * Is there a package out there that handles all the gory details for > me automatically, and simply returns a properly decoded String (or > Text)? > * If not, is there a standard way to determine the character encoding > used by the filesystem, short of hard-coding in character encodings > used by the major ones? > I started to write a thoughtful reply, but I found that the answers here sum up everything I was going to say: http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux This same issue comes up from time to time for darcs and, if I recall correctly, the solution has been to treat unix file paths as arbitrary bytes whenever possible and to escape non-ascii compatible bytes when they occur. Otherwise it can be hard to encode them in textual patch descriptions or xml (where an encoding is required and I believe utf8 is a standard default). I wish you luck. It's not as easy problem, at least on unix. I've heard that windows has a much easier time here as MS has provided a standard for it. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
