Extensions to Delphi
Tusk offers the ternary operator popular in C, C++, Java,
JavaScript, C#, etc…
Prompt := Qty > 100 ? 'Large order - thanks!' : 'Small order';
Tusk offers slightly more concise notation for defining
short functions and procedures…
// Traditional approach
function Sum(x, y: Integer): Integer;
begin
Result := x + y;
end;
// More concise alternative
function Sum(x, y: Integer): Integer = x + y;
// Traditional approach
procedure Display(a, b: Integer);
begin
Writeln(a, ' + ', b, ' = ', Sum(a, b));
end;
// More concise alternative
procedure Display(a, b: Integer) =
Writeln(a, ' + ', b, ' = ', Sum(a, b));
Like Delphi, Tusk offers type inference when declaring
variables…
var a := 123; // implicitly of type Integer
var s := 'hello'; // implicitly of type string
Tusk extends this feature to the return type of a function
(when using the one-line approach described above)…
// Implicitly returns Integer
function Sum(x, y: Integer) = x + y;
Like many languages in the C family,
Tusk permits trailing commas and semi-colons…
- When declaring function/procedure parameters;
- When specifying arguments to a function/procedure call;
- When specifying expressions in a case statement;
- When building a list literal.
In Tusk, the IType data type represents a type,
somewhat like Delphi's PTypeInfo.
In Tusk, however, IType is more flexible and powerful.
For example…
type INbrList = IList<Integer>;
const Nbr = ValueType(INbrList); // Nbr is Integer
var z: Nbr := 223; // z is an Integer
Tusk supports Delphi's for loops,
including a new feature for the for‥in loop.
Instead of this…
var i := 0;
for var v in List do begin
Writeln('List[', i, '] = ', v);
Inc(i);
end;
You can do this…
for var v at var i in List do
Writeln('List[', i, '] = ', v);
The index variable,
which is introduced with the at keyword,
is zero for the first iteration, one for the next,
and so on.
This variable can be local to the loop,
as shown above, or can be an existing variable…
var i: Integer;
for var v at i in List do
Writeln('List[', i, '] = ', v);
When the variable is local to the loop,
you can specify the data type,
but it defaults to NativeInt…
for var v at var i: Int64 in List do
Writeln('List[', i, '] = ', v);
Tusk offers a case statement that is similar
to Delphi's, with one notable improvement.
Instead of this…
var Status: TYesNo;
case Status of
ynUnknown: Writeln('Uncertain');
ynNo: Writeln('No');
ynYes: Writeln('Yes');
else InternalError;
end;
You can do this…
var Status: TYesNo;
case:strict Status of
ynUnknown: Writeln('Uncertain');
ynNo: Writeln('No');
ynYes: Writeln('Yes');
end;
Above, it is a parse-time error if the case
statement does not have every valid choice from the
underlying data type.
In Tusk, anonymous methods can be
implicitly converted to Variant as well as IInterface,
whereas in Delphi, an explicit cast is required
(we typically use TAnonMeth.ToVar and TAnonMeth.ToIntf).
Tusk offers the built-in type object,
which is like Variant, except for the following:
when converting a function expression to object,
Tusk will not attempt to add empty parentheses.
For example…
function f: string = 'hello';
var v: Variant := f; // v is 'hello' (implicit function call)
var o: object := f; // o is the function f (no implicit call)
Show(v); // prints: 'hello'
Show(o); // prints: function f: string = 'hello'
Writeln(v); // prints: hello
Writeln(o); // raises an exception
Above, the last call to Writeln raises an exception because
there is no implicit conversion from interface to string
(in Tuskm, functions are interfaces).
In Tusk, narrowing conversions require an explicit cast,
as opposed to Delphi, where narrowing conversions happen
implicitly.
For example, Delphi will happily pass an Int64 value
to a function that requires a Byte,
but Tusk requires an explicit cast.
In Delphi, out parameters pass the argument
by reference, like var parameters.
The difference is that, for managed types,
out parameters are cleared out immediately
before the called function executes.
For other data types, out and var
behave identically.
In Tusk, out parameters are consistent:
they are always cleared out, regardless of data type,
at the point of call.
In Tusk, a const parameter is passed by value,
but cannot be changed within the function itself.
Whether a parameter is passed by value
or by const affects the called function,
but not the caller.
Therefore, the following code works fine in Tusk…
type
TIntProc = procedure(x: Integer);
procedure p1(y: Integer);
begin
end;
procedure p2(const z: Integer);
begin
end;
var ip: TIntProc;
ip := p1;
ip(3);
ip := p2; // In Delphi, this would not compile
ip(4);
In Tusk, the type of a function includes information about
which parameters are optional.
For example, to define the variable p as a procedure
that takes one string and an optional integer…
var p: procedure(const s: string; i: Integer = ?);
Note that the data type does not indicate the value
of default parameters — just that they are optional.
Thus, p (once assigned) can be called in two ways…
p('hello');
p('goodbye', 22);
To assign a value to p,
we could do something like this…
p :=
procedure(const: string; i: Integer = 9);
begin
Writeln(s, ': ', i);
end;
In Delphi, a procedural type can specify optional parameters,
but the default value is baked into the type.
In Tusk, default parameters can be expressed using
previous parameters…
procedure p(x: Integer; y: Integer = 2*x; z: Double = Sqrt(y));
begin
Writeln(x, ' ', y, ' ' , z);
end;
In Delphi, the above would have to be an overloaded trio…
procedure p(x, y: Integer; z: Double); overload;
begin
Writeln(x, ' ', y, ' ' , z);
end;
procedure p(x, y: Integer); overload;
begin
p(x, y, Sqrt(y));
end;
procedure p(x: Integer); overload;
begin
p(x, 2*x);
end;
In Tusk, there are no restrictions
on what type of parameters can have default values.
In Delphi, only certain data types can have defaults —
for example, Integer and string are supported,
but not Variant, objects, static arrays, or records.
In Delphi, default parameter values must be
compile-time constants.
In Tusk, default parameter values may be any
expression (evaluated at the time of call,
but only if the argument was omitted).
For example…
var x: Integer := 123;
procedure Work(z: Integer = x);
begin
Writeln(z);
end;
Work(3);
Work;
x := 999;
Work;
The above program prints…
3
123
999
In Tusk, functions may be frozen,
meaning that they exhibit no side effects,
and always return the same value for a given set of inputs.
Examples of such functions include Pos and Sqrt.
Frozen functions can be used to make
constants known at parse time.
For example…
type MyInt = Integer; // type declarations are always frozen
const k = Sqrt(16); // k is frozen, because Sqrt and 16 are frozen
var j: Integer; // variables are not frozen
case j of
2: Writeln('two');
k: Writeln('four'); // k is allowed, because it's frozen
end;
Some functions are always frozen,
and others are frozen only if
all their arguments are frozen.
Others, of course, are never frozen
(even if their arguments are),
including Inc and Dec
(due to side effects) and Now,
which can return a different value with each call.
Delphi has a few less-than-ideal behaviors
related to function results.
For managed types, Result may be bound to a local
variable in the caller's scope.
This can lead to a couple of odd issues:
Result may have a non-zero initial value,
and it may apply changes to the caller's variable
before the function completes.
In Tusk, Result is never aliased to any other value.
For non-managed types, Result has no defined value.
Typically, the compiler warns if you use Result
before giving it a value, but this is not reliable.
For example…
procedure Work(var z: Integer);
begin
end;
function Compute: Integer;
begin
Work(Result);
Writeln(Result);
Result := 0;
end;
Above, Compute writes a random number,
but the code is warning-free.
Tusk addresses this issue in a simple manner:
Result is always zero-initialized.
In Tusk, a property (of an interface) can be used anywhere
a value of that type would be expected.
This includes taking the address of a property
or passing a property by reference
(to a var parameter).
For example…
// IEmployee has a read/write Name property
var Emp: IEmployee;
Emp.Name := 'Joe Cool';
Writeln(Emp.Name);
var p: ^string := @Emp.Name;
p^ := 'Jane Smith';
Writeln(p^);
procedure ChangeStr(var s: string);
begin
s := 'Wilma Flitstone';
end;
ChangeStr(Emp.Name);
The above works fine in Tusk,
even though most of it wouldn't work in Delphi.
For array properties, the above discussion applies
to individual elements of the array property…
var List: IVariantList := [4,5,6];
Writeln(List.Items[1]);
Writeln(List[2]);
var p: ^Variant := @List.Items[0];
p^ := 888;
Writeln(p^);
procedure ChangeVar(var v: Variant);
begin
v := 333;
end;
ChangeVar(List[1]);
For certain array properties,
Tusk supports pointer math…
var List: IVariantList := [4,5,6];
var p: ^Variant := @List.Items[0];
while InBounds(p) do begin
Writeln(p^);
Inc(p);
end;
To enable pointer math on an array property,
use the [TuskArray] attribute.
For example, here's how IReadOnlyVector
is exposed (in the unit Tusk_GenUtil)…
Tusk_IReadOnlyVector = class
public
Obj: IReadOnlyVector;
function get_Items(i: Integer): Variant;
[TuskArray('Count')]
property Items[i: Integer]: Variant
read get_Items; default;
function get_First: Variant;
function get_Last: Variant;
property First: Variant read get_First;
property Last: Variant read get_Last;
end;
The [TuskArray] attribute is only supported
on indexed properties with a single index parameter,
which must be an integer type.
The [TuskArray] attribute takes an argument,
as shown above, a string specifying the name of
the property that indicates the element count
for the array property.
This argument defaults to "Count",
so the above is actually written as follows…
[TuskArray]
property Items[i: Integer]: Variant
read get_Items; default;
The count property (whatever it is called)
must also be an integer type,
and may (as in this example)
be defined in the class that exposes an ancestor type
(Tusk_IReadOnlyVector, in this case).
In Tusk, expressions of type Variant support the dot operator
(requiring the value to support IAssociation)…
var v: Variant := Something;
Writeln(v.x); // TType.VarAs<IAssociation>(v)['x']
Similarly, Variant expressions support the square bracket
operator for IAssociation and IReadOnlyVector objects…
var v: Variant := SomeAssociation;
Writeln(v['y']); // TType.VarAs<IAssociation>(v)['y']
var w: Variant := SomeList;
Writeln(w[2]); // TType.VarAs<IReadOnlyVector>(w)[2]
Tusk offers a built-in type, IDotBag,
which is assignment-compatible with IAssociation.
IDotBag does not expose any properties or methods of
IAssociation or its ancestor interfaces.
Instead, IDotBag allows you to access the default array
property of IAssociation using the dot
or square bracket operators…
var s := 'z';
var a: IAssociation := Something;
Writeln(a['x'] + a['y'] + a[s]);
var b: IDotBag := a;
Writeln(b.x + b.y + b[s]);
In this way, IDotBag is similar to Variant,
but it is more restrictive because IDotBag
is still an interface, so (unlike Variant)
it cannot be used with arithmetic operators,
doesn't implicitly convert to other types, etc.
⏱ Last Modified: Sat 6:13:57 pm