[Haskell] SPLV 2022 - Call for Participation

=== More information can be found on the school webpage: http://www.macs.hw.ac.uk/splv/splv22/ Please contact one of the local organisers if you have any questions: * Ekaterina Komendantskaya e.komendantsk...@hw.ac.uk * Filip Sieczkowskif.sieczkow...@hw.ac.uk * Kathrin Starkk.st...

[Haskell] HOPE 2018: Deadline extension until June 15th

table state in functional languages, to continuations, algebraic effects and more. See the Call for Presentations at https://icfp18.sigplan.org/track/hope-2018-papers#Call-for-Presentations and please write me an email if you have any question. Thanks! — Filip Sieczk

[Haskell] Final CFP HOPE 2018

d. If you have any questions about the relevance of a particular topic, please contact the PC chairs, Filip Sieczkowski (e...@cs.uni.wroc.pl) and François Pottier ( francois.pott...@inria.fr). ** Submission link ** https://icfp-hope18.hotcrp.com/ **Important Dates** * Deadline for talk proposals:

[Haskell] HOPE 2018: Call for Presentations

e are interested in talks on all topics related to the interaction of higher-order programming and computational effects. Talks about work in progress are particularly encouraged. If you have any questions about the relevance of a particular topic, please contact the PC chairs, Filip Sieczkows

Re: The Future of Haskell discussion at the Haskell Workshop

Yes, things are clearer and I rather like the idea. The only thorny issue is that the update function for field 'wibble' is formed from but not equal to the field name itself. In short, the magic thing would be in the 'deriving' clause: If the data type declares fields with names x_1, ..., x_n an

Re: The Future of Haskell discussion at the Haskell Workshop

Hi! > So in summary, here is my proposal: > > No specific "extensible records" system. > > Define record update to be a function just like record selection is. > > Allow these functions to be in type classes. I do not understand the second and third point: As I understand your idea, record sel

Threads

Hi, I have function f:: a -> b and I need something like this: myaccept:: Socket -> IO () myaccept g = do a <- accept g t <- forkIO (f a) myaccept g What to do to have two threads working at the same time. When I am using myaccept, program is

IOError

Hi, I wrote something like "let t = try (hGetLine h1)" and I would like to check is it EOFError or not. How can I do this ?? Thanks ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Stupid wuestion about Monads :)

I have a question :) What should I do if I have something like "IO Bool" and I need "Bool" ?? And the same with other IO +something. Thank You :) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

LOOP + HANDLE

So how to write function that will wait until Handle is ready for reading ?? And is there something like "if" ?? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

LOOPS

I have a stupid question :) Is there something like "while" loop in GHC ?? Thanks very much :) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

LOOPS

I have a stupid question :) Is there something like "while" loop in GHC ?? Thanks very much :) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

lecture

Hi,   I am student of Computer Science and I have to write a lecture on ghc network module. Where can I get some code samples of this module. I am looking for short progrmas that show how to use network module.   Thanks.

Re: palm?

Wait a minute! As far as I have understood, "threaded" refers (in this context) to a style of writing (byte code) interpreters. A threaded interpreter does not have a dispatch loop which reads the next byte code and then invokes the correct handler (typically by using the byte code as an index i

Re: What does FP do well? (was How to get functional software engineering experience?)

Hi! The listlessness stuff is a precursor to deforrestation, so it replaces lists by (fewer lists and) scalars. I do not think there are any arrays involved. The most important property for being able to convert a list to an array is that there should never be two cons cells with the same tail

Re: What does FP do well? (was How to get functional software engineering experience?)

Hi! On the performance (or not) of high level code: I'm working on a compiler with a strong emphasis on generating good code for programs written in a fairly generic style. This work is very far from being completed, but some of the highlights of the compiler are: - Aggressive removal of highe

Re: Haskell 98 Revised

Hi! For whatever that is worth, my semantics agrees with Simon's point here, ie in the example code module M( C(op1) ) where-- NB: op2 not exported class C a where op1 :: a->a op2 :: a->a module N where import M

Re: Possible bug/omission in Numeric library?

Hi! In fact, we might want to be slightly more general. Why don't go for a general base conversion, much like Malcolms idea but without converting every digit to a Char. Say something like toBase :: (Integral a) => a -> a -> [a] toBase base n | n < 0 = error "Numeric.toBase: can'

Re: Incoherence

Hi! The binding form := must absolutely have a completely monomorphic type. A while back I posted the result that the MR kills principal types in Haskell. The problem with the MR is exactly that it introduces types which may be polymorphic but not overloaded. So if we want to regain principal typ

Deprecated feature section

Hi! George Russel proposed a search for things which should be deprecated. I have a very distinct unfondness for contexts in algebraic data type declarations. They make absolutely no difference except move type errors to a different part of a program (or rather, they add type errors). In that se

Re: Scope of imported names

Hello again, Wolfgang wrote > The Haskell report seems to be inconsistent here (once again). In the > beginning of section 5.3 it says > > Imported names serve as top level declarations: they scope over the entire > body of the module but may be shadowed by local NON-TOP-LEVEL bindings. >

Scope of imported names

Hi all! I have been thinking about the scoping issues for imported names. Of course, this musing is ispired by the formal static semantics I have been working on, but it is also prompted by the revised Haskell report. Section 5.5.2 relates to name clashes and has an interesting example towards t

Re: Haskell 98 - Standard Prelude - Floating Class

Hi! Jon Fairbairn wrote: > I agree too, but being able to omit method definitions is > sometimes useful -- would it be possible to make calls to > those methods a /static/ error? I suspect this would be hard > to do. Yes, quite tricky. The problem is that the class constraints (in an inference

Re: Haskell and principal types

Oops! I said THIH has problems with type synonyms. That is completely wrong. I meant type SIGNATURES and nothing else. Sorry for the confusion. /kff ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell

Re: Haskell and principal types

Hello again! John Hughes suggested that Haskell should have two forms of binding, one with call-by-name (does not preserve sharing) semantics and polymorphism and overloading and monomorphic with call-by-need (preserves sharing). The question is; would this restore principal types in general?

Re: Monomorphism, monomorphism...

Hi! Marcin wrote: > Juan Carlos Arévalo Baeza wrote: >> Karl-Filip wrote: >>>- a -> Bool (without quantification and with "IsNil a" among the >>> predicates). >> >>This is something I didn't understand either. Which predicat

Haskell and principal types

Hi all! I've been spending some time the last year writing up a formalization of the Haskell type system (actually, most of the static semantics). In doing so, I've come across an oddity. It seems that Haskell does not have the principal type property, ie there are Haskell expressions which, in

Re: [kff@it.kth.se: Re: Int overflow]

> > Karl-Filip Faxen <[EMAIL PROTECTED]> writes: > > > There is a hidden cost to trapping Int overflow ... > > operations on Ints become unsafe i.e. may raise exceptions > > This is a problem both for a global > > instruction scheduler

Re: Int overflow

m. This is not possible if the expression can raise an exception, as that would change the semantcs of the program from successful termination to termination with a run-time error. Hence the effectiveness of the cheap eagerness transformation is reduced. / Cheers, Karl-Filip