Creating stubs statically
As explained in detail here: http://www.haskell.org/pipermail/ffi/2012-June/001867.html, it may be useful to have a form of foreign declaration that creates a static stub for a haskell function without exporting a symbol. Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048. It is not particularly clear how such a declaration would look like syntactically. In the ticket I proposed the following: foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback but please do suggest better alternatives. It would also be useful to see some use cases of this new form of declaration. Library binding authors: would this be a welcome addition for you? BR, Paolo ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Call to arms: lambda-case is stuck and needs your help
Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Quoting Mikhail Vorozhtsov : After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 Well, for what it's worth, my vote goes for a multi-argument \case. I find the comment on the wiki page about mistyping "\case Just x" instead of "\case (Just x)" a lot a bit disingenuous, since you already need these parens with today's lambda. The complaint that multi-argument cases are unorthodox doesn't really hold a lot of weight with me -- much more serious things than syntax have changed in GHC compared to the Report! Is there a more formal way to cast votes...? ~d ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
I like \case as is proposed. It seems the least controversial one and there's curry (\case ) for two-args, but even that seems a rare case. For what it's worth, I like the idea of omission being partiality, as in case of and if then. It seems perfectly natural to me, I don't need a \ to tell me that an expression will result in a function. But some do. So I'll go along with and vote for \case. The lack of a lambda case is one of the few "legitimate" complaints I have about Haskell's syntax so it would be marvey to see it in GHC. P.S. \if then … else …? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Thu, Jul 5, 2012 at 12:21 PM, Christopher Done wrote: > I like \case as is proposed. It seems the least controversial one and > there's curry (\case ) for two-args, but even that seems a rare case. > > For what it's worth, I like the idea of omission being partiality, as > in case of and if then. It seems perfectly natural to me, I don't need > a \ to tell me that an expression will result in a function. But some > do. So I'll go along with and vote for \case. The lack of a lambda > case is one of the few "legitimate" complaints I have about Haskell's > syntax so it would be marvey to see it in GHC. +1 for \case, I completely agree with Christopher Done. Cheers, -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 05/07/12 17:22, wagne...@seas.upenn.edu wrote: Well, for what it's worth, my vote goes for a multi-argument \case. I find the comment on the wiki page about mistyping "\case Just x" instead of "\case (Just x)" a lot a bit disingenuous, since you already need these parens with today's lambda. But you don't need parentheses with today's case. I.e. you write \x -> case v of Just x -> y Nothing -> z then you would also expect to be able to write \case Just x -> y Nothing -> z And \case looks more like case than like lambda, particularly because it uses layout. As for single argument \case, I don't really see the need for it, but I am not against. So I'll abstain from voting. Twan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Call to arms: lambda-case is stuck and needs your help
On Thu, Jul 5, 2012 at 5:21 PM, Christopher Done wrote: > I like \case as is proposed. It seems the least controversial one and > there's curry (\case ) for two-args, but even that seems a rare case. > > For what it's worth, I like the idea of omission being partiality, as > in case of and if then. It seems perfectly natural to me, I don't need > a \ to tell me that an expression will result in a function. But some > do. So I'll go along with and vote for \case. The lack of a lambda > case is one of the few "legitimate" complaints I have about Haskell's > syntax so it would be marvey to see it in GHC. I agree. I think the partial application metaphor in "case of" is very nice, but \case is okay enough, so I'm voting for whatever is most popular as long as it does the job and doesn't break compatibility. > > P.S. \if then … else …? > I'd prefer just getting a function of type a -> a -> Bool -> a and partially applying it. We need a language level solution for case because case of is fundamental and you can't do that. But if then else is just sugar. (That being said one of my principles is to trust people not to make their own code ugly on purpose, so if people really want partially applied if then else then I guess let them have it else who cares. But I don't really see the case for it.) -- Your ship was caught in a monadic eruption. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Quoting wagne...@seas.upenn.edu: Well, for what it's worth, my vote goes for a multi-argument \case. I Just saw a proposal for \of on the reddit post about this. That's even better, since: 1. it doesn't change the list of block heralds 2. it doesn't mention case, and therefore multi-arg \of is perhaps a bit less objectionable to those who expect "case" to be single-argument 3. 40% less typing! Can I change my vote? =) ~d ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote:
> After 21 months of occasional arguing the lambda-case proposal(s) is in
> danger of being buried under its own trac ticket comments. We need fresh
> blood to finally reach an agreement on the syntax. Read the wiki
> page[1], take a look at the ticket[2], vote and comment on the proposals!
If I understand correctly, we currently we have
\ apat1 ... apatn -> exp
The possibility using '\' as a layout herald (like let, do, etc.)
\ { apat1 ... apatn -> exp; ... }
is suggested on the wiki, but rejected because code like so
mask $ \restore -> do
stmt1
...
by translating it into (Section 9.3 of the 98 Report)
mask $ \ { restore -> do { }
} stmt1
http://www.haskell.org/onlinereport/syntax-iso.html
The reason for this is
1 - the layout level for '\' is the column of the 'restore' token
2 - the layout level for 'do' would be the column of the first token of 'stmt1'
3 - the '\' level is greater than the potential 'do' level so the fall through
'{}' insertion rule fires instead of the desired '{' insertion rule
4 - the '\' level is greater than the identation level for the first token of
'stms1' (now established to not be part of the 'do') so the '}' rule fires
Why not just let enclosed scopes be less indented than their outer ones?
It would then correctly translate the above. This of course implies that any
code that requires the original translation (i.e., where the last of multiple
enclosing blocks should be an empty block) would no longer work.
Is any code actually relying on this though? It seems like a pretty esoteric
corner case. If not, my vote would be to relax this rule and go with '\'
being a layout hearld with full case style matching (i.e., guards too).
Cheers! -Tyson
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Creating stubs statically
Hi Paolo, I agree that this would be useful. In fact, a couple of years ago I implemented this in GHC, but after some discussion folks were not convinced that it's a good idea. I don't remember the details but as far as I recall we "agreed to disagree" :-) The e-mail thread is over here: http://www.haskell.org/pipermail/glasgow-haskell-users/2010-March/018575.html The patch should be there too, but I suspect that GHC has moved on since than, but perhaps there's still something useful there. -Iavor On Thu, Jul 5, 2012 at 5:13 AM, Paolo Capriotti wrote: > As explained in detail here: > http://www.haskell.org/pipermail/ffi/2012-June/001867.html, > it may be useful to have a form of foreign declaration that creates a > static stub for a haskell function without exporting a symbol. > > Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048 > . > > It is not particularly clear how such a declaration would look like > syntactically. In the ticket I proposed the following: > > foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback > > but please do suggest better alternatives. > > It would also be useful to see some use cases of this new form of > declaration. Library binding authors: would this be a welcome addition > for you? > > BR, > Paolo > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
I really like the \of proposal! It is a clean elision with \x -> case x of becoming \of I still don't like it directly for multiple arguments. One possible approach to multiple arguments is what we use for multi-argument case/alt here in our little haskell-like language, Ermine, here at S&P CapitalIQ, we allow for ',' separated patterns, but without surrounding parens to be treated as a multi argument case and alt pair. Internally we desugar our usual top level bindings directly to this representation. When mixed with the \of extension, this would give you: foo :: Num a => Maybe a -> Maybe a -> Maybe a foo = \of Just x, Just y -> Just (x*y) _, _ -> Nothing but it wouldn't incur parens for the usual constructor pattern matches and it sits cleanly in another syntactic hole. A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of: foo mx my = case mx, my of Just x, Just y -> Just (x*y) _, _ -> Nothing On Jul 5, 2012, at 2:49 PM, wagne...@seas.upenn.edu wrote: > Quoting wagne...@seas.upenn.edu: > >> Well, for what it's worth, my vote goes for a multi-argument \case. I > > Just saw a proposal for \of on the reddit post about this. That's even > better, since: > > 1. it doesn't change the list of block heralds > 2. it doesn't mention case, and therefore multi-arg \of is perhaps a bit less > objectionable to those who expect "case" to be single-argument > 3. 40% less typing! > > Can I change my vote? =) > ~d > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 2012-07-05 23:04, Edward Kmett wrote: A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of: Should that also generalize to nullarry 'case of'? As in foo = case of | guard1 -> bar | guard2 -> baz instead of foo = case () of () | guard1 -> bar | guard2 -> baz I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal. Twan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
The `multi-clause lambda' seems more elegant, if the syntactical problems could be worked out. I mean, unnamed functions are thus just like named functions, something that you'd probably think to try just as soon as you needed the feature. I don't understand the issues well enough with the layout rules to comment on Tyson Whitehead's ideas about that, and for the same reason this may be a useless idea, but what if each clause were introduced by \, would that clarify the column structure, or does indented block structure require a less-indented `layout herald'? f = \ (Just a) (Just b) | a < 0 || b < 0 -> Nothing \ (Just a) (Just b) -> Just (a * b) \ _ _ -> Nothing Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More infinite simplifier bugs?
So a while back Simon added a tick counter to the simplifier: http://hackage.haskell.org/trac/ghc/ticket/5448 Are there any known bugs that can cause the simplifier to run out of memory /without/ hitting the tick counter limit? I have code that /used/ to run (at least after hacking around the previous simplifier bug): https://github.com/ronwalf/Planning With GHC 7.4.[12], it exhausts all the RAM on my machine (4GB). Compiling with -O0 fixes the problem. I can start bisecting my code to find the problem if nothing comes to mind. -Ron Alford (who seems to be good at killing the simplifier) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/06/2012 04:33 AM, Twan van Laarhoven wrote: On 2012-07-05 23:04, Edward Kmett wrote: A similar generalization can be applied to the expression between case and of to permit a , separated list of expressions so this becomes applicable to the usual case construct. A naked unparenthesized , is illegal there currently as well. That would effectively be constructing then matching on an unboxed tuple without the (#, #) noise, but that can be viewed as a separate proposal' then the above is just the elision of the case component of: Should that also generalize to nullarry 'case of'? As in foo = case of | guard1 -> bar | guard2 -> baz instead of foo = case () of () | guard1 -> bar | guard2 -> baz I realize this is getting off-topic, and has become orthogonal to the single argument λcase proposal. Yes, there is a separate proposal for that: http://hackage.haskell.org/trac/haskell-prime/wiki/MultiWayIf ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/06/2012 05:47 AM, Donn Cave wrote: The `multi-clause lambda' seems more elegant, if the syntactical problems could be worked out. I mean, unnamed functions are thus just like named functions, something that you'd probably think to try just as soon as you needed the feature. I don't understand the issues well enough with the layout rules to comment on Tyson Whitehead's ideas about that, and for the same reason this may be a useless idea, but what if each clause were introduced by \, would that clarify the column structure, or does indented block structure require a less-indented `layout herald'? f = \ (Just a) (Just b) | a < 0 || b < 0 -> Nothing \ (Just a) (Just b) -> Just (a * b) \ _ _ -> Nothing Donn This was suggested in the ticket comments, see http://hackage.haskell.org/trac/ghc/ticket/4359#comment:29 I'll add it to the list. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On 07/05/2012 10:22 PM, wagne...@seas.upenn.edu wrote: Quoting Mikhail Vorozhtsov : After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! P.S. I'm CC-ing Cafe to attract more people, but please keep the discussion to the GHC Users list. [1] http://hackage.haskell.org/trac/ghc/wiki/LambdasVsPatternMatching [2] http://hackage.haskell.org/trac/ghc/ticket/4359 Well, for what it's worth, my vote goes for a multi-argument \case. I find the comment on the wiki page about mistyping "\case Just x" instead of "\case (Just x)" a lot a bit disingenuous, since you already need these parens with today's lambda. The complaint that multi-argument cases are unorthodox doesn't really hold a lot of weight with me -- much more serious things than syntax have changed in GHC compared to the Report! \case does /not/ require parentheses. I wrote about forgetting them when using MultiClauseLambdas, e.g. \(A b) -> ... -- \ here reminds me to use () (C d) -> ... ... Y z -> ... -- After a while I forget about them because all I see is -- Pat -> Expr, and that's instantly a case-expression -- alternative clause for me. This might as well be just my personal thing. Is there a more formal way to cast votes...? People are still coming up with new tweaks. I'll write a summary email with the voted (so far) proposals list, maybe it will be easier to go on from there. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
