data Stream a = forall s. Stream !(s -> Step s a) !s
data Step s a = Yield a !s | Skip !s | Done
data Tup a b = Tup !a !b
cartesianProduct :: Stream a -> Stream b -> Stream (a, b)
cartesianProduct (Stream step1 s01) (Stream step2 s02) = Stream step' s' where
s' = Tup s01 s02
step' (Tup s1 s2) =
case step1 s1 of
Yield x s1' ->
case step2 s2 of
Yield y s2' -> Yield (x, y) (Tup s1 s2')
Skip s2' -> Skip (Tup s1 s2')
Done -> Skip (Tup s1' s02)
Skip s1' -> Skip (Tup s1' s2)
Done -> Done
eft :: Int -> Int -> Stream Int
eft x y = Stream step x where
step s
| s > y = Done
| otherwise = Yield s (s + 1)
fooS :: Stream (Int, Int)
fooS = cartesianProduct (eft 0 10) (eft 0 10)
toList :: Stream a -> [a]
toList (Stream step s0) = go s0 where
go !s =
case step s of
Yield x s' -> x : go s'
Skip s' -> go s'
Done -> []
foo :: [(Int,Int)]
foo = toList fooS
Another way to put it is that HasCallStack isn't optimized away by tail call optimization. And Haskell without tail call optimization will have huge stacks.
The discussion about incentives for stability was interesting. It reminded me of the maintainership standards proposal. I think it would be very useful to have Hackage show information like how quickly a package fixes version bounds when new versions of their dependencies are released.
@mangoiv@jaror Inaccessible in what way? Cost? I doubt not colocating with ICFP would be an advantage, actually. The Haskell Symposium is an academic conference, and there's huge overlap between the audiences of ICFP and the Haskell Symposium. Moving HIW elsewhere sounds plausible to me, moving the Haskell Symposium does not.
Maybe the symposium should start catering more to industrial users, now that Haskell itself also seems to be moving more in that direction (e.g. more backwards compatibility). The symposium already allows experience reports and demos.
@jaror@mangoiv How would catering more to industrial users look like, in your opinion? And why would it be better to change the nature of the Haskell Sympoisum than to simply create / continue a different event? (FWIW, I'm an industrial user for many years now and have always felt very welcome and the Haskell Symposium. But I'm genuinely curious what you think could be done.)
@kosmikus@mangoiv I'm not really the right person to ask, having spent exactly zero time in industry. But I can imagine most industrial users have little interest in the main ICFP program and the other co-hosted workshops. So hosting the event separately at a smaller venue for just two days could make it possible to substantially lower the fees (and individual accommodation costs) which naturally makes the event more accessible. And I expect that the fees are generally a bigger problem outside of academia, so it cater more to industrial users and hobbyists.
@jaror@mangoiv I think compared to many commercial events targeted primarily at industrial users, ICFP + associated workshops is still not overly expensive. What I still don't understand is why it would be better to turn a historically primarily academic conference into something else rather than just try to create a different event. It's a bit sad that HaskellX isn't happening this year for unrelated reasons, but it used to be a good conference that was much less academic. So this can work. But if you decouple Haskell Symposium from ICFP, you'll probably have to re-build it completely anyway, because it'll lose all the academic audience it now automatically gets due to ICFP, and then I'm not sure if the brand is so important that it's better than to use a different one. Also, it's extremely risky. If you moved it away from ICFP, it might not be possible to easily undo that change.
Also, one thing to keep in mind, I don't think Haskell Symposium is suffering from a lack of attendance. It's primarily suffering from a lack of academic paper submissions. Other language workshops co-located with ICFP are mostly less serious (i.e., are encouraging more workshop-like work in progress and don't necessarily require full-paper submissions). Haskell Symposium is in a somewhat strange spot where it requires bascially the same amount of work and effort you'd put into a "full" ICFP submission, but it has much less prestige to people outside of the community that try to quantify the research output of individual researchers in order to decide whether they're worth funding / hiring (which, btw, I hate, but it's nevertheless a reality). So I think the main way to fix this is to either make it less serious as well, or to try make it more prestigious, the former being easier than the latter.
Perhaps making it less serious, but still co-locating with ICFP could also make it more interesting to industrial participants in itself, because it would make it easier for people not part of and familiar with the academic research community to get a presentation slot.
This was a fun episode. I was introduced to breadth first labeling and attribute grammars by Doaitse Swierstra at the Applied Functional Programming summer school in Utrecht. He was an inspiring figure.
The biggest disadvantage of circular programs is that it is very easy to get into infinite loops when you make mistakes. I wish there was an easy way to guarantee statically that circular programs are terminating (perhaps using types).
I think Idris' bang notation for performing effects in a do-block is pretty, it could look like this:
main = do putStrLn ("You said: " ++ !getLine)
Today, you'd have to come up with a new variable name or figure out the right combinator names:
main = do line <- getLine; putStrLn ("You said: " ++ line)
main = putStrLn . ("You said: " ++) =<< getLine
But unfortunately there are more complicated cases:
main = do print (True || !getLine == "foo")
In a strict language with built-in short-circuiting logical operations the getLine would never be performed, but in Haskell || is just a normal function that happens to be lazy in its second argument. The only reasonable way to implement it seems to be to treat every function as if it was strict and always perform the getLine:
main = do line <- getLine; print (True || line == "foo")
Do you think this is confusing? Or is the bang notation useful enough that you can live with these odd cases? I'm not very happy with this naive desugaring.
@jaror will this interact with any future proposals towards DH? I’m worried that this increase the pile of chores one would have to do to finally reach the goal of implementing them, similarly to how it happened with LinearTypes (and multiplicity polymorphism ftm) themselves.
The changes seem pretty modest as the costs and drawbacks section also says. But I wouldn't know how complicated it is to combine normal constraints with dependent types, let alone linear constraints.
@jaror yeah it seems fine at first; issue is that someone probably has to do the theory part, writing a new papers for every one new addition seems tedious 😅
Haskell
Active