On Fri, 2010-05-14 at 22:54 -0400, C. McCann wrote:
> On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka
> wrote:
> > 1. Haskell Class/Type famillies/... are conceptually different then
> > classes and interfaces.
>
> I believe interfaces would be roughly equivalent to the subset of
> single-para
On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka wrote:
> 1. Haskell Class/Type famillies/... are conceptually different then
> classes and interfaces.
I believe interfaces would be roughly equivalent to the subset of
single-parameter type classes such that:
- All type class methods are functi
On Saturday 15 May 2010 02:53:43, Brandon S. Allbery KF8NH wrote:
> On May 14, 2010, at 20:24 , Brandon Simmons wrote:
> > The other baffling thing is this: if the debugging line 426 is
> > uncommented, then even running:
> >
> >$> runghc Befunge.hs --quiet mycology.b98
> >
> > ...will fail. Bu
On May 14, 2010, at 20:24 , Brandon Simmons wrote:
The other baffling thing is this: if the debugging line 426 is
uncommented, then even running:
$> runghc Befunge.hs --quiet mycology.b98
...will fail. But all we're doing is a call to `putStr`! Why would
that trigger an error?! Maybe there w
On Fri, 2010-05-14 at 10:40 -0700, Daryoush Mehrtash wrote:
> In this presentation
>
> http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=907
>
> the speaker talks about F# on .Net platform. Early on in the talk he
> says that they did F# because haskell would be "ha
Aran Donohue writes:
> If I notice a new library version I'll be happy to make the requisite
> changes myself, too :)
One thing I think I should mention: it might also be helpful to say
which packages your article uses rather than the modules (as that
involves more work finding which packages ar
On Fri, May 14, 2010 at 4:53 PM, Antoine Latter wrote:
> On Fri, May 14, 2010 at 4:25 PM, Derek Elkins
> wrote:
>> You did it wrong. All you did was Church encode the Either type.
>> Your bind is still doing a case-analysis. All you have to do is use
>> ContT r (Either e). The bind implementa
On Fri, May 14, 2010 at 4:25 PM, Derek Elkins wrote:
> You did it wrong. All you did was Church encode the Either type.
> Your bind is still doing a case-analysis. All you have to do is use
> ContT r (Either e). The bind implementation for ContT is completely
> independent of the underlying mon
You did it wrong. All you did was Church encode the Either type.
Your bind is still doing a case-analysis. All you have to do is use
ContT r (Either e). The bind implementation for ContT is completely
independent of the underlying monad. It doesn't even require the m in
ContT r m to be a functo
dmehrtash:
> Would there be issues (lazy evaluation, type system...) with other languages
> calling a Haskell code in a hypothetical Haskell in .NET?
There are always issues, but conceptually it is no harder than calling
Haskell from C, which is relatively straight forward.
__
Hi,
Am Freitag, den 14.05.2010, 15:31 -0300 schrieb Felipe Lessa:
> On Fri, May 14, 2010 at 08:57:42AM -0700, John Millikin wrote:
> > Additionally, since the original bytestring is shared in your types,
> > potentially very large buffers could be locked in memory due to
> > references held by onl
Would there be issues (lazy evaluation, type system...) with other
languages calling a Haskell code in a hypothetical Haskell in .NET?
Daryoush
On Fri, May 14, 2010 at 10:43 AM, Don Stewart wrote:
> dmehrtash:
> > In this presentation
> >
> >
> http://norfolk.cs.washington.edu/htbin-post/unres
Hello Don,
Friday, May 14, 2010, 9:43:38 PM, you wrote:
> Most .NET libraries are imperative, use mutable state -- so binding to
they are also OOP. ocaml supports OOP while haskell doesn't
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
On Fri, May 14, 2010 at 08:57:42AM -0700, John Millikin wrote:
> Additionally, since the original bytestring is shared in your types,
> potentially very large buffers could be locked in memory due to
> references held by only a small portion of the document. Chopping a
> document up into events or
dmehrtash:
> In this presentation
>
> http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=
> 907
>
> the speaker talks about F# on .Net platform. Early on in the talk he says
> that they did F# because haskell would be "hard to make as a .Net language".
>
> Does a
In this presentation
http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=907
the speaker talks about F# on .Net platform. Early on in the talk he says
that they did F# because haskell would be "hard to make as a .Net
language".Does anyone know what features of Has
The primary problem I see with this is that XML content is
fundamentally text, not bytes. Using your types, two XML documents
with identical content but different encodings will have different
Haskell values (and thus be incorrect regarding Eq, Ord, etc).
Additionally, since the original bytestrin
On Fri, May 14, 2010 at 02:18:42PM +0200, Julian Fleischer wrote:
> Hello,
>
> i'm playin' around with GHCs Haskell and some extensions. I'm already aware
> of that functional dependencies are "very very tricky", but there is
> something I don't understand about there implementation in GHC. I've
I'm not knowledgeable enough in type systems to understand the paper, therefore
I do not know if this email answers anything about your "request for comments".
For what I understand of the current possibilities of GHC, being able to use
types for ensuring the axioms of algebra (groups, rings and
On Fri, May 14, 2010 at 11:30:40PM +1000, Ivan Lazar Miljenovic wrote:
> Brent Yorgey writes:
>
> > On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote:
> >> On 13 May 2010 04:12, Brent Yorgey wrote:
> >> >
> >> > * "Demand More of Your Automata" by Aran Donohue
> >>
> >> Great,
If I notice a new library version I'll be happy to make the requisite
changes myself, too :)
Aran
On Fri, May 14, 2010 at 9:30 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:
> Brent Yorgey writes:
>
> > On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote:
> >> On 13 M
On Friday 14 May 2010 15:32:10, Bulat Ziganshin wrote:
> Hello Julian,
>
> Friday, May 14, 2010, 4:18:42 PM, you wrote:
> > Now, if I type
> >
> >> 3 + 4
> >
> > it does not work, and i really don't understand why. If i ask GHCi
> > for 3's type ($ :t 3) it will answer "3 :: (Prelude.Num t) => t".
> All of STM (Software Transactional Memory) is GHC-specific.
Hm, it's odd that only TChan mentions it...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Julian
Variations of this one come up quite often, in a nutshell the
typechecker doesn't use the instance context in the way you are
expecting:
> instance (Prelude.Num x) => Num x x x where
^^^
instance context
GHC takes less notice of the context than you mi
Hello Julian,
Friday, May 14, 2010, 4:18:42 PM, you wrote:
> Now, if I type
>> 3 + 4
> it does not work, and i really don't understand why. If i ask GHCi
> for 3's type ($ :t 3) it will answer "3 :: (Prelude.Num t) => t".
> But, if 3 and 4 are Prelude.Nums and there is an instanfe Num x x x
> for
Julian Fleischer wrote:
Hello,
i'm playin' around with GHCs Haskell and some extensions. I'm already aware of that functional
dependencies are "very very tricky", but there is something I don't understand about
there implementation in GHC. I've constructed my own TypeClass "Num" providing a
s
Brent Yorgey writes:
> On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote:
>> On 13 May 2010 04:12, Brent Yorgey wrote:
>> >
>> > * "Demand More of Your Automata" by Aran Donohue
>>
>> Great, because of Aran I now can't change some of the bits of API in
>> graphviz without makin
On Fri, May 14, 2010 at 02:37:19PM +1000, Ivan Miljenovic wrote:
> On 13 May 2010 04:12, Brent Yorgey wrote:
> >
> > * "Demand More of Your Automata" by Aran Donohue
>
> Great, because of Aran I now can't change some of the bits of API in
> graphviz without making the code examples in his arti
Friends
Many of you will know that I've been muttering about re-engineering GHC's type
inference engine for some time now. Dimitrios, Tom, Martin and I have just
completed an epic paper describing the Glorious New Framework that forms the
substance of the above mutterings:
http://haske
Hello,
i'm playin' around with GHCs Haskell and some extensions. I'm already aware of
that functional dependencies are "very very tricky", but there is something I
don't understand about there implementation in GHC. I've constructed my own
TypeClass "Num" providing a signature for (+), having m
Hi,
an idea recently crossed my mind that describes a (possibly?) useful way
of accessing XML data from Haskell that is very memory efficient – at
least as long as you only read the XML; for XML processing and
generation, other existing libraries are probably well suited.
Given a (possibly very l
The new version (0.2.0.1) is on Hackage.
vacuum-ubigraph now depends on Hubigraph, basic customization is now
possible, e.g.:
> import System.Vacuum.Ubigraph
> import Graphics.Ubigraph
> myNodeStyle n = map (setColor "#ff") $ defaultNodeStyle n
>where
>setColor color (VColor _
Ozgur Akgun wrote:
In this case I think you should either make it a separate package, or don't
hide it in this module. It looks like an easy way to call Ubigraph from
Hhaskell, and there is no apparent alternative (in hackage) so why hide it?
I've contacted Kohei Ozaki, the author of Hubigraph,
On Mon, 10 May 2010, Max Cantor wrote:
Based on some discussions in #haskell, it seemed to be a consensus that
using a modified continuation monad for Error handling instead of
Eithers would be a significant optimization since it would eliminate a
lot of conditional branching (everytime >>= i
On 14 May 2010 00:10, Derek Elkins wrote:
> On Thu, May 13, 2010 at 10:49 AM, Edward Amsden wrote:
>> On Wed, May 12, 2010 at 3:29 PM, Peter Robinson wrote:
>>> As far as I know, TChan needs the 'retry' combinator which requires GHC's
>>> RTS.
>>> Same is true for TMVar, I think.
>>
>> (sorry f
Henning Thielemann writes:
> Heinrich Apfelmus schrieb:
>
>> Ivan Miljenovic wrote:
>
>>> I'm not sure I understand what you're saying here: first you said you
>>> wanted to be able to specify a vertex type, now you're saying that you
>>> don't want to know what the vertex type even is (except th
Heinrich Apfelmus schrieb:
> Ivan Miljenovic wrote:
>> I'm not sure I understand what you're saying here: first you said you
>> wanted to be able to specify a vertex type, now you're saying that you
>> don't want to know what the vertex type even is (except that it's some
>> abstract Node type)?
Heinrich Apfelmus writes:
> I'd be happy with either one. :) In both cases, I want to specify a
> custom vertex type.
Except an abstract type isn't a custom vertex type...
> I can either do that directly if the library permits, though I think the
> solution with associated types is too cumbersom
I'd also think of Harvard (Morrisset), Tufts (Ramsey), Portland State (Jones,
Sheard), Yale (Hudak), North Eastern (Wand, Felleisen, Shivers), Utah (Flatt),
Chicago (Reppy, MacQueen), North Western (Findler).
Simon
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org
Ivan Miljenovic wrote:
> Heinrich Apfelmus wrote:
>>
>> Yes, the integers are just indexes. Of course, the example with the even
>> integers is a bit silly; but if the integers are actually indexes, then
>> it's conceptually cleaner to make them abstract, i.e.
>>
>>data Node -- constructors ar
40 matches
Mail list logo
