[fpc-devel] RFC: Support for new type "tuple" v0.1

Alexander Klenin klenin at gmail.com
Sun Jan 27 13:09:21 CET 2013


On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt
<michael at 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



More information about the fpc-devel mailing list