W/W should transform such a function into one who takes one less
argument removing any runtime overhead at least for fully applied functions.
I suppose your suggestion is then if we an expression`f x` where bar
takes multiple arguments, but doesn't use the current argument then GHC
should:
* Ins
Hi Devs,
When writing Notes, I find myself using markdown-inspired or
haddock-inspired features. The reason is that I keep telling myself
> In 5 years time, we'll surely have an automated tool that renders
Notes referenced under the cursor in a popup in our IDE
And I might not be completely
"Sebastian Graf" writes:
> Hi Devs,
>
> When writing Notes, I find myself using markdown-inspired or
> haddock-inspired features. The reason is that I keep telling myself
>
> > In 5 years time, we'll surely have an automated tool that renders
> > Notes referenced under the cursor in a popup in
ntation by spaces
>
>id :: a -> a
>id x = x
>
> And so on.
>
> I know that at least Simon was thrown off in the past about my use of
> "tool-aware markup", perhaps also because I kept switching the targetted
> tool. I don't like that either. So I
I'm open-minded, but I *really* want the text to be readily readable *in
the original source file*. So
* Back-ticks are much better than `@` signs; the latter are too noisy.
* For code, backticks add clutter. Maybe just intentend text can be
code? (Unless it's part of a bulleted list.)
On Wed
Simon Peyton Jones writes:
> I'm open-minded, but I *really* want the text to be readily readable *in
> the original source file*. So
> * Back-ticks are much better than `@` signs; the latter are too noisy.
> * For code, backticks add clutter. Maybe just intentend text can be
> code? (Unless
