Alexander Klenin schrieb:
Also note that in my version of proposal, nested tuples are impossible.
I consider this an inacceptable restriction. Records can contain other records.
Yes, but tuples are just a syntax for constructing/deconstructing
records, not records themsleves.
They can be converted to a specific record type by casting.
Consider these examples:
var
x, y, z: Integer;
pt: TPoint;
...
(x, y) // record a, b: Integer; end;
(x, (y)) // record a, b: Integer; end;
(x, (y, z)) // record a, b: Integer; end;
(x, TPoint(y, z)) // record a: Integer; b: TPoint; end;
(TPoint(x, y), TPoint(y, z)) // record a, b: TPoint; end;
(TPoint(x, y), pt) // record a, b: TPoint; end;
(TPoint(x, y), Tuple(pt)) // record a: TPoint; b, c: Integer; end;
I don't see the correspondence between the left and right sides, sorry.
I also dont see whether the left sides are tuple constructors or
deconstructors, what's the intended effect...
* Possible extensions
This is why I think tuples as a data type are not needed.
Instead, I suggest them as a powerful way to manipulate
records, arrays, and parameter lists using one relatively simple concept.
I doubt that a concept alone will help. I see the proposed extensions as an
attempt to introduce elements from *functional programming* languages, for
which OPL lacks many prerequisites.
True, functional programming is certainly the lergest modern paradigm
still lacking from FPC.
What's "modern"? I've learned about functional programming in 1970 - did
all the following languages miss something important?
BTW, I just remembered another tuple usage example:
type
T3DMatrix = array of array of array of Double;
TMatrixPos = array [1..3] of Double;
procedure P(A: T3DMatrix; APos1: TMatrixPos);
begin
A[Tuple(APos1)] := 1.0; // Instead of A[APos[1], APos[2], APos[3]]
end;
I'd accept a TMatrixPos as an array of Integer,
That was just my mistake, of course i meant aray of Integer, sorry.
Why do you expect any difference between
A[Tuple(APos1)] := 1.0;
and
A[APos1] := 1.0;
?
The compiler will have to create the same code for both notations, or use
the same RTL subroutine for doing the job.
The idea is that second case will require a manually-written operator[],
while the first one will work automatically.
NACK. How comes that the compiler should break a tuple into a list of
indices, but not an array? In detail when the tuple contains such an array?
One problem with error codes is their data type. Booleans are not always
sufficient, integers have no obvious meaning. That's why I prefer to use
enumerated types with descriptive names. Which types would your *standard*
return tuple contain?
Note again that I did not mean tuple to be a type, so what I suggested is a
convention, which might be adopted by some library for real-time,
embedded or other
low-level usage where exceptions add too much overhead:
res, error := SomeFunction(params);
where types of result and error will be chosen as appropriate for each function.
The advantages over usual
res := SomeFunction(params, error)
being:
1) Easier to read, once reader knows the convention
2) Ignoring error is more prominent:
res, nil := SomeFunction(params);
3) Since the result is actually a record, functions may still be
chained, while ignoring errors:
SomeFunction1(SomeFinction2(params).res);
The latter looks like breaking tuple rules, by acessing a tuple element
by name.
This means more writing, and the typical use of error codes becomes much
more complicated IMO:
if f(x, res) then ...
has to be rewritten as
res, error := f(x); //or: (res,error) := f(x);?
if error then ...
Of course this could be optimized, when the compiler is extended to
move the result tuple into distinct hidden subroutine arguments (types
omitted):
Note that at machine code level, there is no difference between
"distinct hidden subroutine arguments"
and "single result of a record type", so compiler already does what you suggest.
That's why I wonder about yet another syntax proposal. Your proposal
*requires* that a record/tuple type *is* used for the result, where
otherwise the subroutine could return the result in an CPU or FPU
register, ready for immediate further use.
P.S.: A friend told me that tuple elements can be accessed by index. I'm
not sure whether we should add such a compiler magic, though. I think
that this feature is a workaround for access by name, which is missing
from the mathematical/abstract tuples.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
