On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt <mich...@freepascal.org> wrote: >> 2.1) Tuples are always temporary and anonymous. You can not store a >> tuple, define tuple type, of variable of tuple type. >> So tuples are 100% static, compile-time feature -- no change to >> RTTI, variants etc. > No. > > I think that tuples should be a full fledged type, not an anonymous one with > all the restrictions that come from it.
Let me restate: 1) Tuple as a type does nothing new compared to a record, except for possibility to omit field names. 2) While I agree that omitting field names might be a useful shortcut, it is wasteful to introduce a whole new keyword and syntax just for that -- I propose to just extend record syntax, possible variants: type TKeyValue = record (Integer, String) end; type TKeyValue = record of Integer, String end; type TKeyValue = record Integer; String end; type TKeyValue = (Integer; String); 3) The main part of the feature, IMHO, is a new tools for record and array manipulation -- construction and deconstruction of tuples. So in my proposal, tuple is not a type, but a concept underlying a syntax construct -- similar to, for example, a sequence of statements, or a parameter list. > Pascal is declarative. No, it is not. http://www.britannica.com/EBchecked/topic/417798/declarative-language http://en.wikipedia.org/wiki/Declarative_programming I think you meant that in Pascal identifiers must be declared before usage -- that is true, and of course tuples proposal agrees with that. > So, you must declare a tuple when you want one. Consider the most basic example: a, b := b, a; What do you propose to declare here? > As for notation: > Adding the () brackets to indicate a tuple adds to clarity, simply relying > on the comma to indicate a tuple is not acceptable. Pascal IS a verbose > language. If you want unreadable: go for Javascript. Verbosity in Pascal usually comes from using more keywords, not more punctuation. Using comma only would simplify grammar (and possibly parsing, although I am not sure of that -- FPC parser is not easy to understand). Consider, again: for k, v in a do vs for (k, v) in a do a, b := b, a; vs (a, b) := (b, a); DrawLine(Tuple(ARect), AColor); vs DrawLine((Tuple(ARect), AColor)); Why do you think second examples are more clear then first ones? Of course, if the expression becomes complex, programmes may add brackets -- as is already the case with other expressions. OTOH, this is the point I am willing to concede -- the difference is rather small. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel