I was having a bit of fun earlier while waiting for a call. Am I correct in believing that something like

type    t1= array of integer;
var     a1: t1;
	x: integer;
a1 := [1,2,3,4,5];
can't be done at present, irrespective of any custom definition of the
:= operator?

Is there an accessible not-a-number constant, to allow me to do something like

var     reduce: double= NAN;
   x := reduce + a1;

with an appropriate definition of the + operator without risk that an error would try to evaluate it as an ordinary arithmetic expression?

Maybe if you overload the assignment operator for "t2=set of byte" to "t1" assignments, but I'm not certain. It's definitely not something we explicitly support.

We don't have constant to identify a qNaN. I don't even know whether all architectures support them. Currently, the only way to achieve the above is by masking exceptions for invalid floating point operations: math.SetExceptionMask(math.GetExceptionMask + [exInvalidOp]).

You cannot overload/override operators that have a built-in meaning in the language (such as double+double).

Jonas

In our previous episode, Jonas Maebe said:

       NaN = 0.0/0.0;
       Infinity = 1.0/0.0;
       NegInfinity = -1.0/0.0;

but of course that is just notation/convention (that 0.0/0.0 as literal evaluates to NaN), it doesn't mean all archs do.

That's a good point, although obviously ordering would be lost. After I'd tinkered with it for a while I concluded that it was probably related to the discussion of tuples a few weeks ago.

Thanks, noted. In practical terms the value isn't important, and I could obviously use something like a null variant or for that matter a nil pointer as a marker.

You cannot overload/override operators that have a built-in meaning in the language (such as double+double).

Understood, but what I'm doing here is using "reduce +" as an experimental alternative to APL's +/ or Vector Pascal's \+ to reduce the dimension of the right operand by applying the operator:

c1:
7 9 11 13 5
+/ c1:
45

I've not investigated SSE or spreading over multiple cores yet, and probably won't due to time issues. My only incentive was looking for some alternative to Vector Pascal's higher-level functions, since obviously something like \<operator> <array> couldn't be achieved without major compiler surgery.

Thanks for that. Initial experiment using a NaN real or nil pointer throws an exception as soon as it's passed as the parameter which I suppose is not entirely surprising. Using varnull as a placeholder seems safest, although it looks as though I can't initialise a variant at declaration... WTH, it's just a toy for the
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Not really.

Also the principial components are already available in the compiler so in theory (!) one could implement this. Array constructors (the "[...]" notation) is already used for open array parameters and array initialization is already possible for named dynamic arrays in the form of the delphi compatible "TMyDynamicArrayType.Create(1, 2, 3, 4, 5);" (yes, I think this is a bad choice of implementing it and comes probably from Delphi.NET :( )

Regards,
Sven

Although if I understand things correctly that's for the specific case of a parameter passed to a procedure of function, not for the operand of a redefined operator such as := even though the definition looks like a function.

So it might be able to do it with a type helper, at the cost of looking like a function rather than like an ordinary assignment.

Of course one place where what I'm playing with gets hairy is in overlaid operator definition: I'm having to define e.g. + for a pair of 1-D dynamic arrays, a pair of 2-D dynamic arrays and so on. If I understand things correctly it's not possible to define a generalised dynamic array parameter where the dimension (number of axes/indexes) as well as the rank (range of each index) is undefined.

Am 15.04.2013 22:32 schrieb "Mark Morgan Lloyd" <

in theory (!) one could implement this. Array constructors (the "[...]" notation) is already used for open array parameters

Although if I understand things correctly that's for the specific case of

a parameter passed to a procedure of function, not for the operand of a redefined operator such as := even though the definition looks like a function.

Both are parsed using the expression parser... I would even go that far to say that it's "just" the type checking in the assignment code that doesn't handle such array assignments yet (and yes, this is a bit simplified compared to the real situation ^^)

Regards,
Sven