Wishlist for future development

[Leledumbo]

Which part of my statement applies to case #2?

In case #2 you can spend a lot of time developing the product, but in the end it might fail, just because the dependency fails. What if Apple changes iPhone UI structure completely? - you'll have to spend extra time updating the software. What if iPhone leaves the marked? - your the application is deprecated.

The reason why Symbian port didn't make it. Everything changes, you can choose to stay compatible or leave. No problem. GTK1 was the first Lazarus interface, now it is deprecated in favor of GTK2. GTK3 is on its way.

Another thing: don't forget that even developing for Android with FPC either SDK/NDK will be used! Why not to write our own Android platform (Cheetahoid)? Sounds crazy? risky? stupid? interesting?

Wanna do it? Feel free. Note that in case of FPC through arm-android target only needs assembler, linker and platform libraries. That's the same as the desktop targets. The SDK is required only to build the APK and debug it.

So taking the same approach for other tools (interface builder) also make sense

Again, feel free to do it if you can, but you won't ever make it to the source code repository. There are times when we have to invent our own, and there are times when we have to integrate with existing one. FPC used to use GNU as/ld exclusively, but seeing its overhead the plan began to write internal assembler and linker, which now exists for win32/64, dos and bsd targets. If Lazarus decided to build its own GUI backend when it was first launched, I don't think it will ever be as big as now.

[mse]

If you like to participate, MSElang is on the way:
https://gitorious.org/mseide-msegui/pages/Mselang

Martin

[avra]

try
  ...
except
  ...
finally
  ...
end;

[Edson]

if ... then
  ...
elsif ... then
  ...
else
  ...
end;

[eric]

if ... then
  ...
elsif ... then
  ...
else
  ...
end;

This discussion is getting ridiculous. You can already do that:

if ... then
  ...
else if ... then
  ...
else
  ...

(no 'end' required)

[Edson]

Not. Currently we have to do:

Code: [Select]

if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
    ...
  end  //DANGER: Don't put semicolon!!!!!
else if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
  ...
  end  //DANGER: Don't put semicolon!!!!!
else
  begin  //WARNING: the same before.
   //some code
  end;  //DANGER: Put semicolon!!!!!

Or, formally:

Code: [Select]

if ... then
   begin 
      ...
   end 
else
   if ... then
      begin
         ...
      end
   else
      begin
         ...
      end;

@mse:
The project seems to be magnificent!!!
The "Thoughts for a future syntax" section, have many of my Wishlist and more. It really looks a modern Pascal syntax. There is a lot of question, I have.

[jwdietrich]

Not. Currently we have to do:

Code: [Select]

if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
    ...
  end  //DANGER: Don't put semicolon!!!!!
else if ... then
  begin  //WARNING: If use more than a sentence, you need BEGIN-END
  ...
  end  //DANGER: Don't put semicolon!!!!!
else
  begin  //WARNING: the same before.
   //some code
  end;  //DANGER: Put semicolon!!!!!

Or, formally:

Code: [Select]

if ... then
   begin 
      ...
   end 
else
   if ... then
      begin
         ...
      end
   else
      begin
         ...
      end;

@mse:
The project seems to be magnificent!!!
The "Thoughts for a future syntax" section, have many of my Wishlist and more. It really looks a modern Pascal syntax. There is a lot of question, I have.

Yes! The current Pascal syntax is consistent and logical. Other implementations would lead to ambiguities.

[skalogryz]

Not. Currently we have to do:

You can save some lines in the following manner, by having all reserved words (for if, else, begin, end) in a single line.
It might also give you a better code perception too.

Code: [Select]

if ... then begin 
   ...
end else if ... then  begin 
   ...
end else begin 
   ...
end; 


[marcov]

Yes! The current Pascal syntax is consistent and logical. Other implementations would lead to ambiguities.

Or not Pascal anymore. (but e.g. M2). I still think the M2 syntax better (what MSElang seems to do)(, but while it is better, the existing codebases  (both own and 3rd party) for Delphi/Pascal simply are more important than micromanaging language details.

[avra]

try
  ...
except
  ...
finally
  ...
end;

The point of my proposal is that current syntax does not allow both except and finally together as mentioned above, which makes me using multiple try/except/end and try/finally/end, making code less readable. Readability can be much improved with my proposal, and it follows Pascal spirit.

I would not expect it to work in DELPHI compatibility mode, but I would expect it to work with FPC and/or OBJFPC mode.

[Edson]

@avra: Totally agree. But maybe it should be:

Code: [Select]

try
   ...
except
   ...
else
   ...
finally
   ...
end;

I still think the M2 syntax better (what MSElang seems to do)

I agree too. (If we are talking about the same M2 )

It seems that, Niklaus Wirth realize that the BEGIN ... END, could be problematic in the syntax.  That's why he change the syntax of structs in Modula-2:

Code: [Select]

WHILE ... DO       
   ...
END;

FOR i := 1 TO 5 DO
   ...
END;

IF ... THEN             
   ...
ELSIF ... THEN
   ...
ELSE
   ...
END;
Simply, beatifull.

[marcov]

I agree too. (If we are talking about the same M2 )

Modula2 yes. I migrated from that to FPC in 97-98, mostly because the community was too small, and some (specially the more multiplatform ones) were awkward (and then I'm stating it mildly)
Decided if I had to convert Pascal (then TP, now it would be Delphi) code any time I needed some trivial piece of code, I might as well use Pascal. Never looked back. 

[sam707]

try
try
  for i:=1 to 3 do
    RegisterOnMseForum;
except
  On ERejectError do
    Abandon;
end;
finally
 Abandon;
end;

got it? 

[Leledumbo]

@avra: Totally agree. But maybe it should be:

finally block is NOT else part of the except block, read up how they work.

[Edson]

@avra: Totally agree. But maybe it should be:

finally block is NOT else part of the except block, read up how they work.

???
I'm talking about have and exception struct similar to Python.