Re: Function composition and currying
K. Fritz Ruehr writes: : | But Jerzy Karczmarczuk enlightened me as to the full generality possible | along these lines (revealing the whole truth under the influence of at | least one beer, as I recall). Namely, one can define a sequence of | functions (let's use a better notation now, with "c" for composition): | | c1 = (.) -- good old composition | | c2 = (.) . (.)-- my (.<) from above | | c3 = (.) . (.) . (.) | | c4 = (.) . (.) . (.) . (.) | | -- etc. Nice! There's also c0 = ($) which is clearer if you use 'non-pointfree' notation ... c2 f g x y = f (g x y) c1 f g x = f (g x) c0 f g = f g - Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
User-Defined Operators, Re: Function composition and currying
On Wed, 16 Jul 2003, K. Fritz Ruehr wrote: > I think the cutest way to get what you want here is to define a new ^^ > operator as follows: > > (.<) = (.) . (.) Indeed this is cute - but let me add a general comment here: in my code, I don't define any operators at all (only functions). I do think that self-defined operators make a programm less readable. All you get is a short cryptic sequence of non-alphanumeric characters. No-one would want to export functions named f, g, f1, fg, f' etc., so why should this be any better with operators? A similar discussion sometimes surfaces in mathematics - where they have "user-defined" operators all over the place, and especially so since LaTeX. But it's not enough if you can write down something, you also have to talk about it - so a standard test is to imagine you have to read out a formula (in mathematics) or a program text (in Haskell) to someone over the phone. And what's absolutely horrible (IMHO) is to allow the user to declare arbitrary precedence and associativity for his creations. This requires that the source text of the defining module be there, only to parse (i. e., build the syntax tree of) a program that uses it. And - the corresponding definitions in the standard seem rather ad-hoc: we have a funny expression grammar http://haskell.org/onlinereport/exps.html, with arbitrary restrictions (why just ten precendence levels?) I could live with Haskell's predefined operators (arithmetics, comparisons, bool-ops, (:), (++), (!), (!!), (.), ($)). I often use them, and I sometimes overload them (arithmetics, comparisons), but nothing more. (This is the design of Ada - there are operators, you can overload them, but you cannot change their precedence, or add new ones - so you can always parse a program text.) Anyway, this was just for the record (I'm a happy Haskell user, I just ignore some of its features :-), so back to real work now. -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/209 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
On Thursday, 2003-07-17, 09:08, CEST, Johannes Waldmann wrote: > [...] > in my code, I don't define any operators at all (only functions). I do think > that self-defined operators make a programm less readable. All you get is a > A short cryptic sequence of non-alphanumeric characters. I think, that in some situations using operators makes a program more readable. For instance, if we wouldn't have special list syntax, we could still write something like 1 : 2 : 3 : 4 : []. Without operators we would get 1 `cons` 2 `cons` 3 `cons` 4 `cons` [] (uhh, much harder to type) or even cons 1 $ cons 2 $ cons 3 $ cons 4 $ [] or cons 1 (cons 2 (cons 3 (cons 4 []))) which doesn't look much like [1,2,3,4]. I think that similar situations exist with user-defined functions/operators. > No-one would want to export functions named f, g, f1, fg, f' etc., so why > should this be any better with operators? Ok, that's a point I never thought of. > A similar discussion sometimes surfaces in mathematics - where they have > "user-defined" operators all over the place, and especially so since LaTeX. Well, for the most part, LaTeX only provides common operators. One problem, I came across some weeks ago, is that it is *not* possible to define his/her own operators (or, at least, that Lamport's "LaTeX - A Document Preparation System" doesn't tell you how you can define them). > But it's not enough if you can write down something, you also have to talk > about it - so a standard test is to imagine you have to read out a formula > (in mathematics) or a program text (in Haskell) to someone over the phone. Yes, this is a problem. But it can be solved by assigning a "pronounciation" to an operator like it's done in standard mathematics. > And what's absolutely horrible (IMHO) is to allow the user to declare > arbitrary precedence and associativity for his creations. This requires that > the source text of the defining module be there, only to parse (i. e., build > the syntax tree of) a program that uses it. Maybe the infix declarations should have to be separated from the rest of the code? > And - the corresponding definitions in the standard seem rather ad-hoc: we > have a funny expression grammar http://haskell.org/onlinereport/exps.html, > with arbitrary restrictions (why just ten precendence levels?) Yes, something more sophisticated would be nice. > I could live with Haskell's predefined operators (arithmetics, comparisons, > bool-ops, (:), (++), (!), (!!), (.), ($)). I often use them, and I sometimes > overload them (arithmetics, comparisons), but nothing more. (This is the > design of Ada - there are operators, you can overload them, but you cannot > change their precedence, or add new ones - so you can always parse a program > text.) I dislike, having a fixed set of operators with each having a fixed precedence. I would say: "Either no operators at all or a facility for defining operators which is complex enough to allow the definition of the standard operators." One thing of Haskell, I really like, is that only very few things are hard-wired into the compiler/interpreter. > Anyway, this was just for the record (I'm a happy Haskell user, I just > ignore some of its features :-), so back to real work now. Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
On Thursday, 2003-07-17, 16:07, CEST, Robert Ennals wrote:
> > Well, for the most part, LaTeX only provides common operators. One
> > problem, I came across some weeks ago, is that it is *not* possible to
> > define his/her own operators (or, at least, that Lamport's "LaTeX - A
> > Document Preparation System" doesn't tell you how you can define them).
>
> It's actually fairly easy. There are several ways to do it. A simple hacky
> way to do it is the following:
>
>
> * Draw a little picture of your operator in your favorite drawing package.
>
> * Save this picture as an EPS drawing
>
> * define a new command that inserts this eps drawing, possibly scaling it
> appropriately. E.g.
>
> \newcommand{\myop}{\scalebox{0.1}{operators/myop.eps}}
>
> * Then just use \myop like any other operator in math mode.
>
>
> What this hack won't do is automatically change the size of the operator if
> the maths is in a subscript. There is probably an easy way to do this, but
> I haven't worked it out.
>
>
> A more elegant way to do it is to define a new postscript font (not hard if
> you have the correct software) and then define your operator macro to
> insert the relevant character.
Hello,
I think, in both cases you don't define an *operator*. LaTeX probably won't
use the correct spacing around the symbol.
A related problem is that I cannot see a way to define a new "log-like
function" (as Lamport names them), i.e., a function with a name consisting of
several letters which have to be set in upright font with no spaces between
them. Examples are log, min, max, sin, cos and tan.
> [...]
Wolfgang
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
Wolfgang Jeltsch wrote: > A related problem is that I cannot see a way to define a new "log-like > function" (as Lamport names them), i.e., a function with a name consisting of > several letters which have to be set in upright font with no spaces between > them. Examples are log, min, max, sin, cos and tan. Check out the AMS-LaTeX package. I think it has a macro to solve this. It also includes a zillion new symbols/operators. http://www.ams.org/tex/amslatex.html If you have TeTeX installed as your TeX system, then it should be included. -- Matthew Donadio ([EMAIL PROTECTED]) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
Johannes Waldmann wrote: I do think that self-defined operators make a programm less readable. I quite like most combinators from the pretty-printer or parsing libraries! And what's absolutely horrible (IMHO) is to allow the user to declare arbitrary precedence and associativity for his creations. This requires that the source text of the defining module be there, only to parse (i. e., build the syntax tree of) a program that uses it. The parser does not look into imported modules. Refined expressions trees are setup later (before type analysis). And - the corresponding definitions in the standard seem rather ad-hoc: we have a funny expression grammar http://haskell.org/onlinereport/exps.html, with arbitrary restrictions (why just ten precendence levels?) Maybe only the numbering is nonsense, but surely you want to have differently strong binding infix operations in order to write i.e. polynoms without parens. I could live with Haskell's predefined operators (arithmetics, comparisons, bool-ops, (:), (++), (!), (!!), (.), ($)). Why do you outrule other useful libraries (see above). In fact ($) is quite cryptic (for a non-Haskeller). An what should the difference be between (!!) and (!)? (I know it's the type.) In fact. I would like to reuse (sometimes) a predefined operator for another purposes (not easily covered by type class overloading and without hiding or qualifying prelude operators). Example: multiply a scalar with a vector. Without operators, formulae may become really horribly long. I often use them, and I sometimes overload them (arithmetics, comparisons), but nothing more. (This is the design of Ada - there are operators, you can overload them, but you cannot change their precedence, or add new ones - so you can always parse a program text.) Ada has true ad-hoc overloading, though. Anyway, this was just for the record (I'm a happy Haskell user, I just ignore some of its features :-), so back to real work now. I fully agree with these too lines. Christian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Function composition and currying
How about... h a = f . g a or... f $ g 1 2 f :: Int -> Int f x = x*x g :: Int -> Int -> Int g a b = a + b ... But what I really want is a function with signature Int -> Int -> Int. -- Brett Letner Galois Connections, Inc. http://www.galois.com mailto:[EMAIL PROTECTED] phone:(503)626-6616 ext.110 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators, Re: Function composition and currying
On 2003-07-17 at 09:08+0200 Johannes Waldmann wrote: > On Wed, 16 Jul 2003, K. Fritz Ruehr wrote: > > > I think the cutest way to get what you want here is to define a new > ^^ > > operator as follows: > > > > (.<) = (.) . (.) > > Indeed this is cute - but let me add a general comment here: > in my code, I don't define any operators at all (only functions). > I do think that self-defined operators make a programm less readable. While I agree with that, I think that the language needs "user"-defined operators for libraries; it's a matter of defining them rarely and getting them widely accepted. I'm even tempted to suggest that the language ought to restrict their use to gurus. Someone mentioned multiplying by a scalar. I think this is a good application, but what we need is to agree (somehow) on the symbol used. I've used (*.) and (.*), with the dot being on the side the scalar is on (on the grounds that . is a scalar product elsewhere), but without wide agreement I agree that this sort of thing reduces readability, because while I can read these programmes, it's harder for everyone else. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
COORDINATION 2004 - First Call for papers
Please apologize if you receive multiple copies of this message. COORDINATION 2004 Preliminary Call for Papers Sixth International Conference on Coordination Models and Languages 24-27 February 2004 Pisa, Italy http://www.di.unipi.it/Coordination2004 (under construction) === IMPORTANT DATES: Submission of abstract: September 22, 2003 Submission of Papers: September 29, 2003, Notification of Acceptance: November 14, 2003 Camera-Ready Copy: December 4, 2003 CONFERENCE OBJECTIVES The need for increasing programming productivity and rapid development of complex systems provide the pragmatic motivation for the development of coordination/orchestration languages and models. The intellectual excitement associated with such endeavors is rooted in the decades-old desire to leverage off increasingly higher levels of abstractions. Coordination-based methods provide a clean separation between individual software components and their interactions within their overall software organization. Coordination is relevant in design, development, debugging, maintenance, and reuse of all complex concurrent and distributed systems. Specifically, coordination becomes paramount in the context of open systems, systems with mobile entities, and dynamically re-configurable evolving systems. Moreover, coordination models and languages focus on such key issues in Component Based Software Engineering as specification, interaction, and dynamic compositions. More recently, market trends brought on by the commercialization of the World Wide Web, have fuelled a new level of interest in coordination-based approaches in industry. Applications like BizTalk, standards like the web services' WS-* family, and contending coordination standards like BEPL4WS and WSCI, are all examples of this phenomenon. This interest is opening up new opportunities both to apply coordination-based techniques to a broad class of applications as well as to grapple with potentially new kinds of requirements coming from internet-scale scenarios. PREVIOUS EDITIONS The previous conferences in this series took place in Cesena (Italy), Berlin (Germany), Amsterdam (Netherlands), and Limasol (Cyprus), York (England). Building on the success of these events, this conference provides a forum for the growing community of researchers interested in models, languages, and implementation techniques for coordination and component-based software, as well as applications that utilize them. At http://music.dsi.unifi.it/coordination/ more details are available. TOPICS OF INTEREST (include, but are not limited to): * Theoretical models and foundations for coordination * Coordination middlewares * Specification, refinement, and analysis of software architectures * Architectural, and interface definition languages * Agent-oriented languages and models * Dynamic software architectures * Component Programming * Web Services * Coordination in Peer to Peer and Grid Computing * Tools and environments for the development of coordinated applications * Industrial relevance of coordination and software architectures * Domain-specific software coordination models and case studies. PROCEEDINGS The conference proceedings will be published by Springer, in the Lecture Notes in Computer Science series. The proceedings of the previous editions are appeared in the LNCS series: volumes 1061, 1282 and 1594, 1906, 2315. SUBMISSIONS Electronic submission will be used using conference web site: http://www.di.unipi.it/Coordination2004 (see also http://music.dsi.unifi.it/coordination). Authors are invited to submit electronically a plain ASCII cover page containing the paper title, authors' names, contact author and full address (including e-mail and fax) together with an abstract of up to 100 words (no later than 22 September 2003). Full papers (in English, up to 6000 words) should be submitted in PostScript or PDF no later than 29 September 2003. Authors are invited to use the llncs style. A link will be found the conference web page. Simultaneous submission to other conferences with proceedings or journals is not allowed. LOCATION The conference will be held in Pisa, Dipartimento di Informatica, Via F.Buonarroti 2. Program co-chairs Rocco De Nicola (Univ. Firenze) Greg Meredith (Microsoft) Organizing Chair Gianluigi Ferrari (Univ. Pisa) Program Committee: Roberto Amadio, Univ. Marseilles - France Farhad Arbab, CWI - The Netherlands Marcelo Bonsangue, Leiden University - The Netherlands Paolo Ciancarini, Univ. Bologna Italy José Fiadeiro, Univ. Leicester - United Kingdom C
Re: User-Defined Operators
> Well, for the most part, LaTeX only provides common operators. One problem, I
> came across some weeks ago, is that it is *not* possible to define his/her own
> operators (or, at least, that Lamport's "LaTeX - A Document Preparation
> System" doesn't tell you how you can define them).
It's actually fairly easy. There are several ways to do it. A simple hacky way
to do it is the following:
* Draw a little picture of your operator in your favorite drawing package.
* Save this picture as an EPS drawing
* define a new command that inserts this eps drawing, possibly scaling it
appropriately. E.g.
\newcommand{\myop}{\scalebox{0.1}{operators/myop.eps}}
* Then just use \myop like any other operator in math mode.
What this hack won't do is automatically change the size of the operator if
the maths is in a subscript. There is probably an easy way to do this, but I
haven't worked it out.
A more elegant way to do it is to define a new postscript font (not hard if
you have the correct software) and then define your operator macro to insert
the relevant character.
Hope this is useful to someone.
-Rob
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
Wolfgang Jeltsch wrote:
On Thursday, 2003-07-17, 09:08, CEST, Johannes Waldmann wrote:
A similar discussion sometimes surfaces in mathematics - where they have
"user-defined" operators all over the place, and especially so since LaTeX.
Well, for the most part, LaTeX only provides common operators. One problem, I
came across some weeks ago, is that it is *not* possible to define his/her own
operators (or, at least, that Lamport's "LaTeX - A Document Preparation
System" doesn't tell you how you can define them).
I am sorry, but it is simply a countertruth. You can define \mathop with all
the \limits, \nolimits etc. properties. You have \mathchardef's etc. How do you
think the AMS package has been constructed? Everything is written in a standard
way, your liberty to create the most disgusting operators is unlimited. Some
Haskell-related papers dealing with lenses, bananas and barbed-wires exploited
already this possibility.
/// in another posting,commenting the "graphical" ways to make operator-like
icons, from posting by Robert Ennals///
I think, in both cases you don't define an *operator*. LaTeX probably won't
use the correct spacing around the symbol.
A related problem is that I cannot see a way to define a new "log-like
function" (as Lamport names them), i.e., a function with a name consisting of
several letters which have to be set in upright font with no spaces between
them. Examples are log, min, max, sin, cos and tan.
What's wrong with $ ... \mathrm{brumble}(2\cdot x) ...$ ?
How do you think, the existing "standard ones" have been manufactured?
\def \arctan {\mathop {\rm Arctan}}
You can also put \hbox'es inside a math environment, which will prevent the
automatic choice of \mathitalic.
Read something about families, about \mathchardef, and about such options
as \displaystyle \scriptstyle, etc., in order to choose automatically the
correct size of the math. fonts. Also read something about big operators
useful to define objects like sum, product, etc.
Cheer up. YOU CAN DO EVERYTHING YOU WISH, and much more.
Jerzy Karczmarczuk
Jerzy Karczmarczuk
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Announce: Haskell All-In-One
Hi All (again), Sorry for the multiple posting, but I received serveral emails about this, so I thought I'd reply to the whole list: (1) There was temporarily a bug on my web page with the links which prevented you from downloading the program. This is fixed now (sorry!). (2) More importantly, there was a last minute added bug which prevented HAllInOne from running on recursive modules (in fact, this would cause it to infinite loop!). This bug is now fixed and it should correctly handle mutually recursive modules. It has been tested on two test cases, but if someone wants to stress test this and submit bugs, that would be great. A new version is up on the web page now. - Hal -- Hal Daume III | [EMAIL PROTECTED] "Arrest this man, he talks in maths." | www.isi.edu/~hdaume On Sun, 13 Jul 2003, Hal Daume III wrote: > Hi All, > > There have been several requests for such a program in the past, so I > figured I'd finally break down and write it. > > Haskell All-In-One is a Haskell utility which will take a program > implemented in multiple modules and convert it to a single module. > > It implements all of Haskell 98 (sorry, your -fglasgow-exts programs won't > parse with the Language.Haskell.Parser parser so we can't deal with them, > yet) as well as the hierarchical libraries. It can also correctly deal > with literate Haskell scripts (provided you have GHCs unlit software > available) and programs which need to be run through the c-pre-processor. > > The program, together with a bunch of documentation, is available at: > > http://www.isi.edu/~hdaume/HAllInOne/ > > There is one known bug (listed on the web page), but there are likely > other unknown bugs. > > I would have liked to have run it on itself as a proof of concept, but > unfortunatly it uses the GMap library, which require extensions and thus > it cannot parse correctly. However, it's been tested against the GHC > module regression suite and performs (almost) perfectly. > > I would appreciate bug reports, if you find any problems. > > On the TODO list currently are: > > - simplify and comment the source better > - fix the known bug > > It requires GHC6.0 to compile "out of the box" with -fglasgow-exts and > -fallow-undecidable-instances. It can compile with GHC 5.04.3, but will > also need "-package haskell-src" and you will need to modify the code such > that System.IO no longer imports 'bracket' and uncomment the 'cast' > function in the GMap library. > > - Hal > > -- > Hal Daume III | [EMAIL PROTECTED] > "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Function composition and currying
Tom Pledger wrote: > K. Fritz Ruehr writes: > : > | But Jerzy Karczmarczuk enlightened me as to the full generality possible > | along these lines (revealing the whole truth under the influence of at > | least one beer, as I recall). Namely, one can define a sequence of > | functions (let's use a better notation now, with "c" for composition): > | > | c1 = (.) -- good old composition > | c2 = (.) . (.)-- my (.<) from above > | c3 = (.) . (.) . (.) > | c4 = (.) . (.) . (.) . (.) > | -- etc. > > Nice! > > There's also > > c0 = ($) > > which is clearer if you use 'non-pointfree' notation > > ... > c2 f g x y = f (g x y) > c1 f g x = f (g x) > c0 f g = f g > > - Tom Note also that chains of these operators can be used in a somewhat readable way. For example, suppose we have: f1 :: Int -> Int f2 :: Int -> Int -> Int f3 :: Int -> Int -> Int -> Int f :: Int -> Int -> Int -> Int -> Int f1 x = -x f2 x y= x - y f3 x y z = x * (y - z) f a b c d = f2 (f1 (f3 a b c)) d We can define `f` in a point-free style: f = f2 `c1` f1 `c3` f3 Each function in the composition, from innermost (rightmost) to outermost (leftmost), takes the intermediate result so far (or, for the innermost function, the first argument) plus zero or more additional arguments from those that remain, as determined by the composition operator to its left. Note that the composition operators need to be left-associative (as they are by default) for this to work. -- Dean ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
Wolfgang writes: > I think, in both cases you don't define an *operator*. LaTeX probably won't > use the correct spacing around the symbol. > > A related problem is that I cannot see a way to define a new "log-like > function" (as Lamport names them), i.e., a function with a name consisting of > several letters which have to be set in upright font with no spaces between > them. Examples are log, min, max, sin, cos and tan. This is off-topic, but I think you want to look at the \mathop, \mathbin, \mathrel, \mathord, etc commands. These declare anything as the appropriate math category, and so give the right spacing. Perhaps this should move to the Haskell Cafe? --KW 8-) -- Keith Wansbrough <[EMAIL PROTECTED]> http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Function composition and currying
What I nice application for a multi-variadic compositional operator mcomp [1]. Only one operator does the trick, for functions of arbitrary number of curried arguments. And I really mean the arbitrary number of arguments, in both functions under composition. Given > f1 x = x*x > g2 a b = a + b > g3 a b c = a + b + c we can easily compose g2 with f1 *Main> (g2 `mcomp` f1) (1::Int) (2::Int) 9 and g3 with f1 *Main> (g3 `mcomp` f1) (1::Int) (2::Int) (3::Int) 36 But we can just as easily compose f1 with g2: *Main> (f1 `mcomp` g2) (2::Int) (3::Int) 7 (that is, square the first number and add the second) and f1 with g3 *Main> (f1 `mcomp` g3) (2::Int) (3::Int) (4::Int) 11 What's more, we can even compose g2 with g3 or g3 with g2! *Main> (g3 `mcomp` g2) (1::Int) (2::Int) (3::Int) (4::Int) 10 *Main> (g2 `mcomp` g3) (1::Int) (2::Int) (3::Int) (4::Int) 10 The Web page referenced below shows an advanced application of mcomp, to point-free programming (categorical products). [1] http://pobox.com/~oleg/ftp/Haskell/types.html The following code, excerpted from [1], was used for the above examples. -fglasgow-exts are needed. > class MCompose f2 cp gresult result | f2 cp gresult -> result, f2->cp > where > mcomp:: (f1->f2) -> (cp->gresult) -> (f1 -> result) > > -- Class instances. Please keep in mind that cp must be a non-functional type > -- and f2 and cp must be the same. These instances enumerate the base cases. > > instance MCompose (Maybe b) (Maybe b) c c where > --mcomp f::(a->(Maybe b)) g::((Maybe b)->c) :: a->c > mcomp f g = g . f > > instance MCompose [b] [b] c c where > --mcomp f::(a->[b]) g::([b]->c) :: a->c > mcomp f g = g . f > > instance MCompose Int Int c c where > --mcomp f::(a->Int) g::(Int->c) :: a->c > mcomp f g = g . f > > instance MCompose Char Char c c where > --mcomp f::(a->Char) g::(Char->c) :: a->c > mcomp f g = g . f > > instance MCompose (a,b) (a,b) c c where > mcomp f g = g . f > > -- Induction case > instance (MCompose f2 cp gresult result) => > MCompose (f1->f2) cp gresult (f1->result) where > mcomp f g = \a -> mcomp (f a) g > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators
G'day all. On Thu, Jul 17, 2003 at 05:21:47PM +0200, Christian Maeder wrote: > Why do you outrule other useful libraries (see above). In fact ($) is > quite cryptic (for a non-Haskeller). Actually this gives me a perfect opportunity to rant a bit. :-) ($) is a wart, even for a Haskeller. It has the correct meaning and the correct precedence, but it has the wrong associativity. "Normal" application is left-associative. There's no reason why ($) shouldn't be either. Of course, sometimes you want right-associative apply, but there's already a simple way to do this. If you want to write: f (g (h (i x))) you can use this: f . g . h . i $ x But there is no way to write this parenthesis-free: f (g x) (h y) (i z) Now it's arguable that this is clearer with the parentheses, and I would agree with that. However, consider the situation with ($!). When you use strict-apply, you intend that one or more of the arguments to some function is/are to be strictly evaluated. Making ($!) right-associative only gives you _exactly_ one, and it's always the rightmost one, which gives it a 1-in-n chance of being right for a function of n arguments. In the above example, for instance: f (g x) (h y) (i z) Suppose you want (h y) to be strictly evaluated. I argue that some variation on this: f (g x) $! (h y) $ (i z) even with the parentheses is far more readable than the current alternatives. While it makes sense that ($!) should have the same associativity as ($), I can't for the life of me figure out why ($) is right-associative. There's probably a terribly good reason. Does anyone know what it is? Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: User-Defined Operators, Re: Function composition and currying
G'day all. On Thu, Jul 17, 2003 at 04:46:13PM +0100, Jon Fairbairn wrote: > Someone mentioned multiplying by a scalar. I think this is a > good application, but what we need is to agree (somehow) on > the symbol used. I've used (*.) and (.*), with the dot being > on the side the scalar is on (on the grounds that . is a > scalar product elsewhere), but without wide agreement I > agree that this sort of thing reduces readability, because > while I can read these programmes, it's harder for everyone > else. Yuck. :-) I've run into the same problem with affine algebra, which has two types, the Point and the Vector, where a Vector is the difference between two Points: Vector + Vector = Vector Vector + Point = Point Point + Vector = Point Point + Point is an error Vector - Vector = Vector Point - Vector = Point Vector - Point = Point -- (this rule is a bit controversial) Point - Point = Vector It's not obvious what to call the operators here. One solution might be to relax the rules about how the types of operators are resolved. At the moment, you can define function names from different modules and all you need to do is qualify them when you use them. It's a little odd that you can't do something similar with operators, though no succinct syntax leaps to mind. Of course you could always allow overloading _without_ requiring module qualification (unless the overloading can't be resolved using type information). It'd make type checking NP-hard, but I seem to recall that it's already more complex than that. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
