Hmm... Haskell? Or Nimrod? Or something else? What's the benefit? How will it affect existing code? Last but not least, will you implement it?

Hi,
quite often you need to change a value relatively to another value. For example:

   array1[array2[i]] := array1[array2[i]] + 42;

Luckily this can be written as

   array1[array2[i]] += 42;

Which is nice.

However, sometimes you do not need addition, but the minimum. For example:

    array1[array2[i]] := min(array1[array2[i]], 42);

Now, you need to repeat all the array indices.

Which is very ugly.

So there should be an alternative syntax, similar to += : I.e.:

    array1[array2[i]] min= 42;

More generally, if func is a 2-ary function, of type type(a) => type(b) => type(a), the syntax

a func= b

should become a := func(a, b)

(Or alternatively the syntax a : func = b; might be easier to parse)

Benito

Declare a custom function and mark it inline for efficiency. That also allows you to document it properly, have different implementations depending on the parameter types and so on.

There really are limits to the extent that the underlying Pascal should be mangled further. Your time would be better spent trying to persuade the core developers to tolerate extra operators like ⌊ for floor(), and then working out how to implement them >:-)

array1[array2[i]] := array1[array2[i]] ⌊ 42;
array1[array2[i]] ⌊= 42;

There was already a discussion some time ago whether we should allow operators like "or=" and such as well and the result was simple: no. I consider this the same here.

You can achieve a similar effect through type helpers in 2.7.1 though:

=== code begin ===

program mintest;
{$mode objfpc}
uses
   Math;
type
   TLongIntHelper = type helper for LongInt
     procedure Min(aValue: LongInt);
   end;
procedure TLongIntHelper.Min(aValue: LongInt);
begin
   Self := Math.Min(Self, aValue);
end;
var
   arr: array[0..20] of LongInt;
   i: LongInt;
begin
   for i := Low(arr) to High(arr) do
     arr[i] := i;
   for i := Low(arr) to High(arr) do
     Write(arr[i], ' ');
   Writeln;
   arr[15].Min(10); // arr[15] is passed as Self to Min
   for i := Low(arr) to High(arr) do
     Write(arr[i], ' ');
   Writeln;
end.

=== code end ===

Regards,
Sven

What's the benefit?

Same benefit as += to := ... +

You do not need to rewrite/compute the left side

How will it affect existing code?

Not at all, since old code using this, would not compile

Last but not least, will you implement it?

I can try

Benito van der Zander wrote

> What's the benefit? Same benefit as += to := ... + You do not need to rewrite/compute the left side

+= does *not* prevent re-evaluating the left side. It is internally translated to "x:=x+y" and then evaluated like normal. So if "x" contains a function call with side effects, these side effects are still triggered twice.

Jonas

Same benefit as += to := ... + You do not need to rewrite/compute the left side

Save typing only then, the same mistake the C style operator support have done.

There was already a discussion some time ago whether we should allow operators like "or=" and such as well and the result was simple: no. I consider this the same here.

But it would be more consistent with +=

You can achieve a similar effect through type helpers in 2.7.1 though:

looks cool, but I only have 2.6.2...

Perhaps that should be defined in the rtl

that's overkill if it is only an internal datastructure

our time would be better spent trying to persuade the core developers to tolerate extra operators like ⌊ for floor(), and then working out how to implement them >:-)

Or allow unicode identifier, and than defining ⌊ for ⌊= would just be a special case of func=

Benito van der Zander wrote

> Luckily this can be written as > array1[array2[i]] += 42; >

I would use Pascal (not C) and write

inc(array1[array2[i]],42);

I would use Pascal (not C) and write inc(array1[array2[i]],42);

well, that won't help with min

Now *that* is ugly. It would take me quite a while to find out what happens here. What is assigned to what and when?
Why making Pascal look like C instead of using C?
In the example case I would prefer the original or write

if array1[array2[i]]>42 then
     array1[array2[i]] := 42;

or if performance is realy an issue you I would use an intermediate pointer to the array type:

var p : ^arrayelementtype;
p := @array1[array2[i]];
p^ := min(p^,42);

I thought there was something like that, but I couldn't put my finger on it :-)

"Benito van der Zander" wrote

> > > There was already a discussion some time ago whether we should allow

operators like "or=" and such as well and the result was simple: no. I consider this the same here.

But it would be more consistent with +=

Consistency does not necessarily make them desireable.

Then you'll need to wait until 2.8.0 is released (and no, I don't have an estimate). And even if we'd implement your proposal you'd need to wait for the next major version...

Some helper could be defined in additional units, but the problem with them is that only one per type can be active at a time (Delphi compatible). My plan is to change this though, but for this I first need to define proper search rules for this...

Regards,
Sven

Now *that* is ugly. It would take me quite a while to find out what happens here.

Perhaps :min= was better?

Why making Pascal look like C instead of using C?

C also does not support this :(

And it does not have arbitrary array index ranges

In the example case I would prefer the original or write

In the real program I ended up with

if array1[array2[i]]>42 then array1[array2[i]] := 42;

Then you have everything twice.

And if you have to change i to j, you might forget to change one

In our previous episode, Benito van der Zander said:

Good point. So to be consistent, don't turn it on :-)

Good point. So to be consistent, don't turn it on :-)

NEVER turn it on for me :-)
If only I'm the core dev, I would mark the C operator feature as deprecated and remove it in the next major version.

Same here.
M

2013/3/29 Sven Barth

Using type helper here may result in "apparently" same effect. But in fact they are very different. The syntax OP proposed is a mechanism of the language (compiler), i.e. support will be ubiquitous, but if you implement it with type helper, then you have to write the helper (or use it) every time you need such very tiny "feature" (if not just save typing), which voids the whole idea of make the source code simpler. Unless you put such helper into the RTL, which will be similar to the OP's proposal, but not as elegant.

My opinion is that I like this feature, but I don't mind if it is implemented or not. That will indeed make the syntax more complex and a little un-pascal-ish.

As to the C-style += operator, I have one question, will it makes code slightly faster? because if you use Inc() or Dec() there will be a function call? or, the compiler will always try to inline Inc or Dec?

As to the C-style += operator, I have one question, will it makes code

slightly faster? because if you use Inc() or Dec() there will be a function call? or, the compiler will always try to inline Inc or Dec?

No, as been explained, it's internally translated to the equivalent non-C style by the compiler. Inc/Dec is always processor's single inc/dec instruction AFAIK (at least that's how it's implemented if you dig in to their code).

leledumbo wrote

> Good point. So to be consistent, don't turn it on :-) NEVER turn it on for me :-)

If you use a compiler without a preset fpc.cfg than it's disabled by default. It needs to be switched on using "-Sc" or "{$COPERATORS ON}".

If only I'm the core dev, I would mark the C operator feature as deprecated and remove it in the next major version.

[Note: No personal attack intended with the next sentence] In that case I think we are lucky that you aren't a core dev :P We value backwards compatiblity very high and this is part of it, no matter whether these c-like operators are considered good or bad...

Regards,
Sven

No, there is no difference, because even if we would implement support for "function based operators" we would not implement any default ones or only provide them with an additional unit. So you either need to implement them yourself or use an additional unit anyway.

My opinion is that I like this feature, but I don't mind if it is implemented or not. That will indeed make the syntax more complex and a little un-pascal-ish.

A "little" is an understatement...

As to the C-style += operator, I have one question, will it makes code slightly faster? because if you use Inc() or Dec() there will be a function call? or, the compiler will always try to inline Inc or Dec?

No, "a += b" will be translated to "a := a + b" by the compiler (with all consequences like sideeffects etc.). The C-like operators are merely syntactic sugar.
"Inc" and "Dec" are normally implemented using compiler magic and thus are relatively fast, though the compiler will optimize statements like "a := a + 1" as well (though only if "a" is side effect free, so: no property for example, but that's also true for "Inc" and "Dec" :) ). And as a sidenote: "Inc" and "Dec" can be overloaded as well.

Regards,
Sven

The C-style operators have a special status anyways: they were one of the first third party contributions to fpc somewhere in spring '96 :)

In our previous episode, Florian Kl?mpfl said:

Even if you don't like them (like me), they are occasionally handy when translating C code. Avoids introducing errors.

Sven Barth wrote

We value backwards compatiblity very high and this is part of it, no matter whether these c-like operators are considered good or bad...

But that's not the point here. The problem has nothing to do with backward compatibility. Just the opposite. If you incorporate each and every "feature" from any other language then you no longer have Pascal. The end would be that you can write whatever language you want, the compiler will understand it. This may look like a benefit but after all you cannot be sure to understand source code written for this compiler anymore. It would require learning all the many languages that exist within "Object Pascal". To program nowadays it already requires a lot of other things to learn (different OSs and interfaces). I see no need to add even more to that by adding features over and over again. Pascal was successful because it was easy and clear. Now it becomes complex and cluttered.

What is it about Pascal programmers and their assumption that verbosity is a prerequisite to clarity?

Elsewhere, I see an otherwise-sensible Delphi programmer enthusing about LiveCode which appears to be some species of Visual COBOL. Sometimes I wonder whether I'm on the right planet.

I, for one, see absolutely nothing wrong with += etc. since it's an unambiguous idiom which came into use decades ago and is now almost universally understood. Things like ptr++ or Inc(ptr) are far more pernicious.

Agreed. It is propably time now to make an new attempt for an open source "Pascal-like" compiler which is not forced to follow Delphi and can learn from the pros and cons of Free Pascal without the ballast of backwards compatibility from 20 years.

Martin

Indeed. First, we should get rid of this sting type mess and concentrate on good utf-8 support.

It's about backward compatibility with existing FPC-compilable code that makes use of this feature, and that would no longer be compilable by FPC if the feature were removed.

Jonas

matter whether these c-like operators are considered good or bad...

But that's not the point here. The problem has nothing to do with

backward compatibility.

I am talking about the C operators here as the compiler supports them. As Florian wrote they were contributed in '96, so they are part of FPC's heritage and thus they are object to the same backwards compatibility protection as any other feature we currently support (bugs in those features excluded).

Also I've answered to a "threat" to this protection by leledumbo.

And I agree with you that this proposal of function based operators is un-Pascal-ish and thus I won't support them either.

Regards,
Sven

Am 29.03.2013 11:21 schrieb "Mark Morgan Lloyd" <

: I, for one, see absolutely nothing wrong with += etc. since it's an

unambiguous idiom which came into use decades ago and is now almost universally understood. Things like ptr++ or Inc(ptr) are far more pernicious.

The "normal" C-like operators as we currently support them aren't completely bad (I use them myself here and there), but suggestions like "min=" are too much.

Regards,
Sven

In our previous episode, Mark Morgan Lloyd said:

That's an old discussion. Here is the canned answer:

It's simply how the latin alphabet works, a native to the latin alphabet is trained to read words that consist out of multiple tokens from a limited set.

Not to interpret a sequence of tokens from a large set. It might be different for Chinese :-)

However while some writing systems (like many Eastern Asian languages) are more ideogrammic, it might be dangerous to expand this to the domain of programming languages, where very small changes can have great consequences. (natural languages have a certain mount of redundancy to avoid problems).

Of course it is all reletive. I don't particularly mean to change := to
 " becomes " or so :-)

I, for one, see absolutely nothing wrong with += etc. since it's an unambiguous idiom which came into use decades ago and is now almost universally understood.

"Universal" in the curly braces world. We are not part of that family.

I mean, with the proposed way, you can just use all predefined functions, such as Min or Max, also, it is much easier to just define a function than write a class helper. But anyway, these are only little tricks...

I, for one, see absolutely nothing wrong with += etc. since it's an

unambiguous idiom which came into use decades ago and is now almost universally understood.

I see one: compatibility with other compilers, though I exclusively use FPC, some people in groups I'm involved in asks general Pascal/Delphi questions, which I can't answer with this C-ish feature.

I must emphasise that my "nothing wrong" applied to += as a general language feature, not to its use where portability was concerned. But I must also add that I got this from an accomplished Delphi user (and occasional journalist) this morning:

"PS: I like the idea of += in Pascal. How far do they take it? Is there a /=, *=, mod=, or=, xor=?"

+1

Marcos Douglas

Mark Morgan Lloyd wrote

What is it about Pascal programmers and their assumption that verbosity is a prerequisite to clarity?

Why do you think nobody is writing text in stenography? It would be much less text to write. But we use "standard" languages which have a lot of redundancy. This has the advantage that errors can easily be detected and often can also be corrected. With no redundancy this is not possible. The same applies to programming languages. And that makes (made) Pascal much clearer than C.

So how is something like the += idiom, which seems to be unpopular because it's "not Pascal", unclear? Or for that matter how can braces as distinct from Pascal-style begin-end make a language inferior when their use is unambiguous?

The biggest threat to clarity comes from excessive overloading: use of [] for array subscripts and set elements, use of () for statement grouping, function parameters and so on, multiple function definitions distinguished by their parameters, class/type helpers, and in particular automatic type conversions. Not that I'm suggesting that any of these be ripped out of the language, but my own belief is that notational shortcuts such as += cannot be criticised on the grounds that they sacrifice clarity or compromise error handling.

On 29/03/2013 09:53, Jürgen Hestermann wrote:
[...]

I can't agree with you...

If it wasn't for 'things to learn', Pascal would still be stuck at Borland Turbo Pascal 6 level (that's the one I remember learning at school).

And since the 'novelties' of classes, interfaces (which nb. I can't seem to bend my head round yet) do increase complexity, that make the language look cluttered, some features designed to simplify managing the clutter should be welcome...
(and no, CodeTools and Lazarus ain't always the answer for everybody)

[case in point: the try...[except]...[finally]...[except]...end; I wrote about some time before]

L.

Is evaluated as x := x + y or as x := x + (y)
(where Y can be any expression)

I usually tanslate C code like the first, but recently found out that is should be done like the last.

Marc

FPC guarantees nothing about the order in which expressions are evaluated. FPC generally reorders expressions based on how many registers the compiler thinks it will need.

Jonas

Lukasz Sokol wrote

[case in point: the try...[except]...[finally]...[except]...end; I wrote about some time before]

Which reminds me: would you please be so kind to create a feature request for this, so it won't be forgotten?

Regards,
Sven

OK, signing up to mantis :)

L.

Issue #0024216 .

L.

Thank you.

Regards,
Sven

So far, not many (i.e. none) comments in favor...

L.

Yes, I've seen that as well...

Regards,
Sven

But it was discussed fairly thoroughly here, and I think that consensus was positive. Also (Sven) your request was to get it into Mantis pro forma, rather than for everybody here to use Mantis to vote on its desirability.

But those that commented on Mantis didn't comment to the thread on the mailing list...

Regards,
Sven

Sven Barth wrote

Am 04.04.2013 14:56, schrieb Mark Morgan Lloyd: > Sven Barth wrote: >> Am 04.04.2013 13:54, schrieb Lukasz Sokol:

[trim]

perhaps they should be pointed to the thread so they can catch up?

Well, if you are looking for votes, I certainly would NEVER use it. (Which is not quite the same as being opposed to someone doing it, as long as I can ignore it). To me, the construct is far, far more ugly than anything it solves.

More importantly, the c style operators are vaguely tollerable becasue they are actually operators (though I still never use them). Doing this with a function seems horrible to me.

Wouldn't the Pascal way of doing this be something like

procedure minproc(var target: integer; array of integer)

which would then take the minimum of target and all the other values, and set the result back to target. (It could probably be a function and return the min value as well, for when that would be more convenient.)

ps Hope I have kept track of the context of the thread, it has been a long one ...

cheers,
John Sunderland

"John" wrote

ps Hope I have kept track of the context of the thread, it has been a

long one ...

Nope, you haven't. :)

Lukasz' mail is about a construct that combines try-except and try-finally and not about these function based operators. For for information just look at this bug report: http://bugs.freepascal.org/view.php?id=24216

Regards,
Sven