From 3849209224693562078 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5be30c38f618a07b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-06-03 10:06:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: remove.haberg@matematik.su.se (Hans Aberg) Newsgroups: comp.std.c++ Subject: Re: Why switch w/ only integral types? Date: Mon, 3 Jun 2002 17:05:24 GMT Organization: Mathematics Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <6ee7d287.0203202005.63e0b7b3@posting.google.com> <3CCE6310.672E55DF@webmaster.com> <23b84d65.0205291735.208a70d6@posting.google.com> X-Trace: mail2news.demon.co.uk 1023123930 mail2news:27132 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) NNTP-Posting-Date: Mon, 3 Jun 2002 10:52:11 +0000 (UTC) Lines: 106 Xref: archiver1.google.com comp.std.c++:11812 In article , jakacki@cidc.com.cn (Grzegorz Jakacki) wrote: >> Check Haskell http://haskell.org. I recall that in Haskell (like in SML >> and some other functional languages), one can define functions by patterns > >Pattern matching in Haskell is based on the fact, that every value >contains information on which "constructor" has created it. This is right, in addition to the translation of a more general (relative C++) "cases" construction, Haskell has a pattern matching feature, building on the idea that certain (in Haskell named) "constructors" can be inverted. As C++ does not have anything directly corresponding to Haskell constructors (the C++ constructors can be written to general for this stuff to work), I decided to exclude that part. I just felt it might take too much to add something like that to C++, but this does not mean that the feature is not interesting. > E.g. >values of list type have two constructors: nilary constructor [] and >binary constructor `:`, and looking at list value runtime can tell, >which constructor has been used to create it. The constructors are >used to form patterns. These constructors, used not only in functional language like Haskell, but also on Prolog type languages, are in fact very special: If one, instead of the simple x:xs constructor, adds the full list concatenation xs ++ ys constructor, then problems like unification and pattern matching are transformed from relatively straightforward problems into very difficult ones of mathematical group and monoid theory. > In C++ the values have no unique >"constructions". So therefore, it looks as though there is no way to allow such general, user defined constructors, as is possible in C++, and keep the pattern matching. > However there is an analogy between Haskell value and >C++ dynamic type, thus your list example can be translated into: >struct List { virtual ~List() {} }; >struct Cons : public List { int value; List *next; } ; >struct Nil : public List { } ; >int size(List *l) >{ > switch (l) > { > case (Cons *cons) : return 1 + length(cons->next); > case (Nil *) : return 0; > default (List *) : throw "unknown subclass of List"; > } >} >Currently this code can be simulated with dynamic_cast, but when >compiler sees it as a dedicated construct it is able to: So it might be the case that such a "cases" construction can help in various frequently occuring situations. It might be that limited pattern matching can be allowed by digging into C++'s template system. For example: template const char* what_am_I(X x) { cases (X) { case int: return "I am an int"; default: return "I am not an int"; }; } The template system would match the cases, discovering that there are two different implementations required (instead of using the template specialization system). -- Just an idea, an input that might be used for something useful. So it might be case that having look onto such a "cases" construction can come result in something quite useful to the programmer.. >* reorder freely (except some degenerate cases), >* optimize by emitting new virtual functions for classes taking part > in switches. The question is how to communicate such data to the compiler in a general fashion. For example, if one knows that functions are pure, their computational order can be re-arranged. In a cases construction, one need in addition to know something the relative generality of those statements, so that not a statement that is covering up parts of another statement is computed before that other statement. This is the "=>" implication order. In C++, perhaps the best way to express such a relation is via the system of derived classes. (I do not see the details though.) Hans Aberg * Anti-spam: remove "remove." from email address. * Email: Hans Aberg * Home Page: * AMS member listing: --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]