Re: [Haskell-cafe] Re: Phantoms
On Sat, Aug 16, 2008 at 1:12 PM, Ben Franksen [EMAIL PROTECTED] wrote: Jason Dagit wrote: On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin [EMAIL PROTECTED]wrote: I just (re)discovered that I can do things like data Foo x = Foo Int Int Now Foo Int and Foo Double are, as far as the type checker cares, two completely different types, even though in fact they are the same. This is actually Quite Useful, in the particular case I'm working on. Phantom types are indeed useful for many things, but a bit of cautionary advice. If you start to depend on the phantoms for type safety AND you export your data constructors then you run a serious risk of being type unsafe. Bonus points if you can demonstrate an equivalent of unsafeCoerce# this way. This would be very bad, but I doubt it is possible. Example: fooCast :: Foo Int - Foo Double fooCast (Foo x) = Foo x On noes! We just cast that Foo Int to a Foo Double without changing it! What's the problem? It's not so bad if you keep in mind that it's possible. Sometimes it's exactly what you want. It works because the value on the RHS is consider freshly constructed and other than sharing x it is unrelated to the one on the LHS. Right. You must call the data constructor Foo in order to exploit that it has the type Foo :: Int - Foo a I don't see how this is not type safe, and I was not able to produce an #unsafeCoerce with this technique. One would need some unFoo a - a but the a in data Foo a is phantom, i.e. there is no thing of type a in a Foo. Ah, it seems that the example I remembered cooking up requires GADTs, lexically scoped type variables and one unsafeCoerce#, so I guess it can be dismissed on the grounds that it uses unsafeCoerce# internally. I only need that because to make my thing work I need the following: data EqCheck a b where IsEq :: EqCheck a a NotEq :: EqCheck a b (=\/=) :: C a b - C a c - EqCheck b c Without unsafeCoerce# I don't see how to implement (=\/=). But, if you had that you could do the following: (=\/=) :: C a b - C a c - EqCheck b c a =\/= b | unC a == unC b = unsafeCoerce# IsEq | otherwise = NotEq data C x y = C String unsafeC :: String - C x y unsafeC a = C a unC :: C x y - String unC (C x) = x myCoerce :: forall a b. a - b myCoerce x = fromJust $ do let ab = unsafeC :: C a b let aa = unsafeC :: C a a IsEq - return $ aa =\/= ab return x Actually, it turns out that this also requires ghc 6.6. I just tried this out in both 6.6 and 6.8 and it turns out that in 6.8 the type checker was upgraded, in particular the way type checking works for GADTs was refined and the above program is rejected. I'm glad to see that myCoerce is not possible without using an unsafeCoerce# yourself. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] build depends: in a .cabal file
Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the build depends is incomplete in that it should contain old time and TextPrettyPrint.HughesPJ?? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: build depends: in a .cabal file
cabal should access to currently installed packages from the package db. Just thinking out loud ... a digraph of dependencies would have to be built from build depends to drive possible faulting in On Mon, Aug 18, 2008 at 3:37 AM, Galchin, Vasili [EMAIL PROTECTED]wrote: Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the build depends is incomplete in that it should contain old time and TextPrettyPrint.HughesPJ?? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Serial COM port access on Windows
Dear all, Is there any more or less specific library for access to serial COM port from Haskell on Windows? Or am I expected to use a file mapping? Could you point me to some texts/examples? I tried some google (GHC specific) with no expected result. The issue is the following - I have a device communicating via Bluetooth with my PC, PC can create a serial COM port over the Bluetooth connection... I used C and a specific library for C so far, but I'd rather not encapsulate it by some Foreign calls in Haskell. Thanks for hints, Dusan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FRP question
I think FRP is well-suited to this problem; it lets you abstract out
the imperative network code from the reactive core of the code. The
network code can live in a separate thread that uses select() and
listen(), and updates event streams.
I was thinking about writing a MUD using FRP; in my mind, the
framework looked something like this:
-- A connection is
-- 1) An event that fires once when the connection is closed
-- 2) An event that fires each time a line is received over the connection
-- 3) A routine that outputs a line to that connection
-- 4) A routine that closes the conection
data Connection = Conn
{ connClosed :: Event ()
, connLines :: Event String
, connWrite :: String - IO ()
, connDisconnect :: IO ()
}
-- Listen on a given port for connections and return them as an FRP
event stream.
-- Since Connection contains an event stream, this is going
-- to be a nested event; we will use join/= on Event at some point to get the
-- commands from each connection
listen :: Int - IO (Event Connection)
-- the server is an FRP program that outputs an event stream of IO actions;
-- the actions will generally just be write a message to a particular socket
server :: Event Connection - Event (IO ())
-- Now main is trivial to implement, given sinkE from Conal's FRP paper
-- http://conal.net/papers/simply-reactive/
-- sinkE :: (a - IO ()) - Event a - IO ()
main = listen 4200 = sinkE id . server
-- An example server that writes hello world to each client and
disconnects them
server conns = do
connection - conns
return $ do
connWrite connection Hello World.
connDisconnect connection
-- ryan
On Sun, Aug 17, 2008 at 2:26 PM, Tim Newsham [EMAIL PROTECTED] wrote:
I'm interested in FRP, have read several of the papers and am wondering
if it could be applied to writing multi-client server programs.
What would be the input type events for such a system? What would
be the output type events? How would the system handle the fact
that it has to multiplex several IO streams (sockets)?
I'm trying to answer these questions myself and having a hard time.
Should input events include new connection requests and shutdowns?
Individual bytes? Streams of bytes? or higher level PDUs?
What kind of output should be generated? Full PDUs? streams of
bytes? Pairs of (connection identifier,data)?
How would such a system effectively hide the multiplexed IO going on?
Is this sort of problem poorly suited for FRP?
Tim Newsham
http://www.thenewsh.com/~newsham/
___
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] build depends: in a .cabal file
On Mon, 18 Aug 2008, Galchin, Vasili wrote: Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? At least when compiling with GHC, Cabal exposes only packages which are mentioned under Build-Depends. That is, if a package is missing in Build-Depends, the project cannot be compiled. It is however possible to forget modules in the Exposed-Modules and Other-Modules section and GHC finds them anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] missingH 0.18.6 - problems with cabal configure
when i run cabal i get an error message: :~/haskellSources/packages/MissingH-0.18.6$ runhaskell Setup configure Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip = case os of mingw32 - ... _ - ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags = let mydescrip = ... in (confHook defaultUserHooks) mydescrip flags what is wrong? i use ghc 6.8.2 and cabal 1.2.3.0 thanks for help! andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
On Mon, 2008-08-18 at 03:37 -0500, Galchin, Vasili wrote: Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? I'm not quite sure what you mean. They are certainly not just informational. If you miss dependencies then the package will not compile. If by faulting in you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. As you mention in your other email, Cabal and cabal-install do indeed access the db of installed packages and build a dependency graph. cabal-install also uses a simple constraint solver to find a satisfactory dep graph of installable packages. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
All,
I have a growing amount of astrodynamics code that relies on various
physical constants. The problem with these so called constants are
that they either aren't really constants or aren't well known. An
example is the leap second table (see Data.Time.Clock.TAI). I'd like
to be able to fetch current values of these constants at runtime and
make them accessible to my astrodynamics functions by some means. To
clarify, once initialized the constants will be considered constant
for the remainder of the program.
I'd store the constants in a data structure along the lines of:
data AstroData a = AstroData
{ mu_Earth:: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
I would like to know if there is any consensus on what is the best way
to make such a data structure accessible in pure functions. Passing it
explicitly would be a mess. It seems that two options are to use
either a Reader monad or implicit parameters. Using a Reader monad is
straight forward enough though it requires writing/converting code
in/to monadic style and adds some clutter to the formulae. It seems
implicit parameters could be cleaner but I've seen them referred to as
everything from evil to just what you need and rendering the Reader
monad obsolete...
What do you people recommend?
Thanks,
Bjorn Buckwalter
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
All,
I have a growing amount of astrodynamics code that relies on various
physical constants. The problem with these so called constants are
that they either aren't really constants or aren't well known. An
example is the leap second table (see Data.Time.Clock.TAI). I'd like
to be able to fetch current values of these constants at runtime and
make them accessible to my astrodynamics functions by some means. To
clarify, once initialized the constants will be considered constant
for the remainder of the program.
I'd store the constants in a data structure along the lines of:
data AstroData a = AstroData
{ mu_Earth:: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
I would like to know if there is any consensus on what is the best way
to make such a data structure accessible in pure functions. Passing it
explicitly would be a mess. It seems that two options are to use
either a Reader monad or implicit parameters. Using a Reader monad is
straight forward enough though it requires writing/converting code
in/to monadic style and adds some clutter to the formulae. It seems
implicit parameters could be cleaner but I've seen them referred to as
everything from evil to just what you need and rendering the Reader
monad obsolete...
What do you people recommend?
Thanks,
Bjorn Buckwalter
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On Mon, 18 Aug 2008, Bjorn Buckwalter wrote: I would like to know if there is any consensus on what is the best way to make such a data structure accessible in pure functions. Passing it explicitly would be a mess. It seems that two options are to use either a Reader monad or implicit parameters. Using a Reader monad is straight forward enough though it requires writing/converting code in/to monadic style and adds some clutter to the formulae. It seems implicit parameters could be cleaner but I've seen them referred to as everything from evil to just what you need and rendering the Reader monad obsolete... I expect that you will get the same range of opinions as you got from your search. As far as I know implicit parameters break referential transparency. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters So I prefer Reader monad. The burden of converting to monadic style pays off when you need to use the same code with different values for the constants. (E.g. find out for which value of the Planck constant the universe collapses and for which it oscillates etc. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On 2008 Aug 18, at 11:16, Henning Thielemann wrote: know implicit parameters break referential transparency. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters Are you making the same mistake I did? Linear implicit parameters are different from implicit parameters. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On Mon, 18 Aug 2008, Brandon S. Allbery KF8NH wrote: On 2008 Aug 18, at 11:16, Henning Thielemann wrote: know implicit parameters break referential transparency. http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters Are you making the same mistake I did? Linear implicit parameters are different from implicit parameters. I haven't look into the details, so I certainly make any possible mistake. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:
On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:
I would like to know if there is any consensus on what is the best way
to make such a data structure accessible in pure functions. Passing it
explicitly would be a mess. It seems that two options are to use
either a Reader monad or implicit parameters. Using a Reader monad is
straight forward enough though it requires writing/converting code
in/to monadic style and adds some clutter to the formulae. It seems
implicit parameters could be cleaner but I've seen them referred to as
everything from evil to just what you need and rendering the Reader
monad obsolete...
I expect that you will get the same range of opinions as you got from your
search. As far as I know implicit parameters break referential transparency.
http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters
So I prefer Reader monad. The burden of converting to monadic style pays
off when you need to use the same code with different values for the
constants. (E.g. find out for which value of the Planck constant the
universe collapses and for which it oscillates etc. :-)
Love the example but could you elaborate a little on how monadic style
helps with this? (This is probably a matter of it not being obvious to
me what approach you would take to solving the problem.)
Instead of
muEarth :: GravitationalParameter a
muEarth = ???
escapeVelocity :: a
escapeVelocity = ... muEarth ...
you would write
data AstroData a = AstroData
{ muEarth :: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
escapeVelocity :: Reader (AstroData a) a
escapeVelocity =
do mu - asks muEarth
return (... mu ...)
Even better you would introduce a newtype for Reader (AstroData a). This
way you can add any monadic functionality later (Writer et.al.).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:
On Mon, Aug 18, 2008 at 11:16 AM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008, Bjorn Buckwalter wrote:
I would like to know if there is any consensus on what is the best way
to make such a data structure accessible in pure functions. Passing it
explicitly would be a mess. It seems that two options are to use
either a Reader monad or implicit parameters. Using a Reader monad is
straight forward enough though it requires writing/converting code
in/to monadic style and adds some clutter to the formulae. It seems
implicit parameters could be cleaner but I've seen them referred to as
everything from evil to just what you need and rendering the Reader
monad obsolete...
I expect that you will get the same range of opinions as you got from
your
search. As far as I know implicit parameters break referential
transparency.
http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters
So I prefer Reader monad. The burden of converting to monadic style pays
off when you need to use the same code with different values for the
constants. (E.g. find out for which value of the Planck constant the
universe collapses and for which it oscillates etc. :-)
Love the example but could you elaborate a little on how monadic style
helps with this? (This is probably a matter of it not being obvious to
me what approach you would take to solving the problem.)
Instead of
muEarth :: GravitationalParameter a
muEarth = ???
escapeVelocity :: a
escapeVelocity = ... muEarth ...
you would write
data AstroData a = AstroData
{ muEarth :: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
escapeVelocity :: Reader (AstroData a) a
escapeVelocity =
do mu - asks muEarth
return (... mu ...)
Even better you would introduce a newtype for Reader (AstroData a). This way
you can add any monadic functionality later (Writer et.al.).
Right, and I'd evaluate it using e.g.:
runReader escapeVelocity myAstroData
But with implicit params I suppose I'd define (untested) e.g.:
escapeVelocity :: (?astro :: AstroData a) = a
escapeVelocity = ... mu ... where mu = muEarth ?astro
To evaluate this I'd use:
let ?astro = myAstroData in escapeVelocity
Which is comparable to the Reader version (with the
advantage/disadvantage of the body of 'escapeVelocity' not being
monadic).
In retrospect I think I misunderstood what you were saying in you
first email. I thought you were arguing that the monadic style would
have an advantage over implicit params in the Planck problem. But you
probably only meant to reemphasize the advantage (of either solution)
over hard-coding constants...
Thanks again, your Reader example is virtually identical to what I
started off with so at least I know I'm not completely off target for
a monadic implementation.
(Sorry about the reposts Henning, I keep forgetting to cc the café!)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
Bjorn Buckwalter schrieb:
On Mon, Aug 18, 2008 at 2:02 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
Instead of
muEarth :: GravitationalParameter a
muEarth = ???
escapeVelocity :: a
escapeVelocity = ... muEarth ...
you would write
data AstroData a = AstroData
{ muEarth :: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
escapeVelocity :: Reader (AstroData a) a
escapeVelocity =
do mu - asks muEarth
return (... mu ...)
Even better you would introduce a newtype for Reader (AstroData a). This way
you can add any monadic functionality later (Writer et.al.).
Right, and I'd evaluate it using e.g.:
runReader escapeVelocity myAstroData
But with implicit params I suppose I'd define (untested) e.g.:
escapeVelocity :: (?astro :: AstroData a) = a
escapeVelocity = ... mu ... where mu = muEarth ?astro
To evaluate this I'd use:
let ?astro = myAstroData in escapeVelocity
Which is comparable to the Reader version (with the
advantage/disadvantage of the body of 'escapeVelocity' not being
monadic).
In my opinion the implicit parameters don't make things simpler, only
less portable, that's why I prefer the Reader monad.
In retrospect I think I misunderstood what you were saying in you
first email. I thought you were arguing that the monadic style would
have an advantage over implicit params in the Planck problem. But you
probably only meant to reemphasize the advantage (of either solution)
over hard-coding constants...
indeed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] X Haskell Bindings
On 8/16/08, Antoine Latter [EMAIL PROTECTED] wrote: The following is a summary of my plan so far. I'm interested in hearing any suggestions or concerns about what a Haskell library for writing X clients should look like. This is not a release announcement, and I can't make any promises about when this will be delivered. Code is available in darcs: -- darcs get http://community.haskell.org/~aslatter/code/xhb Some of the advantages XCB claims over xlib are: + smaller API + latency hiding when communicating with the X server + direct access to the X protocol + improved threading support + easier to extend What I plan for the X Haskell Bindings (XHB) are as follows: It seems to me that you could make this a bit more haskelly... + All requests to the server are non-blocking (under most circumstances) + Requests which produce a reply from the server return a token or receipt Why not abstract this token or receipt into a function? i.e. why not change... -- | List all of the extensions supported by the server listExtensions :: Connection - IO (Receipt (ListExtensionsReply)) -- | Query a receipt for a response getReply :: Receipt a - IO (Either XError a) to listExtensions :: Connection - IO (IO ListExtensionsReply) and then you don't need to use a getReply, or a Receipt data type. This should be equally general, if (as I imagine) the only thing you can do with a Receipt is to getReply it. And to me it seems like a friendly way of describing what this function does. Each X extension defines its own set of errors and events (potentially). Should all of these be lumped together into one giant sum-type for errors and one for events? Or maybe just a couple of existential types together with dynamic? (i.e. like xmonad's SomeMessage) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic). In my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad. They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html So it would probably be a mistake to write new code using them. As an aside, if that's really the complete patch I'm impressed how few lines were involved. 136 lines out of TcSimplify.lhs and misc tiny changes in other files. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On 2008 Aug 18, at 16:20, Evan Laforge wrote: Which is comparable to the Reader version (with the advantage/disadvantage of the body of 'escapeVelocity' not being monadic). In my opinion the implicit parameters don't make things simpler, only less portable, that's why I prefer the Reader monad. They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html Again, that's *linear* implicit parameters (%foo instead of ?foo). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Kieran Beltran/Watson/IBM is out of the office.
I will be out of the office starting 08/18/2008 and will not return until 08/25/2008. I will be on vacation for a few days. If this is urgent please reach my Admin Kristine Smester ((917) 472-3387), otherwise I will respond to your message when I return. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html Again, that's *linear* implicit parameters (%foo instead of ?foo). Oh, you're right. I made exactly the same mistake you made, and right after you warned against making it too. I always thought linear was the ? stuff, but now I see it's not. Maybe it's best that it's gone so we only have one flavor of implicit parameters feature from here on out. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
. If by faulting in you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. This is exactly by faulting in .. an analogy ... Installing cabal-install seems to be a chicken and egg problem if enough packages are not already installed ... if not enough then one (me) can die of a thousand paper cuts bootstrapping packages up to where cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is written in Haskell? If so, is there a pre-compiled Cabal-install that I can just install with all dependencies (packages) including. I also want to install HaskellDB painlessly ;^) ?? As you mention in your other email, Cabal and cabal-install do indeed access the db of installed packages and build a dependency graph. cabal-install also uses a simple constraint solver to find a satisfactory dep graph of installable packages. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
2008/8/18 Galchin, Vasili [EMAIL PROTECTED]: . If by faulting in you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. This is exactly by faulting in .. an analogy ... Installing cabal-install seems to be a chicken and egg problem if enough packages are not already installed ... if not enough then one (me) can die of a thousand paper cuts bootstrapping packages up to where cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is written in Haskell? If so, is there a pre-compiled Cabal-install that I can just install with all dependencies (packages) including. I also want to install HaskellDB painlessly ;^) ?? In my experience, with recent GHC there are only 3 packages needed to install cabal-install and it's pretty painless. You need zlib, HTTP and something else that I can't recall off the top of my head (but it tells you). Each of these packages can be had from hackage and they are very standard cabal installations. Sometimes you also need to upgrade cabal; I don't think this was an issue with ghc 6.8.2 and newer though. Cabal-install is worth the pain. Once you have a recent cabal-install it becomes painless to try out new packages via Hackage. And we have some very cool packages there these days. I really need to get all my side projects there so people can play with them. /advocating Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
On 2008 Aug 18, at 17:09, Evan Laforge wrote: They also seem to be removed from ghc: http://www.haskell.org/pipermail/cvs-ghc/2006-September/031824.html Again, that's *linear* implicit parameters (%foo instead of ?foo). Oh, you're right. I made exactly the same mistake you made, and right after you warned against making it too. I always thought linear was the ? stuff, but now I see it's not. Maybe it's best that it's gone so we only have one flavor of implicit parameters feature from here on out. Don't feel too bad; the main reason I'm commenting on it is I managed to confuse a bunch of people in public before I was set straight on it, so I kinda feel a bit guilty when people are confused by it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
On Mon, 2008-08-18 at 14:30 -0700, Jason Dagit wrote: 2008/8/18 Galchin, Vasili [EMAIL PROTECTED]: . If by faulting in you mean downloading and installing missing dependencies, then that's exactly what the cabal-install tool does. This is exactly by faulting in .. an analogy ... Installing cabal-install seems to be a chicken and egg problem if enough packages are not already installed ... if not enough then one (me) can die of a thousand paper cuts bootstrapping packages up to where cabal-install can be installed. I am running Ubuntu Linux. Cabl-install is written in Haskell? If so, is there a pre-compiled Cabal-install that I can just install with all dependencies (packages) including. I also want to install HaskellDB painlessly ;^) ?? In my experience, with recent GHC there are only 3 packages needed to install cabal-install and it's pretty painless. You need zlib, HTTP and something else that I can't recall off the top of my head (but it tells you). Each of these packages can be had from hackage and they are very standard cabal installations. Sometimes you also need to upgrade cabal; I don't think this was an issue with ghc 6.8.2 and newer though. Cabal-install is worth the pain. Once you have a recent cabal-install it becomes painless to try out new packages via Hackage. And we have some very cool packages there these days. I really need to get all my side projects there so people can play with them. /advocating Don't forget that once you get cabal-install going the first time you can upgrade via cabal install cabal-install. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
On 2008 Aug 18, at 17:30, Jason Dagit wrote: In my experience, with recent GHC there are only 3 packages needed to install cabal-install and it's pretty painless. You need zlib, HTTP and something else that I can't recall off the top of my head (but it tells you). Each of these packages can be had from hackage and they are very standard cabal installations. Sometimes you also need to upgrade cabal; I don't think this was an issue with ghc 6.8.2 and newer though. When I installed cabal-install under 6.8.2 I also had to get a Cabal 1.4 prerelease from darcs, IIRC. cabal-install would be helped a lot by either (a) being folded into Cabal, and in particular the Cabal that comes with GHC; or, failing that, (b) being available as a prebuilt bootstrap package. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: wavconvert 0.1.1
Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert I had a directory tree full of .wav files that I ripped from CDs at times when I didn't want to wait for an .mp3 or .ogg encoder to run. The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names. So, wavconvert takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. The name is a bit misleading, since this is not an OGG encoder written in Haskell; it just handles invoking an existing encoder with the right flags to set the metadata. I'd welcome any patches to make this more generally useful (as it is, it assumes a particular file structure and OGG encoder.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Research is what I'm doing when I don't know what I'm doing.--Wernher von Braun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build depends: in a .cabal file
On Mon, 2008-08-18 at 17:41 -0400, Brandon S. Allbery KF8NH wrote: On 2008 Aug 18, at 17:30, Jason Dagit wrote: In my experience, with recent GHC there are only 3 packages needed to install cabal-install and it's pretty painless. You need zlib, HTTP and something else that I can't recall off the top of my head (but it tells you). Each of these packages can be had from hackage and they are very standard cabal installations. Sometimes you also need to upgrade cabal; I don't think this was an issue with ghc 6.8.2 and newer though. When I installed cabal-install under 6.8.2 I also had to get a Cabal 1.4 prerelease from darcs, IIRC. Which is now released on hackage. It's all on hackage. cabal-install would be helped a lot by either (a) being folded into Cabal, and in particular the Cabal that comes with GHC; or, failing that, (b) being available as a prebuilt bootstrap package. We cannot fold it into the Cabal lib package but it will come with the first Haskell Platform release. Now that the development version can re-install itself on Windows (you've no idea how painful windows makes this) I might make a pre-built .exe version available. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: wavconvert 0.1.1
catamorphism: Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert Tim wins the prize for the 500th Haskell package in Arch Linux, http://aur.archlinux.org/packages.php?ID=19205 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: wavconvert 0.1.1
On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote: Tim wins the prize for the 500th Haskell package in Arch Linux, http://aur.archlinux.org/packages.php?ID=19205 Which, I should like to note, demonstrates why the original Cabal design[1] was basically right[2] in that it allows this kind of automated translation into native packages. You cannot do that with autoconf. The other distros are following a similar course though not yet quite as successfully as Don has demonstrated for Arch. There are similar translation tools for Gentoo, Debian and RPM-based distros with varying levels of sophistication and automation. I think the folks who hack on these translation tools should get together and share code and experience so we can all achieve better levels of automation. The highest levels of automation will also require more centralised QA on hackage. That's where we should be going. Duncan [1] http://haskell.org/cabal/proposal/index.html [2] I'm not at all claiming credit for that design. That was decided well before I started hacking on Cabal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how can I receive the mail?
if you can demonstrate an equivalent of unsafeCoerce# this way. This would be very bad, but I doubt it is possible. Example: fooCast :: Foo Int - Foo Double fooCast (Foo x) = Foo x On noes! We just cast that Foo Int to a Foo Double without changing it! What's the problem? It's not so bad if you keep in mind that it's possible. Sometimes it's exactly what you want. It works because the value on the RHS is consider freshly constructed and other than sharing x it is unrelated to the one on the LHS. Right. You must call the data constructor Foo in order to exploit that it has the type Foo :: Int - Foo a I don't see how this is not type safe, and I was not able to produce an #unsafeCoerce with this technique. One would need some unFoo a - a but the a in data Foo a is phantom, i.e. there is no thing of type a in a Foo. Ah, it seems that the example I remembered cooking up requires GADTs, lexically scoped type variables and one unsafeCoerce#, so I guess it can be dismissed on the grounds that it uses unsafeCoerce# internally. I only need that because to make my thing work I need the following: data EqCheck a b where IsEq :: EqCheck a a NotEq :: EqCheck a b (=\/=) :: C a b - C a c - EqCheck b c Without unsafeCoerce# I don't see how to implement (=\/=). But, if you had that you could do the following: (=\/=) :: C a b - C a c - EqCheck b c a =\/= b | unC a == unC b = unsafeCoerce# IsEq | otherwise = NotEq data C x y = C String unsafeC :: String - C x y unsafeC a = C a unC :: C x y - String unC (C x) = x myCoerce :: forall a b. a - b myCoerce x = fromJust $ do let ab = unsafeC :: C a b let aa = unsafeC :: C a a IsEq - return $ aa =\/= ab return x Actually, it turns out that this also requires ghc 6.6. I just tried this out in both 6.6 and 6.8 and it turns out that in 6.8 the type checker was upgraded, in particular the way type checking works for GADTs was refined and the above program is rejected. I'm glad to see that myCoerce is not possible without using an unsafeCoerce# yourself. Thanks, Jason -- Message: 9 Date: Mon, 18 Aug 2008 03:37:25 -0500 From: Galchin, Vasili [EMAIL PROTECTED] Subject: [Haskell-cafe] build depends: in a .cabal file To: haskell-cafe@haskell.org haskell-cafe@haskell.org Cc: Galchin Vasili [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the build depends is incomplete in that it should contain old time and TextPrettyPrint.HughesPJ?? -- next part -- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/245a4304/ attachment-0001.htm -- Message: 10 Date: Mon, 18 Aug 2008 03:42:59 -0500 From: Galchin, Vasili [EMAIL PROTECTED] Subject: [Haskell-cafe] Re: build depends: in a .cabal file To: haskell-cafe@haskell.org haskell-cafe@haskell.org Cc: Galchin Vasili [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 cabal should access to currently installed packages from the package db. Just thinking out loud ... a digraph of dependencies would have to be built from build depends to drive possible faulting in On Mon, Aug 18, 2008 at 3:37 AM, Galchin, Vasili [EMAIL PROTECTED]wrote: Hello, It seems to me that the build depends attribute/field is only informational, i.e. it doesn't cause faulting in dependencies if not present? If true, this seems to be a deficiency in cabal. ?? Kind regards, Vasili PS It seems to me that for HaskellDB the build depends is incomplete in that it should contain old time and TextPrettyPrint.HughesPJ?? -- next part -- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080818/52f404df/ attachment-0001.htm -- Message: 11 Date: Mon, 18 Aug 2008 10:51:01 +0200 From: Kol?? Du?an[EMAIL PROTECTED] Subject: [Haskell-cafe] Serial COM port access on Windows To: Haskell Cafe haskell-cafe@haskell.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-2; DelSp=Yes; format=flowed Dear all, Is there any more or less specific library for access to serial COM port from Haskell on Windows? Or am I expected to use a file mapping? Could you point me to some texts/examples? I tried some google (GHC specific) with no expected result. The issue is the following - I have a device communicating via Bluetooth with my PC, PC can create a serial COM port over the Bluetooth connection... I used C and a specific library for C so
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
G'day all.
Quoting Bjorn Buckwalter [EMAIL PROTECTED]:
I'd store the constants in a data structure along the lines of:
data AstroData a = AstroData
{ mu_Earth:: GravitationalParameter a
, leapSeconds :: LeapSecondTable
}
I would like to know if there is any consensus on what is the best way
to make such a data structure accessible in pure functions. Passing it
explicitly would be a mess.
In this situation, there isn't necessarily any shame in using a
top-level unsafePerformIO as long as it's well-hidden:
module AstroData (AstroData(..), globalAstroData) where
data AstroData = AstroData Int
-- You really don't want this function inlined. You also
-- really don't want this function to be polymorphic.
{-# NOINLINE globalAstroData #-}
globalAstroData :: AstroData
globalAstroData = unsafePerformIO $ do
d - return 42-- Or whatever
return (AstroData d)
Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: wavconvert 0.1.1
duncan.coutts: On Mon, 2008-08-18 at 18:22 -0700, Don Stewart wrote: Tim wins the prize for the 500th Haskell package in Arch Linux, http://aur.archlinux.org/packages.php?ID=19205 Which, I should like to note, demonstrates why the original Cabal design[1] was basically right[2] in that it allows this kind of automated translation into native packages. You cannot do that with autoconf. The other distros are following a similar course though not yet quite as successfully as Don has demonstrated for Arch. There are similar translation tools for Gentoo, Debian and RPM-based distros with varying levels of sophistication and automation. I think the folks who hack on these translation tools should get together and share code and experience so we can all achieve better levels of automation. The highest levels of automation will also require more centralised QA on hackage. That's where we should be going. Duncan [1] http://haskell.org/cabal/proposal/index.html [2] I'm not at all claiming credit for that design. That was decided well before I started hacking on Cabal. Yes, I want to write something about this soon, but essentially, having a pure, declarative specifcation language for build dependencies -- with no runtime initialisation (yes, I'm looking at you, autoconf!) to define how the package is constructed -- enables analysis and translation tools like cabal2arch, which are an order of magnitude more productive. Use build-type: Simple! One person can maintain 500 packages with minimal manual intervention, while our competitors (6 erlang packages, 21 ocaml packages, 494 python packages :) have to waste a lot more manpower keeping things in shape. Cabal is going to benefit Haskell a lot in the long term -- this kind of productivity improvement is game changing. This leads nicely into the question of where we go from here. We have central hosting, a declarative build system of the first order, and native packages that are easy to construct. The next phase is a standard, comprehensive platform of packages, we can rely on, built upon the automation Cabal enables. See the Batteries Included proposal[1] for more info. -- Don [1] http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
Just an idiot-level question: so these constants are subject to revision, but *how often*? What is the actual cost of recompiling and using them *as* constants, compared with the cost of rereading the stuff every time you run the program and passing it around? -- If stupidity were a crime, who'd 'scape hanging? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reader monad, implicit parameters, or something else altogether?
G'day all. Quoting Richard A. O'Keefe [EMAIL PROTECTED]: Just an idiot-level question: so these constants are subject to revision, but *how often*? Good question. For leap seconds: - The data can change no quicker than once every 6 months. - The shortest time between changes was 6 months, and the longest (so far) was 7 years. - The mean change is once every 18 months. - You get just under 6 months' notice before a change comes into effect. (No more, no less.) For most programs, it's the last point that concerns me the most... What is the actual cost of recompiling and using them *as* constants, compared with the cost of rereading the stuff every time you run the program and passing it around? ...because the main cost probably isn't recompiling, it's redeployment. I don't know about this program in particular, but release cycles longer than six months are hardly uncommon in our business. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unboxing VT_VARIANT in hscom
I am a Haskell newbie trying to do COM automation using Haskell. I am using hscom (Krasimir's implementation of COM automation). I have run into a problem and need some help. I have a Variant returned from a COM method invocation. When I print it, it shows up as below. Variant VT_DISPATCH interface 0x00039f00 I need to invoke methods on the wrapped interface. My attempt to unbox it as below runs into 'rigid type' error. someFunc (Variant VT_DISPATCH val) query = do dispId - getMethodID MethodName val The code above generates this error. Couldn't match expected type `IDispatch a' against inferred type `a1' `a1' is a rigid type variable bound by... I am probably missing something pretty basic. Any help on this is greatly appreciated! Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
