Hello,

REM Objects released an interesting document regarding some changes (that looks so much like Ruby) to their Delphi Prisem.

For example assignment of a value regarding a condition:

x := if Something then 2;
y := case Other of
         bla : 'hello';
         foo : 'bye';
         baz : 'adius';
       end;

And more.
You can find more in http://blogs.remobjects.com/blogs/mh/2010/02/18/p1116

Ido
http://ik.homelinux.org/

What do you gain with this?
Doesn't look much different to

case Other of
   bla : y := 'hello';
   foo : y := 'bye';
   baz : y := 'adius';
   end;

Shorter write imho.

In our previous episode, ik said:

> Shorter write imho.

Or something easily marketable to make people upgrade. Not a problem of FPC.

Is that realy a reason for adding yet another extension to Pascal? This is C thinking. I don't care about a word more or less to write if only the *reading* of source code is easy (and the logic of the language is clear). But each variant in writing makes it harder to understand a source code (especially for newbies to whom the learning curve gets steeper and steeper with each of such 'extensions').

Which also means "less chance of mistake". For example, if you decide later to change "y" to "y1", you only have to change the code in one place, not three. Functional "case" and "if" are not only from Ruby, also from all functional languages (sml, ocaml), also Python and even C have functional "if".

I'm not saying that this is some revolutional or essential feature. But just because "we can work without it" doesn't mean it's totally useless :)

Michalis

Does this innovation makes "case" a function?

procedure SomeProc(const v: string);
SomeProc (  case Other of
                        a: 'a';
                        b: 'b';
                   end; );

Imho, this reduces the code readability.

thanks,
dmitry

In our previous episode, dmitry boyarintsev said:

Does this innovation makes "case" a function?

I'd rather say an expression.

Even if you are a favorite of said functionality, it should not be added adhoc, but integrated in the language definition. (but that would mean it is no longer Pascal).

I don't see the use either. Moreover the benefit/cost (work) is way to high IMHO

Michalis Kamburelis wrote

Which also means "less chance of mistake". For example, if you decide later to change "y" to "y1", you only have to change the code in one place, not three.

Unfortunately you are wrong Michalis. Ever heard of 'syncron-edit'?

http://wiki.freepascal.org/New_IDE_features_since#Syncron-Edit

You only need to change one variable, and all other instances will change to. And syncron-edit applies to any selection of text. So already works in more cases.

I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners.

Graeme Geldenhuys wrote

I vote against adding this language feature. It's not pascal-like and actually makes the code harder to read. It also only applies to simple assignment. Case begin..end blocks can do much more than simple oneliners.

Maybe some-one would like to catch-up with Delphi/Prism? Wouldn't be possible to start a Prism mode to support new Delphi syntax features? (or modeswitch, just like objectivec)?

I don't volunteer :) I'm happy with the present FPC syntax.

thanks,
dmitry

In our previous episode, dmitry boyarintsev said:

IMHO Prism is not even Delphi. Just recycling of the brand.

I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode).

If a feature is not supported by delphi, the usage is usually very low (since most people don't even know about it, and some are limited by compatibility requirements), except in the rare cases that it is really used a lot (like in the past the pointer overindexing and the exit() features. But they are no longer extensions, since D2009 Delphi has them too)

Marco van de Voort wrote

I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode).

+1

Which is cool, but only if you and all your contributors use Lazarus for all your editing. The fact that Lazarus makes something easier should not be a reason to reject the language feature.

This is a matter of taste, I can imagine uses when at least functional "if" would make code *more* readable. Noone forces programmers to convert all their case/if to functional versions if they look unreadable. The functional variants are supposed to be used in particular situations, when they make sense.

Mind you, I'm not saying I'm a fan or a big proponent of this feature. I do not own Delphi since a long time, being happy with FPC, so I'm also not interested in compatibility.

Mostly, I'm playing devil's advocate here :), and I didn't see yet a good argument against this feature (and I see cases when it would be useful). The fact that it makes some cases less readable doesn't count here imho (because it's optional, and can make other code more readable).

Michalis

In our previous episode, Michalis Kamburelis said:

It also proves that such solution external to the language is possible. That weakens the case for a language feature

That is always the reason, but every feature must be implemented tested, supported, and may clash with future extensions.

"it wouldn't hurt", and a bit of typing, and some fairly theoretic case about readability are IMHO quite weak arguments.

Hello FPC-Pascal,

Sunday, February 21, 2010, 7:29:54 PM, you wrote:

MK> This is a matter of taste, I can imagine uses when at least functional MK> "if" would make code *more* readable. Noone forces programmers to MK> convert all their case/if to functional versions if they look MK> unreadable. The functional variants are supposed to be used in MK> particular situations, when they make sense.

For me the bigger problem is that both statements change its behavior in function of its context.

if a=b then 1 else 2;

this is a pascal error, but

z := if a=b then 1 else 2;

Is it correct ? From my point of view is much more reasonable to use something like:

z := iff(a=b,1,2);

But to me it looks awful and a bit of c-ism and really horrible code could be written:

z: Boolean;
begin
z := iff(a=b,iif(b=2,a=b,ba),not(a=b));

On Sun, 21 Feb 2010 20:37:12 +0100, JoshyFun wrote about Re[2]: [fpc-pascal] some new features to delphi prisem:

That is an attempt at a statement, but what is being offered in Prism is an enhanced *expression* syntax.

this is a pascal error, but z := if a=b then 1 else 2;

This is actually valid ALGOL 60 and/or ALGOL 68. Conditional expressions were available in both languages. I think Niklaus Wirth continued with this in ALGOL W, but dropped it from Pascal.

Note that the ALGOLs required the "else" clause, as does C today (see below).

Is it correct ? From my point of view is much more reasonable to use something like: z := iff(a=b,1,2);

This is over-punctuated Visual BASIC. Yuck.

Mega-yuck!!

I can only infer that you don't write C. The C equivalent is:

   z = a == b ? 1 : 2;

It's terse, but one gets used to it.

Hello FPC-Pascal,

Sunday, February 21, 2010, 9:32:50 PM, you wrote:

DWN> This is actually valid ALGOL 60 and/or ALGOL 68. Conditional DWN> expressions were available in both languages. I think Niklaus Wirth DWN> continued with this in ALGOL W, but dropped it from Pascal. DWN> Note that the ALGOLs required the "else" clause, as does C today (see DWN> below).

I'm the opposite of an compilers expert, also never learned Algol, modula, eiffel or non "main-stream" languages, except Forth. So I known my opinion is not an expert opinion, just an opinion only.

After this preamble :) I must say that this is Pascal, not Algol ;)

> Is it correct ? From my point of view is much more reasonable to use > something like: > z := iff(a=b,1,2);

DWN> This is over-punctuated Visual BASIC. Yuck.

iff is valid in VB ? Just a coincidence, I was trying to note the "if-function".

DWN> Mega-yuck!!

I even do not know the result :)

DWN> I can only infer that you don't write C. The C equivalent is:

Oh yes, I write and wrote C/C++ that's the reason I hate such things, like:

if (a=a++==a) {......}

It's a funny entertainment to try to know which exactly that condition will execute.

DWN>    z = a == b ? 1 : 2;
DWN> It's terse, but one gets used to it.

In near 20 years I was unable to find the reason and need of such constructions, even when my first computer only have 3 Kb for source code.

Sent from my iPhone

JoshyFun wrote

z := iff(a=b,1,2); But to me it looks awful and a bit of c-ism

No, that is a VB-ism. A C-ism would be:

z = (a==b ? 1 : 2);

Which I fo tend to use myself in c# as it is a lot more convenient in some cases.

Marco van de Voort wrote

IMHO Prism is not even Delphi. Just recycling of the brand.

+1

I'd rather see the time spent on features that really matter (like generics, SEH/COM support, unicode).

Definitely. I would like to add 'Interface Delegation' to that list. It's a vital part of Interfaces that is not implemented in FPC yet.

Regards,
- Graeme -

Marco van de Voort wrote

It also proves that such solution external to the language is possible. That weakens the case for a language feature

My point exactly! The language doesn't need such a feature because your editor of choice should be able to do that, and in Lazarus IDE that is the case.

Regards,
- Graeme -

This is unrelated though. Refactoring has its place, but is absolutely specific to a single IDE. If one never intends to use that IDE, the functionality is gone. I don't care for the feature either, but I can also see why it would be desirable over mechanical string replacement, no matter how advanced.

Marco van de Voort wrote

IMHO Prism is not even Delphi. Just recycling of the brand.

Laying cards on the proverbial table, I don't think it was ever intended to be Delphi. RemObjects developed the compiler completely outside of Delphi for a number of years before the technology was licensed to become Prism. Fact. IIRC, they billed "Chrome" (then Oxygen) as a Pascal-like syntax refined for the .Net framework. It was the Codegear/Embarcadero licensing that first created Delphi Prism.

The syntax that Prism uses is a lot cleaner in many respects - especially removing the "procedure"/"function" conundrum and using instead "method". However, in other ways it is horrible and so I can also see why it is not something worth discussing further.

The syntax that Prism uses is a lot cleaner in many respects - especially removing the "procedure"/"function" conundrum and using instead "method". However, in other ways it is horrible and so I can also see why it is not something worth discussing further.

Matt,

I am no Prism fan (I prefer native code). Having said that, would you care to explain the other ways in which it is horrible?

Curious

Maybe this discussion could be moved to the fpc-other list? It's not really directly applicable to FPC anymore.

Thanks,

Jonas
FPC mailing lists admin

Jonas Maebe wrote

Maybe this discussion could be moved to the fpc-other list? It's not really directly applicable to FPC anymore.

Indeed, which is why I said "[..] I can also see why it is not something worth discussing further." I guess if someone was committing to developing the compiler mode switch for the dialect, it might be a different case.

I sent a follow up before reading your email, so apologies and lips are now firmly zipped!! ;-)

In our previous episode, Matt Emson said:

No, there are multiple IDEs that support it to some extend or the other. XCode, Eclipse has had plugins in the past, Emacs (if you can find the editor in that OS)

If one never intends to use that IDE, the functionality is gone.

It's only important in ease of use and shorthand cases. If it really is functionality that is not doable otherwise, it's a different matter. Nobody will argue that a template that generates a wrapper around a container class is a substitute for generics.

IOW, for this argument, the only advantage in favour must be shorthand, or other editing work related speedup of workflow.

I don't care for the feature either, but I can also see why it would be desirable over mechanical string replacement, no matter how advanced.

I don't believe in adding shorthands solely based on such reasons. THat is a carte blanche for all kinds of char twiddling non improvmeents.

And in this case IMHO it is a specialisation of CASE, which is already an specialization of nested if then.

If we implement that, we'll get the next level of specialization within the year probably, and probablyagain with similar argumentation

In our previous episode, Matt Emson said:

Correct.

The syntax that Prism uses is a lot cleaner in many respects - especially removing the "procedure"/"function" conundrum and using instead "method". However, in other ways it is horrible and so I can also see why it is not something worth discussing further.

Good. I just want to add that not every improvement (even if a real consensus exists that it is better) is worth breaking compatibility for.

or this...
type foo_type = (bla, foo, baz);
var foo_names : array [foo_type] of string = ('hello', 'bye', 'adius');
y := foo_names[other];

Hi!

You are looking at the wrong example! Clearly, for variable assignment you don't gain anything. But for a function argument you do!

  WriteLn('The value is ',(if X then 'true' else 'false'),
          ' at the moment.');

and

  MakeBackup(FileName,ChangeExtension(FileName,
    case BackupExtension of
      exBak   : '.bak';
      exBkp   : '.bkp';
      exTilde : '~';
    else '.bak'
    End));

Bye
Hansi

You are looking at the wrong example! Clearly, for variable assignment you don't gain anything. But for a function argument you do!

Realy?

WriteLn('The value is ',(if X then 'true' else 'false'), ' at the moment.');

Well, *this* can be done much easier ;-):

-------------------------------------------
WriteLn('The value is ',X,' at the moment.');
-------------------------------------------

But even if X is not boolean I would find that much more readable:

-------------------------------------------
if X then s := 'true' else s := 'false',
WriteLn('The value is ',s,' at the moment.');
-------------------------------------------

Even with the need of an intermediate variable (most of the time you can reuse an existing variable) I would prefer this one over the quite confusing nesting of case statement in an expression. It states much clearer what happens.

Again, this would be much clearer code:

-------------------------------------------
case BackupExtension of
    exBak   : s := '.bak';
    exBkp   : s := '.bkp';
    exTilde : s := '~';
else          s := '.bak'
    End;
MakeBackup(FileName,ChangeExtension(FileName,s));
-------------------------------------------

Sent from my iPhone

Jürgen Hestermann wrote

Well, *this* can be done much easier ;-): <snip>

I think an interjection at this point is required - all of this is down to personal experience, preference and style. It is what you are used to. Having done 10+ years of Pascal, yes this is very alien. Having done 5+ years of C# and C based languages, no this is useful. Should it be part of Free Pascal? That is for the compiler maintainers to decide. However, don't write it off because you find it undesirable. One languages feature is another's bad syntax decision. I can't count the number of times I've tried to explain the point of Sets to non Pascal programmers (read: C based language users.) I also don't want to remember the countless bad implementations of Sets I saw whilst trying not to have to reinvent the wheel.

M

Your post illustrates a misunderstanding that is common today - that choices are arbitrary and equivalent and should just be decided by personal preference. There are many choices people make today that are far more serious than that. But they just dismiss them as "Its my choice. What's it to you?" This is especially common in items of convenience.

Within the philosophic principles that formed Pascal such a proposed construct is a violation. (As are some of the now accepted extensions introduced by Borland.) The principle is one of minimalism or conservation of features. The principle is: If a feature can be expressed using a reasonable expression of the current language features it is unnecessary and should be left out. Wirth did an outstanding job of adhering tot his principle. Those that followed him, not so much.

It is important when considering language changes to observe the principles and adhere to them. Their logical consistency is important to maintain for that is is the basis of the language's integrity and that, in turn, is the basis of its elegance and power.