Useful Oxygene Features for FPC?

[marcov]

Oxygene just randomly exposes crap from .NET because it is cheap and looks fashionable.

Just like for their GCed world, the whole nesting tuple bit is irrelevant.

But seems we agree, a whole lot better descriptions (and goals) are needed to even brainstorm about them.

[Martin_fr]

Depends. You can also see a tuple as an reference to an implicit record that is automatically  type compatible to tuples that have the same declaration. Add in some rtti for iteration purposes,  interface style refcounting maybe.

That is the big question, if partial assignment is possible, then they would not need the same declaration.
  var t: tuple of (integer, string, boolean);
  var x: tuple of (integer, string);
  x := t;

copies the first 2 values.

But even if they have the same declaration, this leaves questions.
Because if you changed the declaration of one, then all the assignments in your code would break. So why have such an assignment compatibility? What would be the benefit? What do you get out of having 2 separate declarations, if you can only change them together.

All you have is an alias. And  that you can already to
type TFoo = TBar;

Ok, granted, you gain the ability to use unnamed types

function foo: record a, b : integer end;

For that a modifier for records could be added, so they would be assignment compatible (the modifier would be assumed automatically, for function results with inline declared record as above)

var x: compatible record a,b: integer end;
x := foo();

P.s. reading my own example, I would really always want a name for my record types. Just so, I do not need to repeat the declaration.

[guest58172]

Tuples are useful when conjugated with other language features that Object Pascal doesn't have:

Return type inference in order to make what's called "Multiple Return Values".

Code: Pascal  [Select][+][-]

1. function foo(): auto;
2. begin
3.   result := TTuple(0, 'A'); // TTuple<integer, char>
4. end;

type inference from the tuple used as initialization e.g:

Code: Pascal  [Select][+][-]

1. auto stuff = TTuple(0, 'A'); // TTuple<integer, char>

The type system is actually not powerful enough. For now it's a static and named system of type. Should be also optionally inferred to unleash tuples power.

[Martin_fr]

Return type inference in order to make what's called "Multiple Return Values".

I see static declared types as a feature (a really big one).

So (to me) type inference would be abandoning this feature.

[marcov]

I see static declared types as a feature (a really big one).

So (to me) type inference would be abandoning this feature.

And even if, aggregate return value is a very, very minor improvement to warrant such enormous bundle of fairly fundamental changes.

[Blaazen]

Well yes, as I said most (if not all) could be archived by extending records (not that I advertise doing any of this).

I see only benefit in function call to aviod using of out parameters:

Code: Pascal  [Select][+][-]

1. function MyFunct(a: Integer; b: Char): Integer, string;
2. ...
3. var a, r: Integer;
4.     c: char;
5.     s: string;
6. begin
7.   r, s:=MyFunct(a, c)

And use

Code: Pascal  [Select][+][-]

1. Result[0]:=...;
2. Result[1]:=...;

inside body of function to define result. Anything else is mainly duplicating of record and new keywords tuple of wouldn't be needed at all.

[guest58172]

Return type inference in order to make what's called "Multiple Return Values".

I see static declared types as a feature (a really big one).

So (to me) type inference would be abandoning this feature.

It's still static type in the end, it's just guessed. Optional type inference has really nothing to do with dynamic typing as found in web script languages. Anyway as I explained I don't think that Object Pascal generics are powerful enough to give something really cool with tuples.

And if it's about auto generating comparison operators and such things then this can still be done for POD records. (this is an argument in favor of tuples I had read earlier today, don't recall for which language it was but the guy wrote more or less tuples are lightweight structs with helpers...).

[soerensen3]

Return type inference in order to make what's called "Multiple Return Values".

I see static declared types as a feature (a really big one).

So (to me) type inference would be abandoning this feature.

It's still static type in the end, it's just guessed. Optional type inference has really nothing to do with dynamic typing as found in web script languages. Anyway as I explained I don't think that Object Pascal generics are powerful enough to give something really cool with tuples.

And if it's about auto generating comparison operators and such things then this can still be done for POD records. (this is an argument in favor of tuples I had read earlier today, don't recall for which language it was but the guy wrote more or less tuples are lightweight structs with helpers...).

It's not static if you can do this:

Code: Pascal  [Select][+][-]

1.     function foo(): auto;
2.     begin
3.       result := TTuple(0, 'A'); // TTuple<integer, char>
4.     end;
5.  

You could then as well do this:

Code: Pascal  [Select][+][-]

1.     function foo(someparam: Boolean): auto;
2.     begin
3.       if ( someparam ) then
4.         result := TTuple(0, 'A') // TTuple<integer, char>
5.       else
6.         result := TTuple(0, 20, 30, 40 ); // TTuple<integer, integer,integer,integer>
7.     end;
8.  

Tuples by itself could be static of course, but the above would not be possible unless you implement something like a tuple variant.

[Martin_fr]

I see static declared types as a feature (a really big one).

So (to me) type inference would be abandoning this feature.

It's still static type in the end, it's just guessed. Optional type inference has really nothing to do with dynamic typing as found in web script languages. Anyway as I explained I don't think that Object Pascal generics are powerful enough to give something really cool with tuples.

I know, but the same discussion had been had regarding "for" with undeclared variables.

Also guessing can go wrong. Your code can accidentally assign a value of a type different to what you wanted. So guessing looses one level of error checking.
It also looses read-ability. While the compiler can do a guess (even if complicated) in just a few ms, the human reader of the code can not.

Type interfering is not bound to tuples.  So what is the benefit of type interference, under the circumstances given. That is, as you stated yourself "It's still static type", therefore the programmer must still decide what type he wants. The only saving I can see is to save yourself the "work" of writing it down.
The only other "gain" I can see is: programmers may need less thinking ahead. Not a "gain" in my book.

And if it's about auto generating comparison operators and such things then this can still be done for POD records. (this is an argument in favor of tuples I had read earlier today, don't recall for which language it was but the guy wrote more or less tuples are lightweight structs with helpers...).

Examples / Explanation?

"lightweight structs with helpers": records?

[440bx]

Yes. It rarely needs (ed:leads) to something useful. It is just parroting other languages bulletlists based on short examples with only a terribly generic "will make language more popular" as so called advantage, without any feel of what is needed or what it is good for, and without investigating any actual needs.

Unfortunately, the probability of that statement being true approaches 1.  What followed showed it quite well.   LOL

Oxygene is a cobbled together amalgam of features styled to like fashionable. If it were so great, you would be on the Oxygene site using it, not here.

I agree that Oxygene feels more like a cobbled together bucket of features than a language designed to excel in a particular area of programming.  That said, I do think that ideas found in other languages should be noticed and considered (preferably the good ideas, if at all possible )

Here is one request...  please, never, ever, taint the Pascal language with type inference.  Amazing that such sorry "features" find their way in programming languages.

[Shpend]

Hey, I wanted to ask if something got updated/implemented or did you throw all ideas over the board^^

[jamie]

I see water splashing....

actually, I think the features they have now should be fixed before adding more!

[lainz]

It's not static if you can do this:

Code: Pascal  [Select][+][-]

1.     function foo(): auto;
2.     begin
3.       result := TTuple(0, 'A'); // TTuple<integer, char>
4.     end;
5.  

You could then as well do this:

Code: Pascal  [Select][+][-]

1.     function foo(someparam: Boolean): auto;
2.     begin
3.       if ( someparam ) then
4.         result := TTuple(0, 'A') // TTuple<integer, char>
5.       else
6.         result := TTuple(0, 20, 30, 40 ); // TTuple<integer, integer,integer,integer>
7.     end;
8.  

This sounds like array of const:
https://www.freepascal.org/docs-html/ref/refsu69.html

But a more general usage instead of only be available to pass data to a function.

I think is better to know what is really the output type of a function instead of reading all the function to find that.

FPC already supports JSON and oter rich formats that can be used instead of that.

For your second example I can build this currently:

Code: Pascal  [Select][+][-]

1. function hello(b: boolean): TJSONArray;
2. begin
3.   if b then
4.     Result := TJSONArray.Create([0,'A'])
5.   else
6.     Result := TJSONArray.Create([0,20,30,40]);
7. end;

Code: Pascal  [Select][+][-]

1. var
2.   r: TJSONArray;
3. begin
4.   r := hello(false);
5.   ShowMessage(r[3].AsString); // 40
6.   r.Free;

So I'm now creating TTuple like an alias.

Code: Pascal  [Select][+][-]

1. TTuple = TJSONArray;

[marcov]

Hey, I wanted to ask if something got updated/implemented or did you throw all ideas over the board^^

There were no new ideas.

[jamie]

as for the use of AUTO, well, one could say we simply add the VARIANTS unit in there and then
we have a pile of automatic types we can use, even custom one's that can be tested against..

I know this isn't the same as AUTO exactly but I use variants a lot in a project...


 Ok, NEXT Please!