Re: Proposal: ArgumentDo
Hi all, On 07/09/2016 08:09 AM, C Maeder wrote: The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression: (if c then f else g) . \ x -> h x Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right. This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".) In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language. I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong. Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi all, Joachim Breitner wrote: > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > > I don't think so: https://ghc.haskell.org/trac/ghc > /wiki/ArgumentDo#Bl > [...] > Where is the outer set of parenthesis coming from? > > This is all not related to the ArgumentDo notation. Note that [...] The very fact that that experts can't easily agree on how a small Haskell fragment is parsed to me just confirms that Haskell already is a syntactically very cumbersome language. The present proposal just makes matters worse. For that reason alone, I don't find it compelling at all. (So -1 from me, then.) I will not repeat the many other strong arguments against that has been made. But I must say I don't find the use cases as documented on the associated web page compelling at all. Maybe there is a tacit desire to be able to pretend functions are keywords for various creative uses in supporting EDSLs and such. But for that to be truly useful, one need to support groups of related keywords. Something like Agda's mixfix syntax springs to mind. But this proposal does not come close, so the benefits are minimal and the drawbacks large. As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Hi, I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. +1 from me. The deep file system hierarchies imposed by the assumption that hierarchical module names need to be matched by a hierarchical directory structure has always bothered me (well, since hierarchical modules were introduced into Haskell some 15 years ago). In part because I do find it inconvenient, even if navigation arguably is not too hard, but more importantly because I think that language naming conventions in general should be as decoupled as possible from naming conventions of file systems/the mapping to how source code happen to be stored and organised on any particular system. While I do acknowledge the pragmatical convenience of essentially one-to-one mappings between module and file names, I think this proposal would be a step in the right direction, if feasible. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi all, Ian Lynagh wrote: Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. From a teaching perspective, I'd hope the philosophy is still known-good releases. The Haskell platform is what we deploy on our teaching machines, and we really need to be able to trust that it will work very smoothly, or we'd risk losing lots of valuable teaching time and, even worse, putting lots of students off Haskell. (Getting students to appreciate Haskell is an upwards struggle at the best of times anyway.) Something like new run-time system features sounds like something that really ought to be tested very thoroughly before being integrated into the HP. So, for (general) teaching, at least, stability over new features any day. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Hi, On 04/25/2012 09:15 AM, Yitzchak Gale wrote: Because all other uses of OverloadedStrings that I have seen, and there are many, are ill-advised in my opinion. They all should have been quasiquoters. But the problem here is that reasonable people may choose to disagree as to what is ill-advised or not. Thus, rather than generalising the existing approach to overloaded literals in the most straightforward way possible to strings, the argument is that overloaded string literals need to be handled differently due to a fundamentally subjective argument about what is ill-advised or not, and how overloaded strings might be abused unless there is some special checking in place. I'm not saying that partial instances of fromString is a good idea. In fact, I'm prepared to believe those who say that all instances of this they have come across are ill-advised. But that is not to say that it necessarily always has to be a bad idea. Thus, it seems to me that a systematic language extension is preferable for simplicity and as it does not add any fundamentally new issues, to one which leads to a more involved design based on subjective arguments about programming style. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
Hi, Yitzhack Gale wrote: Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? I don't really see the irony, I'm afraid, as nothing really has changed, and as Simon M. that I don't see what the fuss is about. Presumably, the syntax of string literals as such is still going to be checked by the scanner, as it always was? And the issue, then, is whether an overloaded fromString is total in all its overloadings? Or did I miss something central, here? Well, Haskell is not a total language, so the fact that fromString might have non-total overloadings is not surprising. Yes, fromString would be implicitly inserted, just like e.g. fromInteger for overloaded integer literals, to create the effect of overloaded literals, but this is really just a convenience, albeit an important one. The benefit of an approach to overloading of string literals that is analogous to the existing method for overloading of numeric literals would seem to me to outweigh the benefits of additional static checking through an essentially new approach to overloading of literals for a specific case. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Hi,
Just checking my understanding here as I have not followed this thread
in all its details.
Gabor Lehel wrote:
I agree completely. This is what I like about DORF: the D stands for
Declared, which is referring to the fact that the contracts are
explicit. Record fields aren't automatically polymorphic based on
their name and type, as with SORF, rather they are scoped and
disambiguated in the same way as classes.
So, with both DORF and your variant of it, am I correct in understanding
that polymorphic fields, be it universally quantified as in
data ARecordType a =
C1 {
...,
fieldX :: a,
...,
fieldY :: a - a,
...
}
or existentially quantified as in:
data AnotherRecordType =
forall a . C2 {
...,
fieldU :: a,
...,
fieldV :: a - Int,
...
}
would no longer be possible?
Note that the type variable a in both cases scope just over the
constructor(s) of the data type in question. So any attempt at
declaring the types of the fields outside of this context,
be it explicitly with the fieldLabel notation, or implicitly as
per your proposal, would not be possible. E.g.
fieldLabel fieldY :: a - a
would presumably mean
fieldLabel fieldY :: forall a . a - a
resulting in ARecordType becoming second-order polymorphic
where the value of fieldY would *have* to be a polymorphic function,
which is very different from the original definition.
Similarly, the whole point with the existentially quantification is
to allow a number of fields to share some specific but arbitrary type,
which again means that any attempt to type these fields outside of the
context of the datatype to which they belong would result in something
different.
Note that fieldU and fieldV cannot be used as projection functions
due to escaped type variables, but that field selection by pattern
matching is perfectly fine.
Both constructions above are very useful and, I'd argue that a design
that rules them out actually is a rather poor fit for a language like
Haskell.
To be completely honest, I, at least, would be much happier keeping
working around the present limitations of Haskell's named fields by
picking my field names carefully, than losing the above.
Or am I missing something? E.g. is the idea that sharing of fields
only applies to fields of monomorphic type, i.e. whose type can be
declared globally?
Best,
/Henrik
--
Henrik Nilsson
School of Computer Science
The University of Nottingham
n...@cs.nott.ac.uk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Posting etiquette, was Re: Records in Haskell
Hi, On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote: One could also argue that a good email client should automatically hide long quotes. In fact, I guess many people are not even aware of the problem because their client does this. But then what is the point of including the text in the first place if it is understood it is only there to be hidden? Besides, personally, I don't want my e-mail client to attempt (and, short of it truly having an understanding of what is being said, inevitably fail) to understand which parts of an e-mail are of interest to me and which parts are not. No, I agree completely with Malcolm: not taking the time to quote ONLY what is of relevance to provide the immediately relevant context for a point one wishes to make is a failure of communication and, indeed, an abuse of other's time. Thanks, Malcolm, well said! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Two Proposals
Hi all, Simon PJ wrote: should we not treat [a,b,c] as short for return a `mappend` return b `mappend` return c [...] I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map String Int. Probably not. Maybe that's a shortcoming... but such Maps are a rather surprising use of list literals. Maybe. But not more surprising than how, say, numeric literals are used in many EDSLs. I also like George's proposal. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
| But it'd remove | and | as a | valid operators, at least for quasiquote customers. I don't know | how bad that would be. | | Good brackets are scarce. I'd prefer to stick with one of the many | fine variations on [|...|] currently being discussed. I agree with this. My gut feel is to stick with [| ..|] and variants, and live with the fact that TH and QQ aren't using them in quite the same way. Seconded. Removing | and | as valid operators is potentially quite bad, in my opinion worse than the interference with the list comprehensions for quasiquote customers, because the operators may come from various external libraries that one really would like to use. The list comprehension interference is strictly confined to modules where quasiquoting is enabled. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
Hi Simon, For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! For info, My PhD student George Giorgidze and myself are using it for our EDSL Hydra for non-causal modelling and simulation of physical systems. Indeed, it is a very cool feature. Actually, for us, almost essential, as it gives us *principled* control over the syntax of the deep aspects of our embedding in a way that the usually embedding tricks just don't provide. We'll have a look. Thanks for letting us know! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Quasi quoting
Hi all, Simon wrote (answering Robert Greayer): A variant of your suggestion would be: for any quote [|..blah..|] behave as if the programmer had written [quasiQuoter| ...blah...|]. That is, simply pick up whatever record named quasiQuoter is in scope. Then you'd say import Pads( quasiQuoter ) and away you go. But you can only use one at a time. Yes, I can see that (or one of the alternative forms proposed) would sometimes be convenient. But, being explicit about *which* syntax one is switching into does arguably enhance readability. Without this cue, the reader have to hunt for the appropriate binding before he or she can make sense of a piece of quasiquoted text. Also, as Simon suggests, being explicit makes it possible to use more than one quasiquoter at a time (in one module). Potentially quite useful. I can see being explicit about which quasiquoterbeing to use would be a bit of an issue in a setting with lots of very small fragments being spliced in all over the place. But at least in our experience, and what we've seen in Geoffrey's papers, quiasiquoted code fragments tend to be relatively substantial, where naming the quasiquoter doesn't add much overhead at all. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT question
Hi, SPJ wrote: The right fix is alas not very simple, which is why I have not done it. (It involves what Martin Sulzmann calls implication constraints.) However, GADTs and type classes ought to be fine together, and the fact that many people have reported bugs suggests that the interaction is useful. I plan to tackle it in the next couple of months. Would this also address how plain old Algebraic Data Types and type classes work together? The issues seems related. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT question
Hi Garrett, I get an error No instance for (Fractional a) arising from the use of '/' This seems odd to me, since Div is constrained to have fractional arguments. Is there something obvious I'm missing? Unless GADTs are handled specially, and I don't think they are in this case, this problem is not specific to GADTs but related to how type constraints on constructors are handled in general. Basically, a constraint on a constructor has no effect beyond beyond constraining what the constructor can be applied to (see the Haskell 98 report 4.2.1). In particular, when you take a constructed value apart through pattern matching, the constraints do not come into play: hence the no instance message. It has been suggested a number of times that constraints on constructors should have a more profound meaning, and maybe GADTs make this even more desirable, as your example suggest. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scoped type variables
Hi all, Olaf Chitil wrote: Hence I support Jon in that ghc should only allow those type variables a wider scope that have been explicitly declared with the non-Haskell 98 keyword forall. I'm inclined to support Jon and Olaf here. I'm pretty sure there's lot of code out there that use -fglasgow-exts for all sorts of reasons totally unrelated to scoped type variables. Moreover, I suspect that type signatures for local definitions are quite common too. I, at least, use them a fair bit. So, unless it is 100% clear that the proposed additional way of introducing scoped type variables really is the way to go, I would say go for the version that breaks the fewest programs. If nothing else, if it does turn out to really be the right way, it would seem fairly easy to later generalize the rule, by not requiring an explicit forall (and thus recovering the property that the current type signature syntax is just a syntactic shorthand) than go the other way. Personally, I always get a bit worried when there is too much magic going on, e.g. when the meaning of syntactic constructs are stretched in various ways in attempts to do the right thing tacitly. I believe it usually better, in the long run at least, to state intentions more explicitly. E.g., in this case, maybe it isn't such a bad idea after all to differentiate syntactically between binding occurrences and referring occurrences of scoped type variables? Thus, also from this perspective it would seem that requiring an explicit forall for introducing scoped type variables would be the better option as it could be argued that intentions are stated a bit more explicitly that way, although maybe not in as explicitly as could be desired. It is, however, unfortunate that a signature without outer foralls no longer would be just a syntactic shorthand for signatures with the foralls mentioned explicitly. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using --make with -odir and hierarchical modules
Sven Panne wrote: Allowing leaf names to be equal is essential for the whole hierarchical module business! Obviously, yes. Otherwise you would get evil non-local interactions between different modules. And in practice it doesn't seem to be a problem for ar/ld, because the base package and the GLUT package have lots of examples for equal leaf names (see below). Interesting. I'm not sure how ar/ld handle this exactly, but I guess it works because of an index in the archive. From the Linux ar man page: Yes, I did notice, as I wrote, that at least GNU ar seemed to cope with putting many files having the same name into an archive if the archive is built in a single operation. Maybe the index is instrumental in that. Maybe not. However, I can't really see how this would work if an archive is updated incrementally, for example as per default Make rules. For example, if an archive fie.a contains two foo.o, and one does ar rv fie.a foo.o then how could ar possibly know which foo.o to replace? So I would be a bit nervous about putting files with the same names into an archive. At least one has to be careful when constructing the archive to make it work. And if some libraries really rely on this, it would be nice to know that this is universally supported by all ar programs, linkers, compilers, etc. Alternatively, maybe one should reconsider how object files are named. /Henrik -- Henrik Nilsson Yale University Department of Computer Science [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
