Dear Haskell Folks, I am sure you are fully aware that the most painful decisions that a language designer has to make are those concerning the syntax of the language. Earth shattering disputes have been fought over the syntax of programming languages with equals only in arguments over the monomorphism restriction...and, well, maybe also n+k patterns. In a previously closed discussion concerning the syntax of implicit parameter bindings, it has been suggested to lay the facts open to your scrutinising eyes, in the hope that a wise decision will emerge. The Status Quo ~~~~~~~~~~~~~~ Given a function that requires an implicit parameter addBase :: (?base :: Int) Int => Int addBase x = x + ?base both GHC and Hugs currently support implicit parameter bindings using syntax based on the keyword `with', as in addBase 5 with ?base = 10 For the motivation behind implicit parameters and their semantics, please see Lewis et al's POPL paper <http://www.cse.ogi.edu/~jlewis/implicit.ps.gz>. The Problem ~~~~~~~~~~~ Both GHC and Hugs support implicit parameters only when a command line option is given that instructs them to enable language extensions that go beyond Haskell 98. However, as soon as this command line option, which activates all sorts of extensions, is given, `with' suddenly becomes a keyword and any Haskell code that uses `with' as a variable name fails to parse. Given that `with' is a quite short and rather common word, this problem is hard to neglect. In particular, the XML library HaXML and the libraries in the FFI Addendum use `with' for function names, which would be awkward to change. Now, given that implicit parameters are a - I believe - rarely used extension, can't we just change the keyword to something else and be done with it? We could, but implicit parameters are an eminently useful feature that may well be formalised into a Haskell 98 addendum, or even be included in a future revision of the language. So, it seems worthwhile to spent some thought on how to solve the problem properly. In addition to the keyword problem, `with' doesn't fit very well in with other Haskell binding constructs, which are in prefix form and extend as far to the right as possible (eg, `let', `case', and lambdas). This, for example, raises the questions what let x = e1 in e2 with ?y = e3 might mean. (The exception to prefix form is `where', but it scopes over groups of right-hand sides, not expressions.) Possible Solutions ~~~~~~~~~~~~~~~~~~ [Ugly & easy] The `with' keyword could be renamed to `iwith' or a prefix form could be called `ilet' or `dlet' (the last of which is actually accepted by Hugs as an alternative syntax). [Just use let] Alternatively, it seems reasonable to reuse the existing `let' syntax. So, our above example would read let ?base = 10 in addBase 5 The problem here is that let-bindings are recursive and introduce polymorphic bindings, which doesn't match well with the semantics for implicit parameters. This is aggravated by the ability to mix bindings of implicit parameters with standard variable and function bindings. These problems could be avoided by defining that a let binding either exclusively contains implicit parameter bindings or none at all. Moreover, all implicit parameter bindings are non-recursive and not subject to generalisation during type checking. This is a simple and workable solution, but some people feel that merely having a `?' on the lhs of bindings provides to little visual clue for a semantics that deviates quite strongly from standard `let' bindings. [Add a special identifier] To emphasis the difference in semantics, we may add a special identifier[1] after the let, such as let dynamic ?base = 10 in addBase 5 or let nonrec ?base = 10 in addBase 5 where `nonrec' would have the advantage that it might also be used for explicit value bindings where they are meant to be non-recursive (just like plain `let' in SML). The main disadvantage of this solution is that, in Haskell, some keywords (`let', `case', `where', and `do') trigger the layout rule and now `dynamic' or `nonrec' would have to trigger the layout rule, but *only* when appearing after a `let'. *urgh* [Use a special binding operator] An alternative way to emphasis the non-standard semantics for `let's containing bindings for implicit parameters would be to use a binding operator other than `='; for example, let ?base := 10 in addBase 5 Unfortunately, `:=' is currently a valid infix constructor symbol and making it into a reserved operator is probably as bad as making `with' into a reserved identifier. On the other hand, like the `nonrec' special identifier, the syntax could also be used for explicit value bindings. Are there other, better alternatives for the binding operator? There was also a mention of extending the implicit parameter story to work as recursive bindings, but I don't know any details here. It would certainly strengthen the case for using plain `let'. In Summary ~~~~~~~~~~ We want implicit parameters, but we also want to avoid turning common identifiers into keywords, thus, stealing them from library designers. It seems best to render bindings of implicit parameters as a variant of `let' bindings. The question is, which syntax do we choose for this. The arguments and examples in this message are a summary of mail messages and verbal discussion between Marcin Kowalczyk, John Launchbury, Jeff Lewis, Simon Marlow, Erik Meijer, Sven Panne, Simon Peyton Jones, Alastair Reid, and my humble self. Cheers, Manuel [1] A special identifier is *not* a keyword. It is special only in some contexts (in this case, after a `let'). Everywhere else, it can be used as a normal identifier.