<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 8:11 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Mar 9, 2021, at 3:34 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Well, it sounds like you are saying that to use FFI one would have to buy into DH design.  My concern is not about what pragmas the users have to write---after all we could make them write no pragams whatsoever.  It is about what users would have to understand. For example, why does it matter that there is no data constructor `Bool` in scope?   I am passing a type to `sizeOf`, why would GHC all of a sudden get confused between the type and the value?</span></div></blockquote></div><br><div>Just as much as users of arithmetic have to buy into a design using type-classes. That is, we're aiming to design a cohesive language, and that means that someone trying to understand the design of the language (i.e. our FFI user) will have to consider it holistically.</div></div></blockquote><div><br></div><div>I don't see how type-classes are related to the current point. Yes, we want to consider a cohesive language design, but this doesn't mean that everything has to depend on everything.  The nice benefit of the extension system is that it allows us to experiment with language changes modularly.  As I see it, here we have a choice between:</div><div>   A. a modular opt-int design that is close to what is already used by a lot of a projects (i.e., something like `sizeOf @Bool`), and</div><div>   B. an alternative design (i..e, `sizeOf Bool`) that depends on an unrelated feature (dependent types), that we have zero experience with, and require major changes to how something as basic as name resolution works.</div><div><br></div><div>It sounds like #378 is asking us to always make choice B.   I think a better plan is to prefer option A, as we have been for a long time now.  I don't think that precludes the work on dependent types in any way (ergonomic or not, whatever that means).  Once that work is done, it might subsume some existing extensions, and folks would have a choice to write things one way or another depending on their needs.  I expect in the long run, one of the designs might become the common way to do stuff, and eventually we might depreciate some of the extensions that are not used any more.     To me, this seems to be the right way to grow a living language like Haskell. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>As for confusion between types and values: this is the heart of the matter. I agree that, taking #281 alone, it would make more sense to say sizeOf @Bool. But in the context of a design that might support dependent types, it makes more sense to say sizeOf Bool, and have name lookup try both namespaces (the data constructor namespace first, followed by the type namespace). This is why I wrote #378, so that we could decide which design is better for #281.</div></div></blockquote><div><br></div><div>I don't see how `sizeOf Bool` makes more sense than `sizeOf @Bool` in a language with dependent types, this seems purely a matter of taste.  As I mentioned before, I find `sizeOf @Bool` more readable than `sizeOf Bool` exactly because I don't need to keep in my head yet another thing (i.e., which `Bool` are we talking about here).  By the way, in case the `Bool` example seems absurd, using `newtype`s is quite common when doing FFI bindings, and the normal pattern there is to use the same name for the value and type constructor, so this is something that we should not gloss over lightly.</div><div><br></div><div>-Iavor</div><div> </div></div></div>