Re: Reverse composition
On Fri, 8 Oct 1999 [EMAIL PROTECTED] wrote: > Some time ago there was a discussion about what to call reverse > composition (I can't find it in the archive - needs a search option?) > > Just now I thought of .~ from . for composition and ~ (tilde, but > commonly called twiddle) for twiddling the order about. > > Maybe we could adopt that as normal usage? Interesting however I like (.| and $|) since it represents a unix pipe. The ~ tilde is generally used for not. My guess is that it is not in the standard becuase we can't agree on which one is best. --- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: Reverse composition
On Fri, 8 Oct 1999, Hamilton Richards Jr. wrote:
>
> At 1:01 PM -0500 10/8/1999, [EMAIL PROTECTED] wrote:
> >
> >Some time ago there was a discussion about what to call reverse
> >composition (I can't find it in the archive - needs a search option?)
> >
> >Just now I thought of .~ from . for composition and ~ (tilde, but
> >commonly called twiddle) for twiddling the order about.
> >
> >Maybe we could adopt that as normal usage?
>
> Assuming that "reverse composition" means
>
> f .~ g = g . f
>
> I kind of like >.> ("forward composition"), which I first saw in Simon
> Thompson's book.
Discussion of what glyph(s) to use for the reverse composition operator
just reminded me of the fact that you might really want to think up
a new "forward" composition operator, as well. Twice in the past few
months I've seen the suggestion that "." really should be used for
what the vast majority of programming languages already use it for,
namely, a part of the record syntax. If you look at the code
examples in the "Lightweight extensible records" paper:
http://research.microsoft.com/Users/simonpj/#records
or those in the O'Haskell work:
http://www.cs.chalmers.se/~nordland/ohaskell/index.html
I think you might see the point. (No pun back there, I promise...) I
understand where using "." to mean composition came from, and I know that
it's a long-standing tradition in at least the Haskell community, but I
don't think the visual correspondence of . to the typographic glyph
"raised open circle" is so close that you'd really like to explain why
you diverged from current usage so much as to choose "." to mean
"composition". Especially since to "reverse" it, you end up using >.>
> It makes pipelines easy to read:
>
> f >.> g >.> h >.> ...
How about:
f |> g |> h |> ...
for the above, and
g <| f
for "normal" composition? (Or does this step on some other notation out
there already?) You save a character, get a nice, reversible glyph, and
get to make a different point somewhere else.
jking
Re: Reverse composition
[EMAIL PROTECTED] wrote: > Some time ago there was a discussion about what to call reverse > composition (I can't find it in the archive - needs a search option?) > > Just now I thought of .~ from . for composition and ~ (tilde, but > commonly called twiddle) for twiddling the order about. > > Maybe we could adopt that as normal usage? I've also seen .| and |. used for this purpose (by analogy with Unix pipes.) John Hughes' Arrow library spells it ">>>", but generalized to arbitrary arrows. At the (->) instance it's the same as "flip (.)". Along the same lines, are there accepted conventional infix operators for the functions with types: (a0 -> b0) -> (a1 -> b1) -> (a0,a1) -> (b0,b1) (a -> b0) -> (a -> b1) -> a -> (b0,b1)) (a0 -> b0) -> (a1 -> b1) -> Either a0 a1 -> Either b0 b1 (a0 -> b) -> (a1 -> b) -> Either a0 a1 -> b (the last one is called "either" in the standard Prelude). I personally like: (f <*> g) (x,y) = (f x, g y) (f <&> g) x = (f x, g x) (f <+> g) (Left x) = Left (f x) (f <+> g) (Right y) = Right (g y) (f <|> g) (Left x) = f x (f <|> g) (Right y) = g y Hughes spells these ***, &&&, +++, and ||| (again generalized to arbitrary arrows), but those don't look as nice typeset IMHO. I also like: apfst :: (a -> c) -> (a,b) -> (c,b) apsnd :: (b -> c) -> (a,b) -> (a,c) apl :: (a -> c) -> Either a b -> Either c b apr :: (b -> c) -> Either a b -> Either a c These are called "first", "second", "left", and "right" in the Arrow library. --Joe English [EMAIL PROTECTED]
Re: Reverse composition
Fri, 8 Oct 1999 19:01:07 +0100 (BST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> pisze:
> Some time ago there was a discussion about what to call reverse
> composition (I can't find it in the archive - needs a search option?)
>
> Just now I thought of .~ from . for composition and ~ (tilde,
> but commonly called twiddle) for twiddling the order about.
What about doing the analogous thing for the reverse application
as well?
They could also be <. and <$
But probably it is sufficient to use `(.d) (.c) (.b) a' as `a.b.c.d',
and `($obj) method arg1 arg2 arg3' for those wanting OO-like order.
--
__("+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
Re: Reverse composition
On 8 Oct, Jonathan King wrote: > I think you might see the point. (No pun back there, I promise...) I > understand where using "." to mean composition came from, and I know that > it's a long-standing tradition in at least the Haskell community, but I > don't think the visual correspondence of . to the typographic glyph > "raised open circle" is so close that you'd really like to explain why > you diverged from current usage so much as to choose "." to mean > "composition". Back in the early Haskell discussions we argued about various options, but I think Richard Bird and Phil Wadler were insistent that, because function composition is so important for functional programming, the symbol used should be something with very low visual weight. Nowadays we might actually think of using ° (which would suggest º or § for the reverse ;-). Not to mention using · for composition... Even though I disagreed with the use of . in the original case, I was persuaded, and still think it ought to be a single character. Unfortunately most of the other good candidates have been used elsewhere. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Reverse composition
At 1:01 PM -0500 10/8/1999, [EMAIL PROTECTED] wrote:
>Some time ago there was a discussion about what to call reverse
>composition (I can't find it in the archive - needs a search option?)
>
>Just now I thought of .~ from . for composition and ~ (tilde, but
>commonly called twiddle) for twiddling the order about.
>
>Maybe we could adopt that as normal usage?
Assuming that "reverse composition" means
f .~ g = g . f
I kind of like >.> ("forward composition"), which I first saw in Simon
Thompson's book.
It makes pipelines easy to read:
f >.> g >.> h >.> ...
--Ham
--
Hamilton Richards Jr.Department of Computer Sciences
Senior Lecturer Mail Code C0500
512-471-9525 The University of Texas at Austin
SHC 434 Austin, Texas 78712-1188
[EMAIL PROTECTED]
--
Re: Reverse composition
Re: Syntax ([EMAIL PROTECTED]) wrote: Even though I disagreed with the use of . in the original case, I was persuaded, and still think it ought to be a single character. Unfortunately most of the other good candidates have been used elsewhere. That's right. Limited characters, and none of them look like mathematical symbols. But we do have bitmapped displays, lots of fonts, graphical applications, etc. Perhaps augmenting JH/SPJ's pretty printer to generate LaTeX or PostScript with real symbols would be a good first step. Augmenting the emacs modes to use other symbols would be another. Or just biting the big bullet and making a customized editor. For each of these users could supply a list of translations, e.g., [ x^2 | x <- [1..10] ] would become real LaTeX with a superscripted 2 and <- would be a real set element symbol. Then we could all have few emails to read about squeezing bitmaps into a fixed ASCII character set. On that note, I looked at the Wiki site, and I didn't think it would be as good as a mailing list for the kind of discussion that people seem to want to have but not to listen to. procmail and Gnus in emacs make it pretty easy to turn a mailing list into a newsgroup locally, for those who like newsgroups, and for those who want immediate relief. I vote for an alternate mailing list. Any of the proposals are fine. Comp.lang.haskell would also be fine. -- Clifford Beshers Computer Graphics and User Interfaces Lab [EMAIL PROTECTED] Department of Computer Science http://www.cs.columbia.edu/~beshersColumbia University
RE: Reverse composition
On Saturday, 9 October 1999 12:00, Clifford Beshers [SMTP:[EMAIL PROTECTED]] wrote: > > But we do have bitmapped displays, lots of fonts, graphical > applications, etc. Perhaps augmenting JH/SPJ's pretty printer to > generate LaTeX or PostScript with real symbols would be a good first > step. Augmenting the emacs modes to use other symbols would be > another. Or just biting the big bullet and making a customized > editor. > > For each of these users could supply a list of translations, e.g., > >[ x^2 | x <- [1..10] ] > > would become real LaTeX with a superscripted 2 and <- would be a real > set element symbol. > Be careful. '<-' is two symbols. Replacing it by one symbol can change the semantics of a program by affecting layout. You can't guarantee that a prettyprinted program will still be the same program. If the supply of suitable Ascii symbols seems inadequate, remember that Haskell uses Unicode. There is no reason to limit symbols to those in the Ascii set. --brian
Re: Reverse composition
On 8 Oct, Joe English wrote: > [I wrote]: > > Just now I thought of .~ from . for composition and ~ (tilde, but > > commonly called twiddle) for twiddling the order about. > I've also seen .| and |. used for this purpose (by > analogy with Unix pipes.) > John Hughes' Arrow library spells it ">>>", Oh well, I thought it might be cute enough to solve the argument, but obviously not... > Along the same lines, are there accepted conventional infix operators > for the functions with types: > > (a0 -> b0) -> (a1 -> b1) -> (a0,a1) -> (b0,b1) > (a -> b0) -> (a -> b1) -> a -> (b0,b1)) > > (a0 -> b0) -> (a1 -> b1) -> Either a0 a1 -> Either b0 b1 > (a0 -> b) -> (a1 -> b) -> Either a0 a1 -> b > > (the last one is called "either" in the standard Prelude). These were on my list to think of names as well. In ponder I had ` (like a raised comma) and >< (product of functions). > I personally like: > > (f <*> g) (x,y) = (f x, g y) > (f <&> g) x = (f x, g x) > (f <+> g) (Left x) = Left (f x) > (f <+> g) (Right y) = Right (g y) > (f <|> g) (Left x) = f x > (f <|> g) (Right y) = g y I'd go along with those -- if for no other reason than you being first to suggest them, and wishing for less argument. They look OK too. -- Jón Fairbairn [EMAIL PROTECTED] 18 Kimberley Road[EMAIL PROTECTED] Cambridge CB4 1HH +44 1223 570179 (pm only, please)
Re: Reverse composition
Jonathan King writes: > How about: > > f |> g |> h |> ... > > for [reverse composition], and > > g <| f > > for "normal" composition? I like this because it follows the easy-to-remember rule "Use symmetric glyphs for commutative operations and asymmetric glyphs for non-commutative operations. Reflect glyphs for flipped operations." which I would suggest as a general guideline. (Unfortunately I don't know whom to credit for this rule. Might be someone working on visual programming.) I understand the desire for a lightweight glyph for function composition and also the desire for something similar to the usual mathematical notation. But in this case I find reflected glyphs for forward and backward composition far more appealing. (I wouldn't suggest replacing "-" by an asymmetric glyph though.) Similarly, I would prefer a pair of reflected symbols for normal and reversed function application, e.g., <$ and $>. (Yes, these are not 100% reflected, but almost.) Heribert.
Re: Reverse composition
On Fri, 8 Oct 1999, Joe English wrote: > Along the same lines, are there accepted conventional infix operators > for the functions with types: > > (a0 -> b0) -> (a1 -> b1) -> (a0,a1) -> (b0,b1) > (a -> b0) -> (a -> b1) -> a -> (b0,b1)) > > (a0 -> b0) -> (a1 -> b1) -> Either a0 a1 -> Either b0 b1 > (a0 -> b) -> (a1 -> b) -> Either a0 a1 -> b > > (the last one is called "either" in the standard Prelude). > > I personally like: > > (f <*> g) (x,y) = (f x, g y) > (f <&> g) x = (f x, g x) > (f <+> g) (Left x) = Left (f x) > (f <+> g) (Right y) = Right (g y) > (f <|> g) (Left x) = f x > (f <|> g) (Right y) = g y > I personally use $*$ (application on both sides of product), /\ (split) and dually $+$ and \/ (for join). The split and join notations correspond quite nicely to the categorical notation. The symbols <*> and <|> are used in the parsing combinator library I use quite heavily (the Utrecht version). And I'm sure everybody has a pet choice of operator-names and libraries, so I think this debate could be endless. Just looking through the standard hugs-libraries shows up that <+> and $+$ both are used in John Hughes's and SPJ's pretty-printing library... Cheers, Jan de Wit
Unicode (Re: Reverse composition)
Sat, 9 Oct 1999 12:42:20 +1300, Brian Boutel <[EMAIL PROTECTED]> pisze:
> Be careful. '<-' is two symbols. Replacing it by one symbol can change the
> semantics of a program by affecting layout.
No, because only the indent before the first non-whitespace character
in a line matters. Haskell programs can be typeset even in proportional
font as long as indents have correct relationships between their
lengths.
> If the supply of suitable Ascii symbols seems inadequate, remember
> that Haskell uses Unicode. There is no reason to limit symbols to
> those in the Ascii set.
Yes. Unfortunately under Linux (and probably many other systems)
it is not easy to use Unicode yet, because of lack of text editors
and only partial support from the system (e.g. locale is going to
support UTF-8 in the near future, ncurses does not support UTF-8).
But when Unicode finally comes... How should Haskell's textfile IO
work? And FFI? I'm sure most people will want to use not only Unicode
and I'm afraid many people would treat Haskell as broken when it does
not output non-UTF8 8bit characters in source strings without a change.
I think that the minimum, acceptable and on the other hand reasonably
implementable, is the ability to treat source as ISO-8859-1 or UTF-8,
and treat outside world as ISO-8859-1 or UTF-8, in both places as
chosen with some magical switches. ISO-8859-1 would emulate other 8bit
encodings by transparently passing characters 0..255 through IO and
FFI. And future charset conversion functions will probably represent
8bit encodings as Unicode characters 0..255, even though they "really"
are ISO-8859-1.
Haskell standard speaks nothing about UTF-8, but it's about the only
sensible way of exchange between internal Unicode and external 8bit
streams, and AFAIK it will be / is used in many systems as external
representation.
In a few months I will probably want to use Unicode in Haskell and
will have to temporarily use `type UChar = Int'.
--
__("+++$ UL++>$ P+++ L++>$ E-
^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
Re: Unicode (Re: Reverse composition)
Marcin 'Qrczak' Kowalczyk wrote: > Sat, 9 Oct 1999 12:42:20 +1300, Brian Boutel <[EMAIL PROTECTED]> pisze: > > > Be careful. '<-' is two symbols. Replacing it by one symbol can change the > > semantics of a program by affecting layout. > > No, because only the indent before the first non-whitespace character > in a line matters. Haskell programs can be typeset even in proportional > font as long as indents have correct relationships between their > lengths. You must be using a different Haskell than I am. :-) Consider these two fragments: a = x + y where x = 1 y = 1 vs. a = x ++ y where x = 1 y = 1 They have very different syntactical meaning. > > If the supply of suitable Ascii symbols seems inadequate, remember > > that Haskell uses Unicode. There is no reason to limit symbols to > > those in the Ascii set. > > Yes. Unfortunately under Linux (and probably many other systems) > it is not easy to use Unicode yet, because of lack of text editors > and only partial support from the system (e.g. locale is going to > support UTF-8 in the near future, ncurses does not support UTF-8). It's not hard to find a text editor, use w.g. wily. It's widely available. It can be hard to find support for your favourite editor though. > But when Unicode finally comes... How should Haskell's textfile IO > work? And FFI? I'm sure most people will want to use not only Unicode > and I'm afraid many people would treat Haskell as broken when it does > not output non-UTF8 8bit characters in source strings without a change. These are good questions, and we need to start using Unicode to iron out any wrinkles that are left in Haskell. > Haskell standard speaks nothing about UTF-8, but it's about the only > sensible way of exchange between internal Unicode and external 8bit > streams, and AFAIK it will be / is used in many systems as external > representation. Well, some Haskell implementations come with UTF-8 conversion functions. -- -- Lennart
Re: Unicode (Re: Reverse composition)
Marcin 'Qrczak' Kowalczyk wrote: [snip] > But when Unicode finally comes... How should Haskell's textfile IO > work? I don't think the current standard functions for textfile IO would have too many problems. You can do hSeek in Haskell, but "The offset is given in terms of 8-bit bytes" (library standard section 11.5.2). So if the file is UTF8-encoded the offset may be illegal (leading to a possible IO exception now or later) but at least the run-time system can find it.
Unicode (was RE: Reverse composition)
Brian Boutel writes: > [...] > > If the supply of suitable Ascii symbols seems inadequate, remember > that Haskell uses Unicode. There is no reason to limit symbols to > those in the Ascii set. While we're on the subject, I suggest Unicode as a Hugs/GHC wish list item. In particular, I'd like to use the familiar symbols for union, intersection, and subset, without resorting to Ascii art, please. Regards, Tom
Re: Unicode (Re: Reverse composition)
Lennart Augustsson wrote: > It's not hard to find a text editor, use w.g. wily. It's widely available. But it is hard to use some nonstandard (i.e. neither vi nor emacs) editor just for one special kind of source code - it means to lose all the keybindings, highlight settings, 100-lines-of-definition-macros etc. which are usually the result of many years of work and ergonomical optimization. In particular, the section "Drawbacks and problems" of http://www.cs.su.oz.au/~gary/wily/intro.html says that wily is not for me :-) I'd prefer to keep the language itself in ASCII (remember APL died for doing otherwise) and have it support whatever character sets only as data. (One might allow alternative non-ASCII characters for people who have them, similar to `ä´ as a special code which behaves (more or less) equivalent to `\"a´ in LaTeX). In addition, leaving ASCII would break on DOS and Win3.x - it is not probable that Bill Gates will go back and create UTF libraries for them. Other not-very-recent systems might break as well. Ralf
Idiomatic Haskell extension library (Re: Reverse composition)
On 9 Oct, Heribert Schuetz wrote: [(f <| g) x = f (g x); (f |> g) x = g (f x)] >"Use symmetric glyphs for commutative operations and asymmetric glyphs >for non-commutative operations. Reflect glyphs for flipped operations." That would make me happy. > which I would suggest as a general guideline. and I'd go along with that. > Similarly, I would prefer a pair of reflected symbols for normal and > reversed function application, e.g., <$ and $>. (Yes, these are not 100% > reflected, but almost.) and that. For the record, my taste isn't particularly bothered by multi-character symbols; what swayed me in the past was the argument that it was a problem for other folk. * * * Anyway -- I'd like to suggest that we put a library containing definitions of simple operators of general utility somewhere readily accessible. The precise choice of name for operator doesn't matter (though I think a certain amount of discussion is worthwhile). What matters is that for common functions such as the ones we have been discussing the Haskell community should in general use the same names. I'd include composition, function products (as in Joe English's message) and operations on boolean predicates: > (f &&& g) x = f x && g x > (f ||| g) x = f x || g x > notF f x = not (f x) (I'm not wedded to those names.) Where do we put it? -- Jón Fairbairn [EMAIL PROTECTED]
Re: Idiomatic Haskell extension library (Re: Reverse composition)
On Sat, Oct 09, 1999 at 04:52:20PM +0100, [EMAIL PROTECTED] wrote: > I'd include composition, function products (as in Joe English's > message) and operations on boolean predicates: >> (f &&& g) x = f x && g x >> (f ||| g) x = f x || g x >> notF f x = not (f x) One way to get around this would be to make a class Boolean (or, better yet, Lattice) with not too many constraints and then have something on the order of module Lattice where -- it's important that there isn't an Eq a => Lattice a constraint -- because functions aren't of observable type; unless you want to -- define functions as a trivial instance of Eq, like I had to for -- arithmetic operations class Lattice a where (&&&), (|||):: a -> a -> a instance Lattice Bool where (&&&) = (&&) (|||) = (||) instance Lattice b => Lattice (a->b) where f &&& g = \x -> (f x) &&& (g x) f ||| g = \x -> (f x) ||| (g x) -- the end of the code and this would allow things like let f True = False ; f False = True ; g _ = False in (f ||| g) False and let f True = False ; f False = True ; g _ = False in (f &&& g) True to be interpreted naturally. There is no class corresponding to && and || in the Prelude, which is why I had to do it this way. Bill
