Michael Van Canneyt wrote:
It's a simple fact:
90% if not more of all pascal code out there is Delphi code. Being able to
compile and
re-use that is FAR more important than changing the fact that begin/end is
required in
pascal.
ACK.
You want to make some 'Auto-Maintained' variable
Angelo Bertolli wrote:
Begin..End is redundant - you have to indent them to make em readable
anyways.
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
Jamie McCracken wrote:
Those lazarus tools are great but they require advance knowledge of
those tools that new users wont have (at least somebody using lazarus
for the first time is not going to know all the keyboard shortcuts). Not
having to rely on hacks around the coding inefficiency of a
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
lol - thats not what I meant. If you want
On Sun, 5 Jun 2005, Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
Michael Van Canneyt wrote:
On Sun, 5 Jun 2005, Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
lol
|
| lol - thats not what I meant. If you want readable code you indent
| inside the begin..end blocks ergo the begin..end syntax becomes
| redundant cause its the indentation that provides the visual cue.
|
That's like taking question marks out of sentences that you know are questions.
Why
have
Op Sun, 5 Jun 2005, schreef Jamie McCracken:
yes but isn't it fair to say that such developers that require such
structures would be knowledgable enough to make it safe by using weak refs?
What is a weak ref?
My point is that the everyday structures that most developers (and in
particular
Daniël Mantione wrote:
Op Sun, 5 Jun 2005, schreef Jamie McCracken:
yes but isn't it fair to say that such developers that require such
structures would be knowledgable enough to make it safe by using weak refs?
What is a weak ref?
Allows you to make a reference without increasing or
Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
Well all I ask is you wait til I have written it then
On 05 Jun 2005, at 15:22, Jamie McCracken wrote:
I believe it will help Pascal and breathe new life into it
especially as its a dying language.
And with the above insightful and undoubtedly uncontroversial comment
I think we can close this thread here. I would therefore like to ask
all
| will respect your wishes and no feelings will be hurt. I believe it will
| help Pascal and breathe new life into it especially as its a dying
| language. I also note there is no such thing as Pascal as such even
| Delphi has significant syntax differences with earlier pascal variants
| so I
On Sun, 5 Jun 2005, Jamie McCracken wrote:
Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to
that.
I don't consider your construct to be Pascal, so I will fight inclusion
of it in the compiler, not even under some {$Mode} construct.
using them hard or impossible becomes a toy language.
But it doesn't. The only time they are a problem is when the stuff you
are storing in the tree or list is an *object* and that *object* points
back to either the container or the list that stores it (which is very
rarely done). The
Hans-Peter Diettrich wrote:
You obviously missed that a compiler does not only consist of scanner
and parser, but that optimizers and code generators also have to be
implemented. For multiple target platforms and CPU's...
The new dialect simply makes the syntax less annoying and verbose - it
El Sábado, 4 de Junio de 2005 11:00, Jamie McCracken escribió:
I had thought of that but thats problematic for debugging. IE the
compiler returns line numbers for errors and they will not match if I
use an external preprocessor.
See the recent thread How to manually control debug information
P.S.:
BTW: Never heard of anybody doing serious programming in GNU Pascal (and I
know many a programmer doing serious programming in FPC and even VP)
As far as I can see (from their maillists), most serious GPC users are
academics working with large numeric-related legacy ISO codebases.
VP
listmember wrote:
-- Class Contracts
I like the 'require/ensure' aproach.
It makes the code more robust and more debuggable, IMHO
I think the checks you can do there are to limited. I also wonder what
will happen if a require isn't met. Personally I don't want
exeption in my released app.
Marc Weustink wrote:
Jamie McCracken wrote:
[snip]
would become under Rad Pascal:
uses
Classes, SysUtils;
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count);
On Friday 03 June 2005 10:47, Jamie McCracken wrote:
It makes it more clear IMO not less. having all that interface code
and having to jump between it and the implementation does not aid
legibility.
It encourages reading code instead of interface specifications. Often
there is a big
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for the offer, where can I
On Thursday 02 June 2005 16:12, Marco van de Voort wrote:
Begin..End is redundant - you have to indent them to make em
readable anyways.
No. This makes the code more readable like normal english text. It
states much more clearly what it intents, at least much more than
just indenting
Vincent Snijders wrote:
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use
it - stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks for
Marc Weustink wrote:
-- Class Contracts
I like the 'require/ensure' aproach.
It makes the code more robust and more debuggable, IMHO
I think the checks you can do there are to limited. I also wonder what
will happen if a require isn't met. Personally I don't want
exeption in my released app.
- Original Message -
From: Hans-Peter Diettrich [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, June 02, 2005 3:27 PM
...
More important: Unicode literals. But I know that this would require a
very big change to the scanner, and to all code
From: Gerhard Scholz
Sent: woensdag 1 juni 2005 18:35
- Original Message -
From: Marco van de Voort [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wednesday, June 01, 2005 1:50 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
[big snip
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of listmember
Maybe a few things should be borrowed from RemObjects Chrome, such as
-- Class Contracts
http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30
D8}
I like the 'require/ensure' aproach.
It makes the code
Jamie McCracken wrote:
Marc Weustink wrote:
What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to decode a a := b
:= c := d := 0 line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read
Jamie McCracken wrote:
Marc Weustink wrote:
What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to decode a a := b
:= c := d := 0 line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
MyObject.Create is impossible with classes on the heap. You need to
assign MyObject a pointer but you can't do that from within
On Thu, 2 Jun 2005, Jamie McCracken wrote:
Marc Weustink wrote:
What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to decode a a := b
:= c := d := 0 line. There might be a ; inbeween which results in a
complete different assignment. With such
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet with any
python programmer that I create any application faster than him :)
You must be a damn fast typer then :)
Ironically python is perhaps the
most popular language on Linux and most of its
Michael Van Canneyt wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#. Ironically python is
perhaps the most popular language on Linux and most of its syntax is
derived from object pascal whereas pascal on linux is
Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet with
any
python programmer that I create any application faster than him :)
You must be a damn fast typer then :)
I teached myself typing with 10 fingers, but typing is
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer then :)
No, that's a common
Florian Klaempfl wrote:
If that were the case then yeah it would sux (however pythons
performance is due to bien a bytecode interpreter and dynamic typing
neither of which we need in pascal).
Ref. counting etc. eats time because you need good garbage collection to detect
cycles and other
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer then :)
No,
On Thu, 2 Jun 2005, Jamie McCracken wrote:
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
Michael Van Canneyt wrote:
I don't consider Ojbect Pascal to be verbose at all, so it's not an
issue for
me...
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice as fast,
the maximum
On Thursday 02 June 2005 14:24, Jamie McCracken wrote:
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing my application.
I typically spend 80% of my development time
Vinzent Hoefler wrote:
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice
On Thursday 02 June 2005 14:44, Jamie McCracken wrote:
My point is to to reduce or remove *redundant* syntax that serves no
useful or productive purpose (to the programmer).
Well applied redundancy is a good thing.
Forward declarations are redundant - they exist purely for the
benefit of
Michael Van Canneyt wrote:
This is only 'logical' if the hypothesis
productivity is inversely related to the syntax verbosity
is correct.
And it's not.
What is correct is productivity is directly related to the number of
separate language constructs developer has to put in program to
Michael Van Canneyt wrote:
But the compiler needs to check many things:
1. Initialize the S with Nil.
2. Check that S is assigned only once during the lifetime of the
procedure.
This is actually a bigger restriction than you might think,
unless you want to introduce reference
Marco van de Voort wrote:
Some of these target functionality (specially in the linking section) might
require restructures
related to
* introduction of an internal linker for some core platforms (no more
LD)
* Rewrite of module (unit) handling
Yes, these would be great,
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer then :)
No, that's a common
Marco van de Voort wrote:
Also, I simply don't see the use of it. Borland Pascal's have the forward
directive for those really few cases where it is annoying.
Also, forward declarations mostly mean shitty code / design.
Atleast in my case it does.
Begin..End is redundant - you have to indent them to make em readable
anyways.
No. This makes the code more readable like normal english text. It
states much more clearly what it intents, at least much more than just
indenting or putting curly braces around it.
Not every syntax is
Michael Van Canneyt wrote:
This is only 'logical' if the hypothesis
productivity is inversely related to the syntax verbosity
is correct.
And it's not.
What is correct is productivity is directly related to the number of
separate language constructs developer has to put in
Michael Van Canneyt wrote:
This is not so easy, and reference counting is always a mess...
Well you already have the code for ref counting for com objects so its
not like its a ton of work and therefore we dont need to worry about
your four points. Adding C++ style exception
L505 wrote:
| Yeah I know this sounds like a hybrid Pascal/python but I believe thats
| the way to go - marry Delphi's speed and component framework with less
| verbose python style syntax and you will have the best RAD language ever
| written.
|
You are asking to reinvent python. If I were
|
|
| I'am a poor delphi programmer, didn't use it for years, but I bet with
| any
| python programmer that I create any application faster than him :)
|
|
| You must be a damn fast typer then :)
Sometimes it's which keys are near the home key. I don't care if { is shorter
than
begin,
listmember wrote:
Inline variable initializers, such as:
...
function Something(...): Boolean = False;
var
Integer1: Integer = 15;
Boolean1: Boolean = False;
String1: String = 'SOME TEXT';
begin
end;
Such constructs are subject to frequent misinterpretation :-(
I assume that
Jamie McCracken wrote:
For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)
I totally agree with you in this case - we dont want or need cryptic c
stlye syntax in any version of Pascal.
ACK.
However, in general Pascal has poor
-- Class Contracts
I like the 'require/ensure' aproach.
It makes the code more robust and more debuggable, IMHO
I think the checks you can do there are to limited. I also wonder what
will happen if a require isn't met. Personally I don't want exeption in my
released app.
No, these are
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
So am I. My point is not changing the language so that it incurs
additional maintenance or is harder to read or harder to fix bugs or
make bugs more likely. In fact its the complete opposite.
My point is to to reduce or remove *redundant* syntax
Daniël Mantione wrote:
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
Daniël Mantione wrote:
Ok! We'll be happy to assist anyone doing interresting developments with
Free Pascal. Keep in mind though that implementing ideas can take a lot
more time that thinking out ideas.
The Free Pascal
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
Daniël Mantione wrote:
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
Daniël Mantione wrote:
Ok! We'll be happy to assist anyone doing interresting developments with
Free Pascal. Keep in mind though that implementing ideas can take a
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing my application.
jamie.
Well, you are quite a machine. If you say so, sure it's so, but that's not
the problem.
I've read somewhere that Delphi 7 compatibility is planned (since I do not
have it I do not know what that means in detail).
Main plans short term to my knowledge are:
* create/improve the COM/OLE support. This has multiple facets:
o COM compat interfaces/vmt
o
I followed this discussion if that construction (see below) should be
allowed or not (I think it should be allowed, but it's possible to live
without it; I can imagine situations where it could make easier to read),
and I'm missing a bit a discussion forum about the future of FPC. It
should
El Miércoles, 1 de Junio de 2005 13:50, Marco van de Voort escribió:
Main plans short term to my knowledge are:
...
* improved packages and dynamic libraries (PIC!) support in general.
Sorry if I've been confused by improved. Is PIC already supported?
--
saludos,
Nico Aragón
- Original Message -
From: Marco van de Voort [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wednesday, June 01, 2005 1:50 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
... (shortened)
Useful extensions I would see:
bigger sets: set
Gerhard Scholz wrote:
var
x : type1, y : type2 ;
x *:= y ;
in my humble opinion(IMHO):
:= is based on the fact that A: is written normaly in math etc. where it
means this is a fact about A
So when someone writes A:=5; it means it's a fact that A
my marks start with :
- Original Message -
From: Ales Katona [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wednesday, June 01, 2005 6:52 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote:
var
x
66 matches
Mail list logo
