Hi!
I wanna add new features and facilities to pascal like while - else, for
- else and inline if statement like python.

examples

ex1:

I:=5;
while(I>0) do
   begin
      Write(I);
      I:=I-1;
  end else Write(' While Else ');

ex1-output:54321 While Else

ex2:

I:=5;
   while(I>0) do
   begin
      Write(I);
      Break;
   end else Write(' While Else ');

ex2-output:5

so i want you to help me how to implement it.

thanks a million.

This cannot be implemented without breaking the language.

I:=5:
If (I<5) then
  while(I>0) do
   begin
      Write(I);
      I:=I-1;
  end
else
   Write(' While Else ');

Will not work correctly any more if you want to implement your idea.

So this extension is not possible without breaking backwards compatibility.

Michael.

I'm in tomorrow, we can take a look then.

Kind regards,

Paul

I know this issue but with changing some of structures, I can implement it and now I only want testing adding features to compiler and don't care about backward compatibility,just testing.

I added some changes to compiler functions and classes like pstatmnt.while_statement and nflw.twhilerepeatnode but need more information about functions and units.

Mohsen Timar

And what about the inline if? That should be backwards compatible at a first glance. And it would be a fun thing because the Delphi community has asked for it for many years and Embarcadero looks like they won't add it at all :)

Ondrej

Ondrej Pokorny wrote:

As Michael has said, adding an extra else or for that matter otherwise would be a problem.

And what about the inline if? That should be backwards compatible at a first glance. And it would be a fun thing because the Delphi community has asked for it for many years and Embarcadero looks like they won't add it at all :)

Inline if is an ALGOL feature, and it's inexplicable why it's never been in Pascal.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 08 Oct 2015 16:12:56 +0000, Mark Morgan Lloyd () wrote about "Re: [fpc-devel] new
features and facilities" (in ):

Indeed, it is even more succinct in C/C++:

   x = <boolean> ? <then part> : <else part>;

This was taken directly from ALGOL 60 and remains a very elegant feature.

However, Jensen & Wirth excluded it from the original Pascal Report.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYWnHkACgkQogYgcI4W/5R5IwCgz5RvrROIZn26Pn1u1flRIBKH mIUAn3gyUm9TdTglLkQdYjiI26lSg6ye
=HFIP
-----END PGP SIGNATURE-----

"Ondrej Pokorny" wrote

On 08.10.2015 17:37, MohsenTi wrote: > > I know this issue but with changing some of structures, I can implement

it and now I only want testing adding features to compiler and don't care about backward compatibility,just testing.

> > I added some changes to compiler functions and classes like

pstatmnt.while_statement and nflw.twhilerepeatnode but need more information about functions and units.

And what about the inline if? That should be backwards compatible at a

first glance. And it would be a fun thing because the Delphi community has asked for it for many years and Embarcadero looks like they won't add it at all :)

I had the idea to implement inline-if as well. I think the syntax I selected is derived from Oxygene, but it looks very Pascal and shouldn't break anything:

left := if expr1 then expr2 else expr3;

Thereby expr1 returns Boolean and expr2 determines the type of the whole inline-if, thus expr3 needs to be compatible to expr2.

Regards,
Sven

"MohsenTi" wrote

I know this issue but with changing some of structures, I can implement

it and now I only want testing adding features to compiler and don't care about backward compatibility,just testing.

I wouldn't integrate it in the compiler, but for playing around with the language and learning the workings of the compiler it's okay. :)

I added some changes to compiler functions and classes like

pstatmnt.while_statement and nflw.twhilerepeatnode but need more information about functions and units.

At first glance those locations look correct. Anything specific you're looking for now? Cause the compiler is quite large and I can't explain everything to you just now ^^

Regards,
Sven

Exactly. We discussed the same Oxygene-syntax in the Delphi community.

Ondrej

Sorry, but that doesn't "look Pascal" at all, and is anything but easily understandable, specially given the possible complexity of expr[1,2,3]...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Does Oxygene allow something like this?
left := if expr1 then begin exprN, left := exprK end else begin
left:=left+3; exp3 end
or is it only one expression at a time?
left := if expr1 then if expr2 then expr5 else expr6 else expr7;

thanks,
Dmitry

At which point you'll have various members of the Pascal community decrying it as too C-like.

This was taken directly from ALGOL 60 and remains a very elegant feature. However, Jensen & Wirth excluded it from the original Pascal Report.

More to the point, I don't believe it was in in Wirth's early Pascal compilers although it was in ALGOL-W. This is actually quite a messy area, since ALGOL 68 changed the syntax to add an explicit FI for compatibility with the statement-level IF THEN ELSE FI.

ALGOL also had inline CASE etc., and some implementations (e.g. Burroughs) extended this to accomodate jump tables etc. Curiously, Wirth's Stanford-era compilers use these liberally.

Well, the tenary operator as present in C(++) is a shortcut for a simple if-then-else, and can be pretty readable if used "in moderation". And it assigns a value to x depending on two expressions not some murky boolean result out of three expressions like Bart supposed...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Op 2015-10-08 om 19:25 schreef Dmitry Boyarintsev:

Only one expression at a time, since the 'result' of the expression in oxygene is the combined type of the true value and false value, false being optional defaulting to nil.

Thank you Sven,
is there any documentation about freepascal compiler parts ?

But at least in this instance there's /always/ an ELSE, so there's no risk of apparent ambiguity due to "dangling else": a closing END or FI isn't needed.

It's more difficult to argue for inline CASE, particularly since that one might have optional ELSE or OTHERWISE.

selected is derived from Oxygene, but it looks very Pascal and shouldn't break anything:

> > left := if expr1 then expr2 else expr3; > > Thereby expr1 returns Boolean and expr2 determines the type of the whole

inline-if, thus expr3 needs to be compatible to expr2.

> > Sorry, but that doesn't "look Pascal" at all, and is anything but easily

understandable, specially given the possible complexity of expr[1,2,3]...

And you think C's ternary would be more Pascal? Also you need /some/ definition of what defines the type no whether what syntax you choose (in addition expr1 is the same as in normal ifs, so it's only the "complexity" of expr2 and expr3). And no, "the left side" is not the Pascal answer either.

Regards,
Sven

Sven Barth wrote

And you think C's ternary would be more Pascal?

Well, no.

While I use the ternary operator quite a bit when using C, as it IMHO allows for a cleaner formatting of code there, in Pascal, I always use a cleanly formatted If-then-else.

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Actually, yes I think C's or Javascript's ternary is better suited.

Let me explain. If I see

If expr1 then expr2 else expr3

it says 'statement' to me. But

a ? b : c;

Says "expression" to me.

So

left := a ? b : c;

looks more 'right' than the 'if then else', because the right-hand side is clearly an expression.

The "if expr1 then expr2 else expr3" is equally counter-intuitive and confusing as anonymous functions.

Keyword "If" starts a statement. If you allow to use it in expressions, its meaning becomes context sensitive. That is a bad thing in my book.

So if this thing needs to be implemented, then I'd much prefer it in the ternary form.

Michael.

OK. So presumably, since false < true, b is executed if a is false and c is executed if it's true? >:-)

The way I look at it is that it's restoring a feature that was (possibly accidentally) dropped during the ALGOL -> Pascal transition. As such I don't have any problem with ALGOL-style

left := if a then b else c;

After all, while concise C-style operators work well in expressions this is not a simple expression where all components are evaluated: it's directly equivalent to the statement-level if potentially including exactly the same short-circuiting rules in the boolean expression (a above).

The thing I do have problems with is the difficulty people had explaining nested inline ifs during the 1960s. However I think that was more because they simply hadn't worked out how to write language documentation rather than there being anything inherently tricky about it, and these days there's absolutely no reason why it shouldn't be spaced and indented in a thoroughly Pascal-like fashion :-)

Why would anyone in the world think that ?

Many pascal programmers do not even know that false<true and ord(false)=0 and ord(true)=1, or even that a boolean is equivalent to an enumerated.

The number of times I've encountered

if expr = true then

is staggering, and tends to make me very depressed...

By contrast, many people these days have encountered some C-ish language and do know ternary expressions.

After all, while concise C-style operators work well in expressions this is not a simple expression where all components are evaluated:

Of course it is the same. Boolean expressions by default are shortcut-evaluated. So the ternary is completely equivalent to that and should not present any difficulties whatsoever.

Michael.

Well if it is merely a decision between syntax: FPC already as a command line option for c like operator += -+ ..., so the ? could be only if c like ops are enabled.

Besides this, if ?: is treated like any operator then you can also use it in values for default param, or const

const bar = 1;
const TVal = 2;
const TVal2 = 3;
procedure foo(a: integer = 7 = bar ? TVal : TVal2);
...
const foo: integer = 7 = bar ? TVal : TVal2;

Which is hard enough to read. The meaning of the colon in the declaration block changes, if preceded by a ?

Of course the if can be made misleading too, if you break lines in the
wrong place
   foo := SomeBoolValOrExpression +
   if a= b then bar(1) else bar(2);

That's probably only because other languages use that as the ternary.

There also another reason why I prefer the variant with the if: ease to implement in the compiler.

For the if one merely needs to add a corresponding case in factor() while for the ?: one needs to fiddle with the compiler's operator precedence rules that are applied in sub_expr() which can lead to desaster either during implementation or later on when bugs are discovered...

So that's another reason why I'm inclined to this...

(Also that Algol-60 as the spiritual predecessor of Pascal has them as well is quite intriguing :) )

Regards,
Sven

No, it is because there are no keywords involved.

The keyword "If" starts a statement. It's a simple rule.

As I said: by using "if" in an expression, you break the rule and introduce ambiguity.

I don't see how the use of "if" differs from "?" in rules of precedence, they are at the exact same level. They're both just tokens to the compiler.
At least "?" has the advantage of being new and not yet used, so is unambiguously.

Michael.

Jonas, what's your take on this as an overall language guru?

they are at the exact same level.

They're both just tokens to the compiler. At least "?" has the advantage

of being new and not yet used, so is unambiguously.

The tokens themselves are merely tokens to the compiler, but you need to ensure that expressions like "a + b ? c : d + e" are handled correctly by the compiler (and right now I don't even care what the rules would be exactly, only /that/ they need to be).
Though thinking about it one could maybe add the check for the ?-token to the end of factor(), that should hopefully cover all cases... :/ (this does however not mean that I support the syntax ;) )

Regards,
Sven

The only Pascal way is

 left := IfThen(expr1, expr2, expr3)

Similar to addr(), sizeof(), length(), write() and recently added Default() in intrinsic.
I guess functions declared in Math unit are not covering all the needs (since type of expr2, expr3) may vary.
That's why a bit of compiler support is needed.

thanks,
Dmitry

The main reason compiler support is needed is that Expr3 must not be evaluated if expr1 is true, and expr2 must not be evaluated if expr1 is false, at least if you want the ternary semantics. (as once explained to me by Sven himself...)

I'm not sure this kind of semantics is possible with a compiler intrinsic... But if it is: In that case the IfThen or IIF() or somesuch has my absolute top preference, followed by ternary. (and the If .. then expression should be blasted to hell ;) )

Michael.

On Fri, Oct 9, 2015 at 2:30 PM, Michael Van Canneyt wrote:

I'm not sure this kind of semantics is possible with a compiler intrinsic...

But if it is: In that case the IfThen or IIF() or somesuch has my absolute top preference, followed by ternary. (and the If .. then expression should be blasted to hell ;) )

Here's an example:

uses sysutils;
var
  a,b : integer;
begin
  a:=1;
  b:=5;
  assert(a=0, 'error: '+intTostr(b));
end.

compiled with (2.6.4) fpc -al -Sa testassert.pas

Looking at the assembler code, a=0 is evaluated first. If it's true, the code is passed to the next line after assert, w/o evaluating 'error '+intToStr(b).

Looks like a good example of conditional intrinsic supported by compiler to me.

thanks,
Dmitry

On Fri, Oct 9, 2015 at 2:45 PM, Dmitry Boyarintsev <

And that's the reason why assert() was invented and people love it... as well as -Sa :)

thanks,
Dmitry

Default()

evaluated if expr1 is true, and expr2 must not be evaluated if expr1 is false, at least if you want the ternary semantics. (as once explained to me by Sven himself...)

I'm not sure this kind of semantics is possible with a compiler

intrinsic...

But if it is: In that case the IfThen or IIF() or somesuch has my

absolute top preference, followed by ternary. (and the If .. then
expression should be blasted to hell ;) )

Yes a compiler intrinsic could handle that. In the end all three syntaxes are the same code representation anyway: namely an if-node. The IfThen() intrinsic would be fine with me as well. Let's call this our common ground ;)

Regards,
Sven

"MohsenTi" wrote

Thank you Sven, is there any documentation about freepascal compiler parts ?

Nope, sorry. It's mainly learning by doing or maybe learning by debugging...

Regards,
Sven

I wonder if replacing Ifthen() inline function, with a common intrinsic keeps the compatibility.

Just because it is "inline" in the end, the generated code forced the proper order of valuation: condition goes first at then the proper expression.

However, "inline" is just a hint, rather than a rule for the compiler. And if there's a place, where the function was not inlined, then the compatibility might break.
... causing to think about a different name.

thanks,
Dmitry

Agreed !

Michael.

Am 09.10.2015 23:11 schrieb "Dmitry Boyarintsev" <

: On Fri, Oct 9, 2015 at 5:04 PM, Sven Barth

> > Yes a compiler intrinsic could handle that. In the end all three

syntaxes are the same code representation anyway: namely an if-node.

> The IfThen() intrinsic would be fine with me as well. Let's call this

our common ground ;)

I wonder if replacing Ifthen() inline function, with a common intrinsic

keeps the compatibility.

One could force the correct behavior, because the intrinsic is in System while the inline function AFAIK isn't. Thus one could prefix the unit name if needed.

Regards,
Sven

It would be even better if it could be generalised to evaluate and return one of any number of expressions.

Am 10.10.2015 10:51 schrieb "Mark Morgan Lloyd" <

syntaxes

>> are the same code representation anyway: namely an if-node. >> The IfThen() intrinsic would be fine with me as well. Let's call this

our

one of any number of expressions.

How do you think that could look like? IfThen() is the wrong intrinsic for this and for a CaseOf() intrinsic you'd nevertheless need the case labels. And /then/ I agree with Ralf that it isn't understandable...

Regards,
Sven

I had the same thought. The only case I see applicable is an ordinal. CaseOf(a, ord(a)=0, ord(a)=1, ord(a)=2...)
Still it seems somewhat convoluted.

Michael.

Two possibilities that I can see. The first would be a variable or expression followed by an array of corresponding expressions, implicitly zero-based:

left := CaseOf(a, [b, c, d]);

The second would be an array of tuples, each a predicate followed by an expression, with the predicates evaluated left-to-right until one is true.

In either case there would have to be explicit rules as to what happened if the variable was out of range or no predicate evaluated true: I don't know whether it would be feasible to have a final optional flags element to determine this sort of thing, or if this is moving too far from what could reasonably be called a syntax structure.

One thing that bothers me about these approaches is that sooner or later some awkward cuss (such as myself) will start whining about how much better Pascal would be if there were a decent macro preprocessor so that CaseOf() could be specialised into other forms expressing choice :-/

I'd add that historically, extended ALGOLs had if-then-else inline but put anything with more elements (e.g. tables of labels) into the declarations at the start of a block. However my reading of the manuals suggests that they might have been inconsistent about whether the first element was indexed 0 or 1.

Mark Morgan Lloyd wrote

One thing that bothers me about these approaches is that sooner or later some awkward cuss (such as myself) will start whining about how much better Pascal would be if there were a decent macro preprocessor so that CaseOf() could be specialised into other forms expressing choice :-/

[aside]
years ago when i was working with TP3 and then later TP/BP6&7, i wrote a macro preprocessor for use with my code... basically i coded in .tpl (template) files where i needed macros and then my preprocessor would read the .tpl files and output .pas or .inc files with the macros altered to the real desired data... i did this especially with the date and time of the compile so that it was included in the binary and could be displayed when desired... there were other use cases where this came in very handy... unfortunately it was a down'n'dirty tool that needed to be customized for each project i worked on... i've no clue where that code is today :(
[/aside]

Hi

I added new keyword to moderate while - else (otherwise) new codes is

Ex1:
while( I>5 ) do begin Dec(I); write(I); end otherwise write(' otherwise while ');

Ex2:
if (I<10) then while( I>5 ) do begin Dec(I); write(I); end otherwise write(' otherwise while ') else write(' IF ELSE ');

I need help to implement it
I added more info needed by compiler ,but I don't know what is executionweight in pass_generate_code function of tcgwhilerepeatnode class I check other classes and functions ;like (if,for,exit) node pass_generate_code ,but I can't find relation between executionweight and while.

please define it for me!

Thanks a lot.

MohsenTi wrote

I added more info needed by compiler ,but I don't know what is executionweight in pass_generate_code function of tcgwhilerepeatnode class

The executionweight is used to determine how often a particular node will be executed. The higher the value, more often it will be executed, according to the compiler. This value is used to determine which variables the compiler should try to keep in registers.

Jonas

Would one of the moderators of the system remove me from the fpc lists.

My days of freepascal are over.

Now its C++11 plus Qt plus golang ==> my future.

Thanks for all your efforts across many years.

Good luck.

md

Would one of the moderators of the system remove me from the fpc lists.

There is a link at the bottom of every message that comes from the lists that allows you to do so yourself.

Jonas
FPC mailing lists admin

It does not work, I have tried. I never receive the confirmation email.

In our previous episode, Dmitry Boyarintsev said:

The only Pascal way is left := IfThen(expr1, expr2, expr3)

I also think intrinsic pseudo function syntax would be best, evaluating only one expression. Because that is the primary purpose of the ternary.

Making it an operator is just C copycatting, and only secondary purpose if at all (since I don't see what operator syntax would improve extra).

In our previous episode, Michael Van Canneyt said:

(ifthen clashes name with the delphi functions of the same name in a much used unit as math, the name should be different but the intrinsic principle IMHO is best)

Marco van de Voort wrote

(ifthen clashes name with the delphi functions of the same name in a much used unit as math, the name should be different but the intrinsic principle IMHO is best)

But they're inline functions. Thus when inline-d into the code, they're acting as intrinsic.

Also, even if they're not inlined, the existing code would break, because use of "Math" comes after use of "system". Thus Math's IfThen() would be used instead of system intrinsic.

The same applies for any other user's variants of IfThen that could have been written.

thanks,
Dmitry

In our previous episode, Dmitry Boyarintsev said:

Are they? It sounds dangerous to me that inlining would suddenly not evaluate functions anymore.

The delphi ifthen is just a shorthand as an conversion aid where evaluation requirements are not too complex.

"Marco van de Voort" wrote

In our previous episode, Dmitry Boyarintsev said: > On Mon, Oct 12, 2015 at 4:01 PM, Marco van de Voort

> > > (ifthen clashes name with the delphi functions of the same name in a

much

> > used unit as math, the name should be different but the intrinsic

principle

It's should not be the case with functions, but with the right optimization settings the compiler might optimize away statements/expressions that otherwise would have generated exceptions.

Regards,
Sven

IIF ?

Michael.

syntaxes

>>> are the same code representation anyway: namely an if-node. >>> The IfThen() intrinsic would be fine with me as well. Let's call this

our

principle

> IMHO is best) IIF ?

As someone else already wrote name clashes shouldn't be a problem as Math is always used after System and thus Math.IfThen takes precedence.

Regards,
Sven