A bit of time away from my keyboard has revealed a natural way to solve this problem and others: be more like Idris. Normally, of course, I'm thinking about how Haskell's type system can be more like Idris's. But that's not what I mean here. I want Haskell's interface to be more like Idris's. Imagine this interchange: λ> :t ($) ($) :: (a -> b) -> a -> b -- click on the type ($) :: forall a b. (a -> b) -> a -> b -- click on the a ($) :: forall (a :: *) b. (a -> b) -> a -> b -- click on the b ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b -- where b's kind has a different color than usual -- click on b's kind ($) :: forall {r :: RuntimeRep} (a :: *) (b :: TYPE r). (a -> b) -> a -> b -- mouseover RuntimeRep or TYPE reveals a tooltip "($) is representation-polymorphic, meaning that `b` can have an arbitrary runtime representation. Please see http://.... for more details." Similarly, classes would render in a special color, allowing you to click on them and choose to instantiate the type at a few in-scope instances of the class at hand, changing Foldable f => f a -> Int to the much simpler [a] -> Int. This is not a minor engineering project, but it would reap wonderful rewards, addressing the problems in this thread and more. No more lying (because all lies are clickable), no more fragmented language, no more brakes on development. Evidently, Chris already agrees with this proposal: #10073 (https://ghc.haskell.org/trac/ghc/ticket/10073) Also see #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809) Any volunteers to implement this? :) Richard On Feb 5, 2016, at 7:47 PM, Artyom wrote:

I’ve amended my suggestion to say basically “this type is a slight lie, here’s a flag/command to see the true type” – this way we aren’t scaring people with implementation guts, merely letting them see the guts for themselves and then think “I don’t care about this” (which is, I think, exactly what should happen; the worst scenario here is that the beginner falls into the “I’m an advanced user, I need all features, I need to know everything, so I’ll enable the flag” trap – which is why it’s important not to call it “an advanced type” or mention “if you know what you’re doing” or anything else like that).

I don’t agree that levity can be compared to Java’s “class” or “static” – not because it’s harder to understand, but because it’s much less widely used; I don’t feel that you need to know about levity in order to be a good Haskeller. Also, unboxed types don’t imply knowledge of levity – for instance, I’ve been successfully using unboxed types for a while, but I only found out about the true type of ($) by complete accident (I think I queried the kind of -> and then got curious about question marks). Of

On 02/06/2016 03:27 AM, Mihai Maruseac wrote:

...

On Fri, Feb 5, 2016 at 7:09 PM, Richard Eisenberg wrote:

...

Another great question that has come up is about Haddock output (Hackage). I think Haddock needs to add a facility where library authors can include specializations of an overly general type. This can be done in commentary, but it's not as prominent. Such a new feature would address the ($) problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization of its real type. It would also help a great deal with FTP-related generalizations. This goes hand in hand with Artyom's suggestion of a warning in GHCi after showing the simpler type.

I'm thinking of a flag which enables/disables printing the simplest type with warning (in GHCi) or footnote (or otherwise, in Haddock). We can have the default behavior of the flag be either printing the simpler type + extra (warning/footnote) or printing the longer type and include a reference in our learning materials that beginners and people confused by the long, complex and real type, can use --use-simpler-types flag.

On Fri, Feb 5, 2016 at 9:24 PM, M Farkas-Dyck wrote:

...

-- click on the type

The question so remains: what would we write to a purely textual terminal?

We could write the simplest type with a "type :expand / :ex (or similar) to expand signature", eventually underlining the part that will be expanded first. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

Richard, That is by far the best idea I've read in this entire thread!!! There should be no more lies, no "beginner-only" preludes, etc. All information should be available on request, effortlessly, as in your example interaction with GHCi. I don't like having to set special flags to see/hide certain info, as it was proposed. Having to use the flags can easily mislead people who are not aware of them and also it is too much work. There was an issue raised with Haddocks. It's 2016 and we can easily make the haddocks more interactive by embedding some JavaScript to exactly recreate your interaction with GHCi or even, as a poor mans substitute, simply show more details on mouse hoover or have similar design like for showing instances, etc. Every programmer should understand the difference between boxed and unboxed values. Period. The fact that Haskell allows for levity polimorphism is something we should be proud of and leverage in teaching, not hide it or lie about it. Finally, I wanted to highlight explicit type application as a great didactic tool. We can now nicely provide types the same way as values to the function and I find it a great way to explain type parameters. Best, Michał On Fri, Feb 5, 2016 at 8:51 PM, Richard Eisenberg wrote:

A bit of time away from my keyboard has revealed a natural way to solve this problem and others: be more like Idris.

Normally, of course, I'm thinking about how Haskell's type system can be more like Idris's. But that's not what I mean here. I want Haskell's interface to be more like Idris's. Imagine this interchange:

λ> :t ($) ($) :: (a -> b) -> a -> b -- click on the type ($) :: forall a b. (a -> b) -> a -> b -- click on the a ($) :: forall (a :: *) b. (a -> b) -> a -> b -- click on the b ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b -- where b's kind has a different color than usual -- click on b's kind ($) :: forall {r :: RuntimeRep} (a :: *) (b :: TYPE r). (a -> b) -> a -> b -- mouseover RuntimeRep or TYPE reveals a tooltip "($) is representation-polymorphic, meaning that `b` can have an arbitrary runtime representation. Please see http://.... for more details."

Similarly, classes would render in a special color, allowing you to click on them and choose to instantiate the type at a few in-scope instances of the class at hand, changing Foldable f => f a -> Int to the much simpler [a] -> Int.

This is not a minor engineering project, but it would reap wonderful rewards, addressing the problems in this thread and more. No more lying (because all lies are clickable), no more fragmented language, no more brakes on development.

Evidently, Chris already agrees with this proposal: #10073 (https://ghc.haskell.org/trac/ghc/ticket/10073)

Also see #8809 (https://ghc.haskell.org/trac/ghc/ticket/8809)

Any volunteers to implement this? :)

Richard

On Feb 5, 2016, at 7:47 PM, Artyom wrote:

I’ve amended my suggestion to say basically “this type is a slight lie, here’s a flag/command to see the true type” – this way we aren’t scaring people with implementation guts, merely letting them see the guts for themselves and then think “I don’t care about this” (which is, I think, exactly what should happen; the worst scenario here is that the beginner falls into the “I’m an advanced user, I need all features, I need to know everything, so I’ll enable the flag” trap – which is why it’s important not to call it “an advanced type” or mention “if you know what you’re doing” or anything else like that).

I don’t agree that levity can be compared to Java’s “class” or “static” – not because it’s harder to understand, but because it’s much less widely used; I don’t feel that you need to know about levity in order to be a good Haskeller. Also, unboxed types don’t imply knowledge of levity – for instance, I’ve been successfully using unboxed types for a while, but I only found out about the true type of ($) by complete accident (I think I queried the kind of -> and then got curious about question marks). Of

On 02/06/2016 03:27 AM, Mihai Maruseac wrote:

On Fri, Feb 5, 2016 at 7:09 PM, Richard Eisenberg wrote:

Another great question that has come up is about Haddock output (Hackage). I think Haddock needs to add a facility where library authors can include specializations of an overly general type. This can be done in commentary, but it's not as prominent. Such a new feature would address the ($) problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization of its real type. It would also help a great deal with FTP-related generalizations.

This goes hand in hand with Artyom's suggestion of a warning in GHCi after showing the simpler type.

I'm thinking of a flag which enables/disables printing the simplest type with warning (in GHCi) or footnote (or otherwise, in Haddock). We can have the default behavior of the flag be either printing the simpler type + extra (warning/footnote) or printing the longer type and include a reference in our learning materials that beginners and people confused by the long, complex and real type, can use --use-simpler-types flag.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

is it safe to say that "boxed" and "lifted" are synonyms?

No. Lifted means may contain bottom. Boxed means represented by a pointer. `ByteArray#` is boxed but unlifted See https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TypeType#Classifyi... On Saturday, February 6, 2016 at 8:54:50 PM UTC+5, Imants Cekusins wrote:

in addition to Takenobu's links, Real World Haskell explains unboxing and lifting on p.583

just to clarify, for practical use, is it safe to say that "boxed" and "lifted" are synonyms? you see, term "boxed" is used in other languages. I assumed "lifting" related to monads. Hence the confusion. _______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Thank you very much Takenobu, these are very clear and extensive explanations.

1, Just to clarify, there are no actual known uses for a TypeRep-polymorphic ($), right? I thought I saw someone say that. 2, ($) has had a fib in its type for a very long time, but did it ever hurt anyone? The closest I saw was a generalized concern about it being bad when people report a bug and then hear that things are more general than they thought and I guess this makes their bug not a bug or something? Results in some confusing back-and-forth? It would be nice to get more specific about how much trouble the ($) lie has caused. 3, Is anything other than ($) TypeRep-polymorphic? If 2 is "not very much", an obvious solution is to keep lying and not worry about it. But clearly someone had a reason strong enough to make this change... what was it? If 1 is "maybe not" then an obvious solution is to just make ($) not TypeRep-polymorphic. I can't imagine that not being able to use ($) is a serious problem if you're working with # types, given that there are already tons of other restrictions. I hesitate to get distracted from the specifics, but I agree with Ben Lippemeier in that I like how haskell doesn't make me worry about boxed vs. unboxed. I'm not saying one little type annotation on one operator is suddenly making me worry since I've never even thought to run :t ($). But I'm happy that # is mostly off in its own little corner and you don't even have to know it exists until you need to get into low level optimization.

On 7 Feb 2016, at 2:59 pm, Richard Eisenberg wrote:

...

2, ($) has had a fib in its type for a very long time, but did it ever hurt anyone? The closest I saw was a generalized concern about it being bad when people report a bug and then hear that things are more general than they thought and I guess this makes their bug not a bug or something? Results in some confusing back-and-forth? It would be nice to get more specific about how much trouble the ($) lie has caused.

I don't have data, but there is a real cost to lying. It shows up in the slow-ish but steady stream of posts / questions / bug reports that are produced saying something is weird. I've seen a good number of these come up in my years in the Haskell community. I'll note that there is also a real cost to telling the truth: witness this thread. This all adds up to a need to do both, which is what we would get by having a richer REPL environment.

This reminds a lot of the FTP controversy and I feel that here too we could side step the problem by allowing modules to re-export type-specialized versions of imported symbols. E.g., Data.Function could define ($) with the new type, Prelude would re-export it with the old type (as a specialization) and anyone who needs to use the more general version would have to opt-in by importing Data.Function. In terms of documentation, the haddock version of (Data.Function.$) would show the more general type while the haddock for Prelude would show the current type (ideally with a link to the more general one).

[..]

...

Data.Function could define ($) with the new type, Prelude would re-export it with the old type (as a specialization) [..]

Could you explain why re-exporting a specialized version is better than just *defining* a specialized equivalent?

I guess that for the same reasons it was considered better not to have duplicated definitions in Data.List of the more general functions in Data.Foldable? I’m just saying this seems to be another instance of a recurrent problem that we had before and that we’ll probably face again in the future.

I'm curious... Ultimately, ($) is just a name for what is otherwise unnameable: the whitespace which means application. However, application whitespace is a bit funny since it works uniformly for mono-/polymorphic arguments, un/boxed arguments, functions/record fields, etc— which is why we keep running into issues with typing ($). So my curiosity is this: why do we insist on considering ($) to be a function in the language rather than being syntax? We have overt syntax for other forms of whitespace, namely to deal with blocks and indentation, and we don't worry about what their types are, so why not treat ($) similarly? Sure, there are higher-order uses of ($), as when people write things like fmap($x), but afaict none of our typing hacks are worried about continuing to work in those settings, so there's no particular reason to think that those uses of a higher-order function capturing function application should be considered identical to the ($) used with runST, Int#, etc. -- Live well, ~wren

what if use of ($) were confined to boxed & lifted types only? use (...) for unboxed / unlifted types. would this not simplify the issue somewhat?

On 02/08/2016 06:54 PM, Richard A. O'Keefe wrote:

Wait, those were grouping parentheses, not application ones. According to https://en.wikipedia.org/wiki/History_of_the_function_concept something explicit resembling modern ideas of a "function" appeared in the 17th century, so THAT's when time began.

I always wondered.

I was referring to grouping parentheses. Most uses of "$" are for stupid things like "sin $ 1 + 2" where parentheses would be much more clear. By "beginning of time" I thought it was clear I meant "I don't feel like looking it up," but thanks -- we now know that people have been using parentheses about 400 years longer than "$" for grouping.

As for me, I don't like ubiquitous $ everywhere, often I prefer parentheses over $ (this might be due to my Elisp practices), and I like very much dot style. Most uses of "$" are for stupid things like "sin $ 1 + 2" where parentheses would be much more clear. Agree. "$" simplifies visual perception through two factors: I think this does not hold for every single person. 1. we are relieved from counting parentheses This is not big deal if your editor/IDE can highlight parentheses and even better provide commands to jump to opening/closing parenthesis. foo (thInt $ fromIntegral $ c2hsValueInt cexp) (thInt $ fromIntegral $ c2hsValueInt cexp) foo (thInt (fromIntegral (c2hsValueInt cexp))) (thInt (fromIntegral (c2hsValueInt cexp))) Me, I get a blood pressure spike roughy here ---^ Personally, I find hard to read expressions like: someFn $ someOtherFn $ more $ more $ val (someFn . someOtherFn . more . more $ val) seems better for me, but this is also good: someFn (someOtherFn (more (more val))) Parentheses annoys me only when I need to wrap something by parentheses in Emacs with electric-pairs-mode :D

On 02/09/2016 06:27 AM, Kosyrev Serge wrote:

Case in point (only slightly contrived) -- which one is easier to visually parse to you:

foo (thInt $ fromIntegral $ c2hsValueInt cexp) (thInt $ fromIntegral $ c2hsValueInt cexp)

foo (thInt (fromIntegral (c2hsValueInt cexp))) (thInt (fromIntegral (c2hsValueInt cexp)))

Me, I get a blood pressure spike roughy here ---^

let th_exp = (thInt . fromIntegral . c2hsValueInt) cexp foo th_exp th_exp The parentheses are a warning sign, and using "$" above only lets you make it look cleaner without fixing the problem. It has hidden the fact that you're computing f(g(h(x))) twice, and there's a better way to do that.

Bryan Richter writes:

On Tue, Feb 09, 2016 at 02:27:44PM +0300, Kosyrev Serge wrote:

...

Michael Orlitzky writes:

...

Most uses of "$" are for stupid things like "sin $ 1 + 2" where parentheses would be much more clear.

"$" simplifies visual perception through two factors:

1. we are relieved from counting parentheses 2. it serves as a cue to treat the entire remaining part until ")" as part of the same expression

Case in point (only slightly contrived) -- which one is easier to visually parse to you:

foo (thInt $ fromIntegral $ c2hsValueInt cexp) (thInt $ fromIntegral $ c2hsValueInt cexp)

foo (thInt (fromIntegral (c2hsValueInt cexp))) (thInt (fromIntegral (c2hsValueInt cexp)))

My readability problem with this statement is line length. How about:

foo (thInt (fromIntegral (c2hsValueInt cexp))) (thInt (fromIntegral (c2hsValueInt cexp)))

I clearly made a mistake of duplicating a real expression.. should have picked two different expressions for an example. The point I have tried to convey was that: - the ))) ( patterns are hard to parse visually - the $ helps to alleviate that ..which is fairly orthogonal to common subexpression elimination or formatting. $ allows one to write more complex expressions -- precisely without resorting to diluting code with formatting. -- с уважениeм / respectfully, Косырев Сергей

Am 09.02.2016 um 18:24 schrieb Kosyrev Serge:

...

...

foo (thInt (fromIntegral (c2hsValueInt cexp))) (thInt (fromIntegral (c2hsValueInt cexp)))

I clearly made a mistake of duplicating a real expression.. should have picked two different expressions for an example.

The counterexamples still work. This: foo (thInt1 (fromIntegral1 (c2hsValueInt1 cexp1))) (thInt2 (fromIntegral2 (c2hsValueInt2 cexp2))) can still become this: let int1 = thInt1 (fromIntegral1 (c2hsValueInt1 cexp1)) int2 = thInt2 (fromIntegral2 (c2hsValueInt2 cexp2)) in foo int1 int2 and that's perfectly readable in my book. If you don't like the nested parentheses, use function composition: let fn1 = thInt1 . fromIntegral1 . c2hsValueInt1 fn2 = thInt2 . fromIntegral2 . c2hsValueInt2 in foo (fn1 int1) (fn2 int2) Function composition isn't the main tool though; I found that naming subexpressions always works, plus the names can help with readability if they are chosen wisely.

On Mon, Feb 8, 2016 at 4:53 AM, wren romano wrote:

I'm curious...

Ultimately, ($) is just a name for what is otherwise unnameable: the whitespace which means application. However, application whitespace is a bit funny since…

A view from the other side: 1. Delete the unnameable 2. First-class application (its not called '$' but '.' -- a minor difference) 3. Remove all specialness of it http://blog.languager.org/2014/09/pugofer.html With justifications here: http://www.the-magus.in/Publications/ewd.pdf

On 02/08/2016 11:13 AM, Marcin Mrotek wrote:

1. Delete the unnameable 3. Remove all specialness of it

... and end up with absolutely no way to apply functions that return unboxed values?

I think the point is that we don't need to worry about what the type of " " is in the expression "f x", because it's syntax for function application. If we had /explicit/ syntax for function application (read the PDF, it's good), there would be no problem to begin with -- syntax isn't typed. The suggestion in the PDF is basically to drop the "f x" syntax and always use "f $ x" which has a lot of merit if you rename "$" to something less ugly and more obvious. The paper proposes "f.x", but you could also equate "f." with "f()" to make something crazy like "f(x)" work.

On 02/08/2016 11:45 AM, Joachim Durchholz wrote:

Am 08.02.2016 um 17:32 schrieb Michael Orlitzky:

...

The suggestion in the PDF is basically to drop the "f x" syntax and always use "f $ x" which has a lot of merit if you rename "$" to something less ugly and more obvious.

I'm wondering what the merit would be.

By making "f $ x" or more generally "f $" syntax, we avoid the very issue that sparked this thread (that's what wren suggested...). We also no longer need the voodoo hacks for things like runST. It's less confusing for the parser and for students (explicit is better than implicit), etc.

On 02/08/2016 12:15 PM, Joachim Durchholz wrote:

Sure, but you don't make that an absolute. Otherwise you'd have to remove operator precedence, too. And the end result would look like Lisp.

juxtaposition is so entrenched in almost all branches of math that using that implicitness to reduce syntactic overhead is a net win.

I don't think anyone was seriously suggesting getting rid of "f x" for function application. Rustom's post is interesting because it suggests that if you're going to have only one of "f x" or "f $ x", then it should be the latter. It's a fun thought experiment. Since we're stuck with "f x", the question is: do we want *both* as syntax? If most uses of "$" are for, putStrLn $ "Hello" ++ " world!" to avoid, putStrLn ("Hello" ++ " world!") then I think it's silly to worry about the type of "$". Most people don't have to know, care, or use it -- the second example is much clearer. And if instead you're doing some kind of fmap (((f $) $) $) gymnastics, then you probably don't mind the type of "$".

Are you seriously suggesting to overloaded semicolons to *avoid* confusing newcomers to Haskell from other languages? And all of that just in case that newcomer happens to look at the output of :t ($)? On Mon, Feb 8, 2016 at 8:28 PM, Joachim Durchholz wrote:

Am 08.02.2016 um 18:59 schrieb Michael Orlitzky:

...

If most uses of "$" are for,

putStrLn $ "Hello" ++ " world!"

to avoid,

putStrLn ("Hello" ++ " world!")

then I think it's silly to worry about the type of "$". Most people don't have to know, care, or use it -- the second example is much clearer.

Only if you are on the standard programming language mindset. I.e. those who learn Haskell first will find putStrLn "Hello" ++ "world!" more natural.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Feb 8, 2016, at 10:13, Marcin Mrotek wrote:

... and end up with absolutely no way to apply functions that return unboxed values?

Besides juxtaposition, could you not make another operator (e.g. "$#") for this purpose? --Will

On 02/08/2016 12:33 PM, Imants Cekusins wrote:

would f 1 ; 2 + 3

look ok instead of f 1 $ 2 + 3

?

the semicolon would be part of syntax, not something with a type the intuition is: pause application until the rest is applied

The semicolon is already appropriated sadly: ghci> do { putStr "Hello" ; putStrLn " world!"; } Hello world!

On Mon, Feb 8, 2016 at 1:01 PM, Imants Cekusins wrote:

would it be a bad taste to overload ;?

Won't it create ambiguity problems like the following? ghci> do { putStr "Hello, the answer is "; print $ 40 + 2 } being changed into the invalid ghci> do { putStr "Hello, the answer is "; print ; 40 + 2 } -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

a) within { code block 1; code block 2; } - keep the current meaning : new statement

On 9/02/16 6:33 am, Imants Cekusins wrote:

would f 1 ; 2 + 3

look ok instead of f 1 $ 2 + 3

No. Semicolon already means something in Haskell, and that's not it.

Am 07.02.2016 um 09:26 schrieb Ben Lippmeier:

It also feels like the same class of problem as what the segmentation registers in the x86 architecture try to address. Does anyone here know how the 8086 processor addresses more than 64k of memory with only 16-bit address registers? I sure wish I didn’t.

Yes I do, and yes I wish I didn't either. For the Int/Int# concept, the approaches I have seen either ignore the efficiency and let the machine figure out what to do (Smalltalk, Python, pre-Int# Haskell), or they complicate the type system at the expense of polymorphism (Java, Eiffel), or they complicate the type system even more to regain some form of polymorphism (C++, today's Haskell). I guess the world is still waiting for an approach that does not force this choice on language designers. Aside note: My own choice would be to have an annotation that tells the compiler to keep something unboxed if it can, and if it cannot, have it print a warning why not. Not seeing this choice in the wild means that either language designers didn't find the right way to do this, or the idea as such is dumb; I don't know which.

With Int/Int#, public/private and x86 segmentation, the abstraction never really worked in the first place. However, because there weren’t any other obvious solutions at the time, these “features” were grandfathered into the culture of the technology.

As much as I agree that design misdecisions can perpetuate by becoming part of the technology culture (see PHP's view on security, or C's insistence on microoptimization), this did not happen for x86 16-bit segment/offset addressing. Even Microsoft switched as fast as they could, and that was in the old days when features were far more important than security or even stability.

For the disciples of a particular technology, the recognition of problems in the fundamental design of that technology tends to result in extensions to what they already have -- rather than backing up and reconsidering WTF they were thinking in the first place.

Word. Problem is that it is possible to add features to existing language, but almost impossible to remove them. Those working on practically useful type systems want to solve an existing problem in an existing language, so they don't have a motive to reconsider; even if they did, they'd quickly drop the thought because whatever the change they'd want, it would get rejected because it would break existing code left and right. This seems to be a universal problem. Every language that I know has it, including Haskell (which I don't really know well enough but the discussion and options are just as with any other language). Regards, Jo

This doesn't really work in a non-strict language like Haskell with uncontrolled recursion. We often need a lazy int that may be _|_ and shouldn't affect termination of the program unless demanded. The result would be that you'd actually have to compile all of your code several ways times the number of type arguments and you'd get rather severely different semantics around evaluation as it switched between strictness and laziness. Moreover, cycles that happened to involve one of these values would have to tie the knot strictly, meaning you'd have issues like scheme where letrec secretly exposes extra, observable, #f cases when you encounter a cycle. -Edward On Sun, Feb 7, 2016 at 7:17 AM, Ben Lippmeier wrote:

...

On 7 Feb 2016, at 9:50 pm, Joachim Durchholz wrote:

...

For the Int/Int# concept, the approaches I have seen either ignore the efficiency and let the machine figure out what to do (Smalltalk, Python, pre-Int# Haskell), or they complicate the type system at the expense of polymorphism (Java, Eiffel), or they complicate the type system even more to regain some form of polymorphism (C++, today's Haskell).

Although I haven’t implemented it, I suspect another approach is to just specialise every polymorphic function at its unboxed type arguments. Boxed and unboxed value types would share the same kind. Of course, full specialisation of polymorphic code assumes that code is available in the interface files, but we’ve almost got that already. Dealing with mutual recursion could be a pain, though.

I don’t think specialisation was an option back when unboxed types were originally implemented. I believe GHC’s support for cross module inlining came some time after the unboxed types, if the publication dates of the relative papers are to be a guide.

Ben.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 06/02/2016, Michał Antkiewicz wrote:

Every programmer should understand the difference between boxed and unboxed values. Period.

Why? The performance of some code is not critical. Sometimes i need not care about 1 more indirection in their code, and some authors need never care, and in these cases i appreciate Haskell not forcing me to care. I'm not saying every language ought to hide this ­– i quite like Rust, for example – but most times hiding it works quite well for me in Haskell.