Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/10 22:30 , wren ng thornton wrote: > On 10/29/10 8:33 PM, C. McCann wrote: >> I suggest U+2621. > > I'm not sure I'd've ever recognized a funny 'z' as "caution sign"... :) You'd have to be a TeX / Metafont user to get that one. (The LaTeX book doesn't use that symbol for "caution", so I don't count LaTeX users so much.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzNrlIACgkQIn7hlCsL25VoygCgnohkDoepVXT+SNzOOpJ15r/6 IB4AnA/dI1d6pk2pje3K2LSFGEXoCADE =JyAA -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/10 20:33 , C. McCann wrote: > I suggest U+2621. Did you mean U+2620 SKULL AND CROSSBONES there? - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzNrfoACgkQIn7hlCsL25UTPwCfZIoFnec/y9Hx9BfIqzw6gSr8 ajAAnjycfEoRw7ZbBrplVb3xApb3Cq6J =7No/ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On Fri, Oct 29, 2010 at 10:30 PM, wren ng thornton wrote: >> I suggest U+2621. > > I'm not sure I'd've ever recognized a funny 'z' as "caution sign"... :) Well, I'm operating under the assumption that it's one of these: http://en.wikipedia.org/wiki/Bourbaki_dangerous_bend_symbol I would not be at all surprised at people working on Unicode being familiar with Knuth's use of the symbol. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On 10/29/10 8:33 PM, C. McCann wrote: On Fri, Oct 29, 2010 at 7:54 PM, wren ng thornton wrote: I'm sort of torn on this issue. On the one hand (#) has great potential as an operator, on the other hand I've found that having something like -XMagicHash (or TeX's \makeatletter and \makeatother) can be really helpful when you want to expose some guts but also want to keep folks from using them accidentally. Haskell officially supports unicode in identifiers, right? Why not pick some obscure and little-used symbol and leave the ones that are conveniently placed on standard keyboards for normal use? That's doable, and no less portable than -XMagicHash already is. I suggest U+2621. I'm not sure I'd've ever recognized a funny 'z' as "caution sign"... :) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On Thu, Oct 28, 2010 at 4:42 PM, Ben Millwood wrote: > Personally I think function composition is what Haskell is all about > and it is absolutely essential that the syntax for it be lightweight. > If we think using . as qualification as well as composition is > confusing, I'm much more inclined to say using it as qualification was > a mistake. Agreed. However for function composition I often use ∘ from: http://hackage.haskell.org/packages/archive/base-unicode-symbols/0.2.1.1/doc/html/Data-Function-Unicode.html Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On Fri, Oct 29, 2010 at 7:54 PM, wren ng thornton wrote: > I'm sort of torn on this issue. On the one hand (#) has great potential as > an operator, on the other hand I've found that having something like > -XMagicHash (or TeX's \makeatletter and \makeatother) can be really helpful > when you want to expose some guts but also want to keep folks from using > them accidentally. Haskell officially supports unicode in identifiers, right? Why not pick some obscure and little-used symbol and leave the ones that are conveniently placed on standard keyboards for normal use? I suggest U+2621. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On 10/29/10 11:18 AM, Daniel Peebles wrote: Speaking of MagicHash, is it really necessary to take an operator with "potential" like (#) just to keep primitive symbols separate from the rest? At least from my 2010 Haskell learner perspective, it seems odd to create a whole language extension/lexical change just for that purpose. I'm sort of torn on this issue. On the one hand (#) has great potential as an operator, on the other hand I've found that having something like -XMagicHash (or TeX's \makeatletter and \makeatother) can be really helpful when you want to expose some guts but also want to keep folks from using them accidentally. For example, I use a lot of newtypes to enforce various well-formedness constraints (a la weak-sigma types in dependently typed languages). Thus, I'll often define things like netwype Foo = Foo# Bar and then have a smart constructor (toFoo :: Bar -> Maybe Foo) which verifies whatever invariant. Sometimes we may be forced to export Foo# in case other modules need to look inside in order to create new class instances or the like, but we don't want people using it in general since that'd violate the semantics of the type Foo. And Foo# is much nicer to type than UnsafeFoo[1]. Since it uses the MagicHash syntax, we can ensure that noone will use it blithely since they must first enable an extension to eliminate the syntax error. So you can make some nice lemonade from those lemons, but I'm not sure whether the lemonade is really worth eliminating every other citrus fruit (most of which are quite tasty). [1] In addition to toFoo, I'll often export a smart constructor (unsafeToFoo :: Bar -> Foo) which will still test the invariants but throws an error instead of returning Nothing. The primary use of unsafeToFoo is to get consistent error messages when someone's going to be throwing the Maybe away anyways. Conversely, allowing them to use Foo# gives the same type as unsafeToFoo, but allows circumventing the invariant checking as a performance optimization. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
Speaking of MagicHash, is it really necessary to take an operator with "potential" like (#) just to keep primitive symbols separate from the rest? At least from my 2010 Haskell learner perspective, it seems odd to create a whole language extension/lexical change just for that purpose. On Thu, Oct 28, 2010 at 10:20 PM, wren ng thornton wrote: > On 10/28/10 10:42 AM, Ben Millwood wrote: > >> Here's the wiki page: >> http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot >> >> Personally I think function composition is what Haskell is all about >> and it is absolutely essential that the syntax for it be lightweight. >> If we think using . as qualification as well as composition is >> confusing, I'm much more inclined to say using it as qualification was >> a mistake. >> >> The comment on the wiki page about $ being more common in reality is >> not even close to true for my own code, and I don't think I'm unusual >> in that regard. >> > > Agreed on both counts. Personally, I'd much rather have name qualification > and record selection use a different character than to remove (.) as > composition. And replacing (.) with some abomination like `o` is > unthinkable. > > As for the selector character, I'm partial to # but that would clash with > MagicHash. > > -- > Live well, > ~wren > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On 10/28/10 10:42 AM, Ben Millwood wrote: Here's the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot Personally I think function composition is what Haskell is all about and it is absolutely essential that the syntax for it be lightweight. If we think using . as qualification as well as composition is confusing, I'm much more inclined to say using it as qualification was a mistake. The comment on the wiki page about $ being more common in reality is not even close to true for my own code, and I don't think I'm unusual in that regard. Agreed on both counts. Personally, I'd much rather have name qualification and record selection use a different character than to remove (.) as composition. And replacing (.) with some abomination like `o` is unthinkable. As for the selector character, I'm partial to # but that would clash with MagicHash. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On Thu, Oct 28, 2010 at 11:12 AM, John Smith wrote: > On 28/10/2010 10:15, Alexander Kjeldaas wrote: >> >> Hi haskellers. >> >> Reading through the Haskell Prime suggestions, one that caught my eye is >> the CompositionAsDot issue. >> >> I'm especially thinking of the Pro issue: >> * Paves the way for using . as the selection operator in improved record >> or module systems >> Here's the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot Personally I think function composition is what Haskell is all about and it is absolutely essential that the syntax for it be lightweight. If we think using . as qualification as well as composition is confusing, I'm much more inclined to say using it as qualification was a mistake. The comment on the wiki page about $ being more common in reality is not even close to true for my own code, and I don't think I'm unusual in that regard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Current thinking on CompositionAsDot issue in haskell prime?
On 28/10/2010 10:15, Alexander Kjeldaas wrote: Hi haskellers. Reading through the Haskell Prime suggestions, one that caught my eye is the CompositionAsDot issue. I'm especially thinking of the Pro issue: * Paves the way for using . as the selection operator in improved record or module systems I think I recognize this issue from common lisp. Basically the code becomes verbose because accessor functions usually need to redundantly encode the name of the module or struct in its name. The alternative is to require users to import qualified, and that doesn't deal with the occasional intra-module collision. This is a typical large-software-system issue and it annoys me a little that Haskell seems to have inherited the problems from common lisp. I worry that in large systems, a very conservative coding standard is needed with quite verbose naming conventions as that's the only safe way to avoid these conflicts in a large system while allowing refactoring code etc. What is the current thinking on this issue? Thanks, Alexander TypeDirectedNameResolution would solve the problem you describe, and make Haskell a lot more suitable for real-world development (which is usually large-software-system, or at least must be capable of scaling to one). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
