On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich <drdiettri...@aol.com> wrote: >> 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...
Right side contains examples of records which would be compatible with the tuples on the left -- for both construction and deconstruction. >> True, functional programming is certainly the largest 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? Current consensus in the field of programming languages design is that they did -- which is why FP features are added to just eny language you look at, from C++ to PHP :) >>> 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? Well, that was the idea, auto- breaking a tuple but not an array, so by converting array to tuple programmer can control it. >> 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. The record becomes a tuple only by either explicit conversion, or deconstructing assignment. > 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 ... That depends on the type or err > 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. There is no reason why a record can not be returned in a register. Actually, there is perhaps even greater chance for that compared to out parameter, which is usually implemented as pointer. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel