Re: [fpc-devel] fppkg question

2011-05-10 Thread dhkblaszyk
On Tue, 10 May 2011 08:30:28 +0200 (CEST), Michael Van Canneyt 
 wrote:

On Tue, 10 May 2011, Darius Blaszyk wrote:


Hi,

I've created a trivial front end for fppkg (see lazarus mailing 
list) but working on this I realized that they are not grouped in any 
way. Currently with approx. 70 packages this is not a real problem, 
but if the system will get used more widely it will be impossible to 
deduct the purpose (and possibly other info) from the package just by 
it's name.


Therefore I would like to request a new command named "info" that 
retrieves the info for a package from packages.xml. I would also like 
to add some more info in this file for a package:


- the topic that organizes the packages (FPC core / DB / buttons / 
charts / dialogs / etc)

- keywords to make it possible to search freely
- support contact (official / community)

See the following movie on youtube on a plugin system that has some 
of these features: 
http://www.youtube.com/watch?v=d9yyJmh3dyU&feature=player_embedded


Are / were there any plans ever in this direction? Am I free to 
create a couple of patches?


It exists.

If you look at fprepos.pp :

  TFPPackage = Class(TStreamCollectionItem)
Property Name : String Read FName Write SetName;
Property Author : String Read FAuthor Write FAuthor;
Property Version : TFPVersion Read FVersion Write SetVersion;
Property License : String Read FLicense Write FLicense;
Property Description : String Read FDescription Write 
FDescription;
Property HomepageURL : String Read FHomepageURL Write 
FHomepageURL;
Property DownloadURL : String Read FDownloadURL Write 
FDownloadURL;

Property FileName : String Read GetFileName Write FFileName;
Property Email : String Read FEmail Write FEmail;
  end

The same information can be stored in the fpmake.pp file.

All this info is supposed to be output in XML format from fpmake
--manifest. fppkg picks it up and stores it in the repository.

If you want to extend it to include a category and keywords, be my 
guest.


Thanks, that was the class indeed I was looking for to extend.

Darius

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Closing bug reports or not ?

2011-05-10 Thread Mark Morgan Lloyd

Jonas Maebe wrote:

On 09 May 2011, at 12:54, Mark Morgan Lloyd wrote:

Is there a polite way for a reporter who's submitted a fix to ping 
management when the bug's not been assigned to anybody?


You can always ask about it here, or add a "ping" comment to the bug 
(the latter will put it back at the top of the list of unassigned bugs).


That was intended as a general question more than anything else, but if 
somebody could pick up my modified serial.pp at 0018946 it would be 
appreciated.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] SQLite and ftFmtBCD

2011-05-10 Thread LacaK

Hi Joost (and others also ;-),

I comment your question about 
http://bugs.freepascal.org/view.php?id=18809 here.

(because I do not know what comment here and what in bug tracker)

I see problem in fact, that AsString returns number formated using 
locale specific DecimalSeparator.
So if FmtBCD param will hold value "123456789,123456789" then this value 
will be written into SQLite3 database.


Which is IMO not very good, becuase SQL standard and also SQLite 
expects, that numeric values will always have point as decimal separator.


So my suggestion is in case of ftFMTBCD param use something like:

ftFmtBCD: begin
   str1:= BCDToStr(P.AsFMTBCD, SQLFormatSettings); //this depend on bug 
18807
   checkerror(sqlite3_bind_text(fstatement,I,pcharstr(str1), 
length(str1),@freebindstring));
 end;

or better:
ftFmtBCD: begin
   if P.AsFMTBCD.Precision > 15 then //we are out of REAL range, so we 
must bind as BLOB
   begin
 str1:=BCDTOStr(P.AsFMTBCD, SQLFormatSettings);
 checkerror(sqlite3_bind_blob(fstatement,I,pcharstr(str1), 
length(str1), @freebindstring));
   end
   else
   begin
  do1=P.AsFloat 
 checkerror(sqlite3_bind_double(fstatement,I,do1));

   end;
 end;



about SQLFormatSettings see: http://bugs.freepascal.org/view.php?id=17188
--
Other questions:
" Isn't it better to use '4' instead of 255/0 as default value for 

the scale?"
SQL standard says, that if scale is ommited then scale is 0 ... imho it 
is better to follow standard



" Isn't it better to map to a ftInteger/ftLargeInt field when size1=0?"
Yes IMHO it is better, at least because ftLargeInt (int64) can hold more 
significant digits (left to decimal point) than ftBCD (currency)

But what if user defines NUMERIC(30,0) then we have two options:
1. say "sorry" SQLite does not support this, so we map to ftLargeInt
2. or map to ftFmtBCD if (scale>4) or (precision>18)

if precision>18 then ftFmtBCD
else if scale=0 then ftLargeInt
else if scale<=4 then ftBCD
else ftFmtBCD

-Laco.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] SQLite and ftFmtBCD

2011-05-10 Thread Joost van der Sluis
On Tue, 2011-05-10 at 12:39 +0200, LacaK wrote:
> Hi Joost (and others also ;-),
> 
> I comment your question about 
> http://bugs.freepascal.org/view.php?id=18809 here.
> (because I do not know what comment here and what in bug tracker)
> 
> I see problem in fact, that AsString returns number formated using 
> locale specific DecimalSeparator.
> So if FmtBCD param will hold value "123456789,123456789" then this value 
> will be written into SQLite3 database.
> 
> Which is IMO not very good, becuase SQL standard and also SQLite 
> expects, that numeric values will always have point as decimal separator.

True.

> So my suggestion is in case of ftFMTBCD param use something like:
> 
> ftFmtBCD: begin
> str1:= BCDToStr(P.AsFMTBCD, SQLFormatSettings); //this depend on 
> bug 18807
> checkerror(sqlite3_bind_text(fstatement,I,pcharstr(str1), 
> length(str1),@freebindstring));
>   end;

I'll look at this solution. I'm a little bit confused about
SQLFormatSettings and why it was implemented as it is now. I'll have to
investigate this.

> or better:
> ftFmtBCD: begin
> if P.AsFMTBCD.Precision > 15 then //we are out of REAL range, so 
> we must bind as BLOB
> begin
>   str1:=BCDTOStr(P.AsFMTBCD, SQLFormatSettings);
>   checkerror(sqlite3_bind_blob(fstatement,I,pcharstr(str1), 
> length(str1), @freebindstring));
> end
> else
> begin
>do1=P.AsFloat 
>   checkerror(sqlite3_bind_double(fstatement,I,do1));
> end;
>   end;

This is wrong. There are some values which can't be written as floats,
but have precision<15. 

> --
> Other questions:
> > " Isn't it better to use '4' instead of 255/0 as default value for 
> the scale?"
> SQL standard says, that if scale is ommited then scale is 0 ... imho it 
> is better to follow standard

But this particular piece of code is used when an invalid value is
supplied, like 'DECIMAL(10,A)'. The case that the value is omitted is
handled elsewhere.

> > " Isn't it better to map to a ftInteger/ftLargeInt field when size1=0?"
> Yes IMHO it is better, at least because ftLargeInt (int64) can hold more 
> significant digits (left to decimal point) than ftBCD (currency)
> But what if user defines NUMERIC(30,0) then we have two options:
> 1. say "sorry" SQLite does not support this, so we map to ftLargeInt

Nah...

> 2. or map to ftFmtBCD if (scale>4) or (precision>18)
> 
> if precision>18 then ftFmtBCD
> else if scale=0 then ftLargeInt
> else if scale<=4 then ftBCD
> else ftFmtBCD

Can you create a patch which does this?

Joost

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] SQLite and ftFmtBCD

2011-05-10 Thread LacaK



I'll look at this solution. I'm a little bit confused about
SQLFormatSettings and why it was implemented as it is now. I'll have to
investigate this.
  
IMO for locale independent formatting numeric, date, time values 
according to sql standard


  

or better:
ftFmtBCD: begin
if P.AsFMTBCD.Precision > 15 then //we are out of REAL range, so we 
must bind as BLOB
begin
  s   tr1=BCDTOStrP.AsFMTBCD,SQLFormatSettings);
  checkerror(sqlite3_bind_blob(fstatement,I,pcharstr(str1), 
length(str1), @freebindstring));
end
else
begin
   d o1=P.AsFloat
  checkerror(sqlite3_bind_double(fstatement,I,do1));
end;
  end;



This is wrong. There are some values which can't be written as floats,
but have precision<15. 
  

Yes, then my mystake then we can/must use:

ftFmtBCD: begin
   str1:=BCDTOStr(P.AsFMTBCD,SQLFormatSettings);
   //bind as BLOB, because when bind as TEXT, SQLite always will 
convert to REAL or INTEGER,
   //which can lead to lost of precision
   checkerror(sqlite3_bind_blob(fstatement,I,pcharstr(str1), 
length(str1), @freebindstring));
 end;




But this particular piece of code is used when an invalid value is
supplied, like 'DECIMAL(10,A)'.
yes, in this case we can default to 4 (but A as scale is in all cases 
something very strange)



 The case that the value is omitted is
handled elsewhere.
  

ok, in this case we should use 0

  

" Isn't it better to map to a ftInteger/ftLargeInt field when size1=0?"
  
Yes IMHO it is better, at least because ftLargeInt (int64) can hold more 
significant digits (left to decimal point) than ftBCD (currency)

But what if user defines NUMERIC(30,0) then we have two options:
1. say "sorry" SQLite does not support this, so we map to ftLargeInt



Nah...

  

2. or map to ftFmtBCD if (scale>4) or (precision>18)

if precision>18 then ftFmtBCD
else if scale=0 then ftLargeInt
else if scale<=4 then ftBCD
else ftFmtBCD



Can you create a patch which does this?
  

Yes, tomorow I will do it

Laco.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: Can't compile at revision: 17417

2011-05-10 Thread Marcos Douglas
On Mon, May 9, 2011 at 5:38 PM, Joerg Schuelke  wrote:
> Am Mon, 9 May 2011 17:23:30 -0300
> schrieb Marcos Douglas :
>
>> > I use /fixes_2_4 but I could not to compile (error in first mail).
>> > So, I took a look in sources from /trunk. I compared this files
>> > (odbcsql) and saw this difference between them (the patch).
>>
>
>> Did you understand?
>
> I think there are two possibilities:
> 1)      During shutdown (shut off) something in your file system went
>        wrong. You should 'svn up' again.
>        Maybe svn can correct the error, or gives you a hint.
> 2)      It is windows related. For me all works fine. But i´m using
>        linux.

In WinXP, with TortoiseSVN I did:
- Deleted directory packages\odbc
- Clean UP
- Updated

I use /fixes_2_4...

To compile I use a BAT (always worked):
-
@echo on
set myroot=W:\dev\freepascal
set myFPC=%myroot%\compiler\2.4.3
set mybinutils=%myroot%\binutils
set PATH=%mybinutils%\i386-win32;%myFPC%\bin\i386-win32;%PATH%

cd %myFPC%
rd /s /q  %myfpc%\examples

make clean all install INSTALL_PREFIX=%myFPC% PP=%mybinutils%\ppc386.exe
-

Now works!

Thanks Joerg.

Marcos Douglas

PS: BTW, what the difference (at least on Win) to use option "install"
in 'make'?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: Can't compile at revision: 17417

2011-05-10 Thread Joerg Schuelke
Am Tue, 10 May 2011 11:11:22 -0300
schrieb Marcos Douglas :

> PS: BTW, what the difference (at least on Win) to use option "install"
> in 'make'?

Thats not windows related, make works the same way on all platforms.
The arguments for make are:
- options for make himself
- targets (which parts of code to build)
- variable definitions (which may modify the making of the targets)

There are some commonly used targets with self explaining names
- clean (tries to delete all during the build process generated files)
- all (builds all targets -if you have more than one-)
- install (installs the former build targets)

If you want to know more about how make works, look for documentation.
There is a lot of.

There is somewhere a doc about the fpc build process, google for "fpc
build faq".

I think that is not development related, if you have more questions it
may be better to visit a forum or the general fpc-pascal mailing list.

Regards
Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Re: Can't compile at revision: 17417

2011-05-10 Thread Marcos Douglas
On Tue, May 10, 2011 at 11:55 AM, Joerg Schuelke  wrote:
> Am Tue, 10 May 2011 11:11:22 -0300
> schrieb Marcos Douglas :
>
>> PS: BTW, what the difference (at least on Win) to use option "install"
>> in 'make'?
>
> Thats not windows related, make works the same way on all platforms.
> The arguments for make are:
> - options for make himself
> - targets (which parts of code to build)
> - variable definitions (which may modify the making of the targets)
>
> There are some commonly used targets with self explaining names
> - clean (tries to delete all during the build process generated files)
> - all (builds all targets -if you have more than one-)
> - install (installs the former build targets)
>
> If you want to know more about how make works, look for documentation.
> There is a lot of.
>
> There is somewhere a doc about the fpc build process, google for "fpc
> build faq".
>
> I think that is not development related, if you have more questions it
> may be better to visit a forum or the general fpc-pascal mailing list.

OK, thank you.

Marcos Douglas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Declare variables inside the code

2011-05-10 Thread kingbiz...@gmail.com
*I have been playing on other languages sometimes and I see some 
features that speed-up a lot the code creating. I'm posting here one, I 
want to see what you think about it.

*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language

/*method* MyMethod;
*var* A, B: Integer;
*begin
*
{ Simple sample of a variable inside the method begin/end near to a 
for-loop }

*var* I: Integer;
*for* I := a *to* b *do*...

{ Or even }
*for* *var* J: Integer := a *to* b *do*...
{ This is normal on languages like C++ and Java }

/*/end;/
*
*What do you think about*?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Joerg Schuelke
Am Tue, 10 May 2011 13:26:59 -0300
schrieb "kingbiz...@gmail.com" :

> *Good:* fast algorithm testings, code creating
> *Bad?:* not a standard of the pascal language

Thats a bad idea. It is completely against the basic structure of
pascal. Other Languages have other paradigms.

For example C++. There is no distinction between declaration and
statement in C++.
The declaration is a statement. But not so in pascal.

If you change this, it is all about to be changed and you get a C++
with pascal-reserved words. Thats ugly.

Thats useless.

Best regards
Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Vincent Snijders
2011/5/10 kingbiz...@gmail.com :
> I have been playing on other languages sometimes and I see some features
> that speed-up a lot the code creating. I'm posting here one, I want to see
> what you think about it.
>
> Good: fast algorithm testings, code creating
> Bad?: not a standard of the pascal language
>
> method MyMethod;
> var A, B: Integer;
> begin
>
> { Simple sample of a variable inside the method begin/end near to a for-loop
> }
> var I: Integer;
> for I := a to b do...
>
> { Or even }
> for var J: Integer := a to b do...
> { This is normal on languages like C++ and Java }
>
> end;
>
> What do you think about?

To speed up code creation, use an IDE:
http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Variable_Declaration_Completion

Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Macro Patch

2011-05-10 Thread Joerg Schuelke
This third revision with additional %FUNC% macro and 'unknown' strings
changed to internalerror.

Regards
Jörg
Index: scanner.pas
===
--- scanner.pas	(Revision 17417)
+++ scanner.pas	(Arbeitskopie)
@@ -237,7 +237,7 @@
   systems,
   switches,
   symbase,symtable,symtype,symsym,symconst,symdef,defutil,
-  fmodule;
+  procinfo,fmodule;
 
 var
   { dictionaries with the supported directives }
@@ -1712,11 +1712,33 @@
  hs:=getdatestr
else
 if hs='FILE' then
- hs:=current_module.sourcefiles.get_file_name(current_filepos.fileindex)
+ begin
+   hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+   if assigned(hp) then hs:=hp.name^ else internalerror(201105101)
+ end
else
 if hs='LINE' then
- hs:=tostr(current_filepos.line)
+ begin
+   hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+   if assigned(hp) then hs:=tostr(hp.saveline_no) else internalerror(201105102)
+ end
else
+   if hs='PATH' then
+begin
+  hp:=ascend_from_macros(current_module.sourcefiles.get_file(current_filepos.fileindex));
+  if assigned(hp) then hs:=hp.path^ else internalerror(201105103);
+  if hs='' then hs:=CurDirRelPath(target_info)
+end
+   else
+   if hs='FUNC' then
+begin
+  if assigned(current_procinfo) then
+   if assigned(current_procinfo.procdef) then
+if assigned(current_procinfo.procdef.procsym) then
+  hs:=current_procinfo.procdef.procsym.realname
+else internalerror(201105104);
+end
+   else
 if hs='FPCVERSION' then
  hs:=version_string
else
@@ -3473,7 +3495,7 @@
mac.is_used:=true;
inc(yylexcount);
insertmacro(pattern,mac.buftext,mac.buflen,
- mac.fileinfo.line,mac.fileinfo.fileindex);
+ current_scanner.line_no,current_scanner.inputfile.ref_index);
  { handle empty macros }
if c=#0 then
  reload;
Index: fmodule.pas
===
--- fmodule.pas	(Revision 17417)
+++ fmodule.pas	(Arbeitskopie)
@@ -235,6 +235,7 @@
 function get_source_file(moduleindex,fileindex : longint) : tinputfile;
 procedure addloadedunit(hp:tmodule);
 function find_module_from_symtable(st:tsymtable):tmodule;
+function ascend_from_macros(f:tinputfile) : tinputfile;
 
 
 implementation
@@ -336,6 +337,13 @@
   end;
 
 
+function ascend_from_macros(f:tinputfile) : tinputfile;
+  begin
+while assigned(f) and f.is_macro do f:=f.next;
+ascend_from_macros:=f;
+  end;
+
+
 procedure addloadedunit(hp:tmodule);
   begin
 hp.moduleid:=loaded_units.count;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Hans-Peter Diettrich

kingbiz...@gmail.com schrieb:
  *I have been playing on other languages sometimes and I see some 
features that speed-up a lot the code creating. I'm posting here one, I 
want to see what you think about it.

*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language

/*method* MyMethod;
*var* A, B: Integer;
*begin
*
{ Simple sample of a variable inside the method begin/end near to a 
for-loop }

*var* I: Integer;
*for* I := a *to* b *do*...

{ Or even }
*for* *var* J: Integer := a *to* b *do*...
{ This is normal on languages like C++ and Java }

/*/end;/
*
*What do you think about*?


This could be made compatible with the FPC handling of Body, where e.g. 
a program or a procedure body is a Body, parsed by tcgprocinfo.parse_body().


The only required parser modification had to treat a For statement as a 
Body, with an (optional) specialized Var section at its begin, and a 
Statement after Do.



But this solution would look strange to C coders, which expect variable 
declarations *after* the begin of an block, while Pascal expects local 
variables declared *before* the begin of an block. OTOH I don't think 
that it would be a big deal to allow for Pascal declarations also at the 
begin of an block. The syntax would look like:


Block = "BEGIN" [Declarations] {Statement} "END" .

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread kingbiz...@gmail.com

Em 10/05/2011 18:50, Hans-Peter Diettrich escreveu:

kingbiz...@gmail.com schrieb:
  *I have been playing on other languages sometimes and I see some 
features that speed-up a lot the code creating. I'm posting here one, 
I want to see what you think about it.

*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language

/*method* MyMethod;
*var* A, B: Integer;
*begin
*
{ Simple sample of a variable inside the method begin/end near to a 
for-loop }

*var* I: Integer;
*for* I := a *to* b *do*...

{ Or even }
*for* *var* J: Integer := a *to* b *do*...
{ This is normal on languages like C++ and Java }

/*/end;/
*
*What do you think about*?


This could be made compatible with the FPC handling of Body, where 
e.g. a program or a procedure body is a Body, parsed by 
tcgprocinfo.parse_body().


The only required parser modification had to treat a For statement as 
a Body, with an (optional) specialized Var section at its begin, and a 
Statement after Do.



But this solution would look strange to C coders, which expect 
variable declarations *after* the begin of an block, while Pascal 
expects local variables declared *before* the begin of an block. OTOH 
I don't think that it would be a big deal to allow for Pascal 
declarations also at the begin of an block. The syntax would look like:


Block = "BEGIN" [Declarations] {Statement} "END" .

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


This already help, but what about declaring also after some code?

I like on Java/C++/PHP that I can create a for-loop that creates the 
counter... sample on PHP:


for(var; condition; step) for($var=0; $var<1000; $var += 1)

This syntaxe is possible on C++, Java (its not equal, but its something 
very close).


I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Joerg Schuelke
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich :

> The syntax would look like:
> 
> Block = "BEGIN" [Declarations] {Statement} "END" .

Yea, it looks like C, but it is not. The difference in C like languages
is that an declaration is just a kind of statement. Without this, I
think it makes no sense. But then you code C-like with pascal keywords.

Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread kingbiz...@gmail.com

Em 10/05/2011 18:29, Joerg Schuelke escreveu:

Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich:


The syntax would look like:

Block = "BEGIN" [Declarations] {Statement} "END" .

Yea, it looks like C, but it is not. The difference in C like languages
is that an declaration is just a kind of statement. Without this, I
think it makes no sense. But then you code C-like with pascal keywords.

Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I don't see any disadvantage writting a code with /C-like with pascal 
keywords/, shortcuts are always welcome in order to code faster (also 
this is the objective of the High-Level Languages, isn't?). I like 
Pascal and I don't see why to resist against some improvements, the 
language gets richer and easier. Some small details can also increase 
the community.


Lets see the OOP, its very helpful and speedup a lot the work and has 
been added to the Pascal. Same for generics.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Joerg Schuelke
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "kingbiz...@gmail.com" :

> Some small details can also increase 
> the community.
> 
> Lets see the OOP, its very helpful and speedup a lot the work and has 
> been added to the Pascal. Same for generics.

To decide that a declaration is a statement and can occur everywhere
where a statement is required, is not that small you think. This has
many consequences, influencing the whole code generation process.

Think about exceptions and stack rewinding.

Think about efficiency of code generating, for many developers a reason
for developing in pascal.

Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Vinzent Höfler
On Tue, 10 May 2011 23:48:30 +0200, Joerg Schuelke   
wrote:



Am Tue, 10 May 2011 18:41:35 -0300
schrieb "kingbiz...@gmail.com" :


Some small details can also increase
the community.

Lets see the OOP, its very helpful and speedup a lot the work and has
been added to the Pascal. Same for generics.


To decide that a declaration is a statement and can occur everywhere
where a statement is required, is not that small you think. This has
many consequences, influencing the whole code generation process.


You mean, just like try/finally blocks? ;)

FWIW, a declaration is not a statement here:

Swap_And_Ignore_Exceptions :
declare
   Temp : Integer;
begin
   Temp := X;
   X := Y;
   Y := Temp;
exception
   when others =>
  null;
end;

Ada compilers can happily handle that since the mid-80s, so I don't
see why doing it a quarter of a century later would suddenly be a
problem. Apart from that I don't want to see it in Pascal, as it
does not make sense there unless you go down the whole way...


Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Joerg Schuelke
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "kingbiz...@gmail.com" :

> Lets see the OOP, its very helpful and speedup a lot the work and has 
> been added to the Pascal. Same for generics.

OOP is an concept. Nobody would say that it would not be helpful if
pascal has templates -an other very helpful concept-.

Nobody would say that it is not helpful if somebody implements multi
inherited objects for pascal.

The reason for C++ to say a declaration is a statement is coding
security. An uninitialized variable is in an undefined state, that`s
why the declaration is suspended up to the time you can initialize the
data and bring it to a defined state.

The reasons for pascal not doing this:
- overview is better if you have all var declarations together
- the compiling process is easier if all vars are together.

The reason to change the pascal behavior would not be to have a
feature add-on, but a thinking in the same direction like C++, what
can we do to make it possible that the compiler helps more in 
fulfilling assertions about variables and objects during their life
time.

Sorry the bad English, it is difficult to write about concepts without
enough words.

By the way I am not a fpc developer, what I write is my own opinion,
not the one of the fpc team.

Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Vinzent Höfler
On Wed, 11 May 2011 00:15:12 +0200, Joerg Schuelke   
wrote:



Nobody would say that it is not helpful if somebody implements multi
inherited objects for pascal.


I would. FPC already has interfaces.

There are good reasons why most languages didn't adopt the C++-way of  
doing MI.



Vinzent.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Declare variables inside the code

2011-05-10 Thread Joerg Schuelke
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler :

> I would. FPC already has interfaces.
> 
> There are good reasons why most languages didn't adopt the C++-way
> of doing MI.

I think we have two concepts

  - inheritance
  - interface

You can decide for one ore the other, or possibly mix them. 

It is a matter of design. Or a matter of capability to implement the
concept.

Jörg
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel