home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!news.u.washington.edu!usenet.coe.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!allegra!alice!ark
- From: ark@alice.att.com (Andrew Koenig)
- Newsgroups: comp.lang.functional
- Subject: Re: pairs vs. triples
- Message-ID: <23577@alice.att.com>
- Date: 28 Aug 92 15:24:46 GMT
- References: <1992Aug26.141437.8465@swift.cs.tcd.ie>
- Reply-To: ark@alice.UUCP ()
- Organization: AT&T Bell Laboratories, Murray Hill NJ
- Lines: 24
-
- In article <1992Aug26.141437.8465@swift.cs.tcd.ie> butrfeld@swift.cs.tcd.ie writes:
-
- > In a language called Sticks&Stones, based loosely on ML, that I have
- > used, the following equality always held:
-
- > (a,(b,c)) = (a,b,c)
-
- > In other words a triple is simply a pair whose second item is a pair.
- > Note that ((a,b),c) is not a triple.
-
- It sounds like that language didn't allow triples at all, only pairs.
- It's certainly possible to do that, but that would certainly be less
- convenient in other ways.
-
- For example, in ML a pair is a special case of a more general record
- type that consists of name-value pairs known and checked at compile
- time. A pair is just a record whose components are named 1 and 2;
- a triple is a record with components named 1, 2, and 3, and so on.
- I don't see how to allow pairs and not triples with that kind of
- unified design, and that unification is truly elegant and makes
- all sorts of other things easier to understand.
- --
- --Andrew Koenig
- ark@europa.att.com
-