On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin i...@kmiac.ru wrote:
What we will get in the result of this language simplification? Yes,
extremely fast and easy compiler but do you like it?
Maybe the syntax should be simplified, rather than following new
delphi's .Nettist growing style? AFAIK,
On Tue, Oct 20, 2009 at 17:59, dmitry boyarintsev
skalogryz.li...@gmail.com wrote:
On Tue, Oct 20, 2009 at 4:59 AM, Paul Ishenin i...@kmiac.ru wrote:
Maybe the syntax should be simplified, rather than following new
delphi's .Nettist growing style? AFAIK, it's been discussed about
using class
In our previous episode, dmitry boyarintsev said:
What we will get in the result of this language simplification? Yes,
extremely fast and easy compiler but do you like it?
Maybe the syntax should be simplified, rather than following new
delphi's .Nettist growing style? AFAIK, it's been
Michael Schnell wrote:
Important additional Question:
Martin:
Any comment on this ?
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Martin,
Any additional comment on Michael Van Canneyt's suggestion
Feel free to contribute a descendant of TCustomApplication that adds a
message queue.
which I tried to gently pass over toward you ? :)
-Michael
___
fpc-devel maillist -
Hello, FPC developers' list.
I think we can close 'sealed/abstract class' page and open another
interesting topc.
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
This is exactly my point about sealed classes. When you design the
product or class, you have NO way of know what will come in the
future. So you
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Hello, FPC developers' list.
I think we can close 'sealed/abstract class' page and open another
interesting topc.
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
2009/10/20 Paul Ishenin i...@kmiac.ru:
It is obvious you are full of energy to discuss new language features.
:-)
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
As an alternative to the very limited for-in, I have a better and
more
On Tue, Oct 20, 2009 at 18:57, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard interface for the cost common usage
of
On Tue, 20 Oct 2009, Graeme Geldenhuys wrote:
2009/10/20 Paul Ishenin i...@kmiac.ru:
It is obvious you are full of energy to discuss new language features.
:-)
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
As an alternative
2009/10/20 Alexander Klenin kle...@gmail.com:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard interface for the cost common
usage
of iterators. So they are not mutually
Florian Klaempfl wrote:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
This is exactly my point about sealed classes. When you design the
product or class, you have NO way
2009/10/20 Alexander Klenin kle...@gmail.com:
for-in is just a syntax sugar plus standard interface for the cost common
usage
of iterators. So they are not mutually exclusive at all.
Another flaw in the for-in concept...
What will this do:
for y in MyList do
begin
if y = XXX then
On Tue, Oct 20, 2009 at 19:03, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
As an alternative to the very limited for-in, I have a better and
more flexible design, using the Iterator design pattern.
for-in is just a syntax sugar plus standard
Graeme Geldenhuys wrote:
BTW: Java and .NET have such type of iterators on just about every
list component and it's very handy (I can only comment here on Java
implementation because I don't use .NET).
Re .NET: Delphi Prism does have iterators.
( http://prismwiki.codegear.com/en/Iterators
In our previous episode, Paul Ishenin said:
It is obvious you are full of energy to discuss new language features.
The next feature which we should think of is for-in loop:
http://wiki.lazarus.freepascal.org/for-in_loop
There you can find:
1. Delphi implementation details
2. Proposed
2009/10/20 Alexander Klenin kle...@gmail.com:
Well, I suggest you to read at least the link provided in the original post,
and maybe also some documention about Delphi/C# enumerators.
I just read the docs in the lazarus wiki. The problems/limitations
still hold true. For-in only goes in ONE
2009/10/20 Michael Schnell mschn...@lumino.de:
Re .NET: Delphi Prism does have iterators.
( http://prismwiki.codegear.com/en/Iterators )
In all respects, Delphi Prism is not a Embarcadero product - except
for the slapped on Delphi prefix, Embarcadero has nothing to do with
Delphi Prism.
But
Graeme Geldenhuys wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
for-in is just a syntax sugar plus standard interface for the cost common usage
of iterators. So they are not mutually exclusive at all.
Another flaw in the for-in concept...
What will this do:
for y in MyList do
On Tue, Oct 20, 2009 at 19:22, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
2009/10/20 Alexander Klenin kle...@gmail.com:
Well, I suggest you to read at least the link provided in the original post,
and maybe also some documention about Delphi/C# enumerators.
I just read the docs in the
2009/10/20 Alexander Klenin kle...@gmail.com:
I just read the docs in the lazarus wiki. The problems/limitations
still hold true. For-in only goes in ONE direction
Hm, did you read the about reverseEnumerators and various irders of
tree traversals?
---
// for basic type we
Michael Van Canneyt wrote:
And what is so special in the class type?
First:
For a for loop, you are guaranteed that the loop logic behaves correctly.
A loop is equivalent to the following:
I:=StartValue;
E:=EndValue;
While I=EndValue do
begin
// loop stuff
Inc(I);
end;
And you
On Tue, Oct 20, 2009 at 19:40, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
// for basic type we will call only the apropriate function
procedure TraverseString(S: String);
var
C: Char;
begin
for C in S using GetReverseStringEnumerator(S) do
DoSomething(C);
end;
Now your for-in
Michael Van Canneyt wrote:
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
At least one of the reasons we never did implement for-in is the
absolutely
horrible and totally wrong idea to use classes/interfaces for this,
to which
I seriously objected.
Reading this I
On Tue, 20 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
And what is so special in the class type?
First:
For a for loop, you are guaranteed that the loop logic behaves correctly.
A loop is equivalent to the following:
I:=StartValue;
E:=EndValue;
While I=EndValue do
begin
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
mich...@freepascal.org wrote:
You don't know this with an iterator since you depend on the implementation
of the iterator. The loop could loop forever then...
Just as it can when using iterators explicitly. No difference here.
Secondly:
You
On Tue, 20 Oct 2009, Alexander Klenin wrote:
On Tue, Oct 20, 2009 at 19:34, Michael Van Canneyt
mich...@freepascal.org wrote:
You don't know this with an iterator since you depend on the implementation
of the iterator. The loop could loop forever then...
Just as it can when using iterators
In our previous episode, dmitry boyarintsev said:
specially for minor features is more trouble then it is worth, since
eventually the Delphi syntax will have to be supported anyway.
Agreed, and that's quite sad, eventual Delphi syntax support makes
FreePascal actually FreeDelphi.
I don't
Michael Van Canneyt schrieb:
Secondly:
You promote a certain class/interface to a language feature. The
compiler then depends on the presence of a certain class with some
'known' methods in the RTL.
The whole interface ref. counting depends on that as well as e.g. the
as operator.
My
On Tue, Oct 20, 2009 at 20:09, Michael Van Canneyt
mich...@freepascal.org wrote:
But I really don't see the advantage of being able to type
For F in Someclass.Iterator do
F.Something
over
While SomeClass.HaveValue do
SomeClasss.NextValue.Something;
It's not clearer, at most it
Florian Klaempfl flor...@freepascal.org:
It's not only not visible but neither accessible.
For good reasons, usually. Either there's a way to access it (properties) or it
really is an implementation detail that might change.
And if something is
not accessible, it affects flexibility.
Yes.
On Tue, Oct 20, 2009 at 1:22 PM, Marco van de Voort mar...@stack.nl wrote:
Packages don't have external classes. A package is fully transparent to the
program, IOW when linking to a package there are proper .ppu's and
everything, and there is no external link step.
So it would be like using
On 20/10/2009, Alexander Klenin kle...@gmail.com wrote:
Hm. I can not see where lookahead aka peeking
is required in using any of the enumerators you mention.
UTF8String enumerator is even among the samples on the wiki page.
I just completed a parser for a custom RichText component I wrote
On Tue, 20 Oct 2009, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
Secondly:
You promote a certain class/interface to a language feature. The
compiler then depends on the presence of a certain class with some
'known' methods in the RTL.
The whole interface ref. counting depends on
On Tue, Oct 20, 2009 at 20:29, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
On 20/10/2009, Alexander Klenin kle...@gmail.com wrote:
Hm. I can not see where lookahead aka peeking
is required in using any of the enumerators you mention.
UTF8String enumerator is even among the samples on
Graeme Geldenhuys graemeg.li...@gmail.com:
Well, with for-in you can only loop through a list is a specific order
and direction. You can't peak forward, you can't move back, you can't
filter returned content.
At least you know it will terminate. That always was a guaranteed property of
the
In our previous episode, Paul Ishenin said:
Yes, I see this very bad too. That's why this discussion is started. But
what can be suggested instead?
Does there need something to be suggested per se?
What do you think of the DECAL solution ? It's ackward, but that is because
it is
On 20/10/2009, Paul Ishenin i...@kmiac.ru wrote:
I don't like non-constructive criticism. If you don't like something please
be ready to suggest something instead. And in this case something what can
By no means to I suggest that my code should be the final product, but
here I am attaching
Marc Weustink marc.weust...@cuperus.nl:
Graeme Geldenhuys wrote:
Another flaw in the for-in concept...
What will this do:
for y in MyList do
begin
if y = XXX then
MyList.Add(YYY);
if y = ZZZ then
MyList.Insert(1, AAA);
end;
[...]
This is
Graeme Geldenhuys wrote:
In all respects, Delphi Prism is not a Embarcadero product - except
for the slapped on Delphi prefix, Embarcadero has nothing to do with
Delphi Prism.
They do sell it, so I suppose if they plan language extension (like
iterators) for the native Delphi flavor, they will
On 20/10/2009, Michael Schnell mschn...@lumino.de wrote:
They do sell it,
As a curtsey because they gave up on Delphi.NET.
RemObjects are now in control of Delphi Prism.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
Graeme Geldenhuys wrote:
RemObjects are now in control of Delphi Prism.
No wonder, as they created it :)
I understand that Codegear or Embarcadero pay(ed) them for the license
to sell it.
-Michael
___
fpc-devel maillist -
In our previous episode, dmitry boyarintsev said:
Packages don't have external classes. ?A package is fully transparent to the
program, IOW when linking to a package there are proper .ppu's and
everything, and there is no external link step.
So it would be like using delphi's dcu (without
Vinzent Höfler wrote:
Marc Weustink marc.weust...@cuperus.nl:
loop you are not allowed to modify the loop variable. In this case I can
imagine its not allowed to modify the list.
But how's the compiler supposed to know which method modifies MyList and which one does not?
That's why I
On Tue, Oct 20, 2009 at 11:26 AM, Marco van de Voort mar...@stack.nl wrote:
Some class/vars/consts/functions are avaiable and declared in package
file, but the only they to see a full declaration is via documention,
rather than header-sources.
I don't understand this.
Delphi can compile a
dmitry boyarintsev wrote:
Delphi can compile a project with dcu present, but no .pas files.
...
Can the mail topic be changed for the unrelated thread? I still expect a
new dose of criticism in every mail with the current topic.
Best regards,
Paul Ishenin.
On 19 Oct 2009, at 19:19, Alexander Klenin wrote:
On Tue, Oct 20, 2009 at 01:12, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
Except if you want to use the constant in another constant
expression (which
is not possible with a function, inlined or not).
Which, by the way, is another
On Tue, Oct 20, 2009 at 12:03 PM, Paul Ishenin webpi...@mail.ru wrote:
Can the mail topic be changed for the unrelated thread? I still expect a new
dose of criticism in every mail with the current topic.
You're right, i've been hijacking the thread to a wrong subject.
Sorry, won't happen again.
In our previous episode, dmitry boyarintsev said:
file, but the only they to see a full declaration is via documention,
rather than header-sources.
I don't understand this.
Delphi can compile a project with dcu present, but no .pas files.
Any type or routine present in dcu can be used.
Marc Weustink wrote:
It is bad enough that the second point is already so for interfaces
and even TObject, (a very serious design flaw by Borland) but
extending this even further to include actual language features such
as the for loop is 2 bridges too far
as far as I'm concerned.
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func: element type
function
Martin wrote:
using seems far better than a fixed name GetIterator procedure.
IMHO the other option is to implement the feature for ase types (e.g.
enum, array, maybe string) and allow operator overriding for all other
types.
Then you can specify an enum operator for classes, or even for
Hi,
In the PS or PDF versions of the RTL documentation, and then the
reference information about the 'SysUtils' unit. In my docs it's
chapter 37.
The sysutils unit has related topics like the Date and Time
formatting characters.
I noticed that those related topics appear before the Used units
Hi
Based on discussion about for in I want to suggest my proposition.
When we investigate some code, sometimes we found pattern:
Pattern 1:
/ begin
startfun;
try
...
finally
stopfun;
end;
/ end;
Pattern 2:
for i:= startfun to stopfun do begin
end;
Pattern 3:
Paul Ishenin пишет:
Marc Weustink wrote:
I can see a use for using iterators in a for loop, however they should
be declared with some keyword.
Something like
type
TListIterator = iterator(TList, init_func, next_func, check_func)
function init_func: Boolean;
function next_func:
On Tue, 20 Oct 2009, Graeme Geldenhuys wrote:
Hi,
In the PS or PDF versions of the RTL documentation, and then the
reference information about the 'SysUtils' unit. In my docs it's
chapter 37.
The sysutils unit has related topics like the Date and Time
formatting characters.
I noticed that
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this. But
lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
Michael Schnell wrote:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
Wow, talk about unreadable code...
I'm all for saving typing, but not at the expense of readability. This
reminds me of C's oddball ? operator. One of the reasons I
Pascal have something close to lambda, and it's nested functions/procedures
The original idea of lambda is to have sub process that takes parameters and
simple tasks.
For example (in Ruby):
def action(base)
expo = lambda { |by_num| base ** by_num}
x = something
a = expo(x)
end
I
In our previous episode, Jeff Wormsley said:
( http://prismwiki.codegear.com/en/Lambda_Expressions )
Wow, talk about unreadable code...
I'm all for saving typing, but not at the expense of readability. This
reminds me of C's oddball ? operator.
(hmm, if I would name one feature I hate
Marco van de Voort schreef:
(hmm, if I would name one feature I hate about C, that would be that if (x=y)
goes unnoticed while legal. At least the ? operator doesn't bite you if you
don't use it)
Off topic.
Vincent
___
fpc-devel maillist -
2009/10/20 Jeff Wormsley dawor...@comcast.net:
( http://prismwiki.codegear.com/en/Lambda_Expressions )
Wow, talk about unreadable code...
+1
That's all I can say.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
ik pisze:
Pascal have something close to lambda, and it's nested
functions/procedures
The original idea of lambda is to have sub process that takes
parameters and simple tasks.
You don't understand me. I know sub process, this is nice feature of
pascal, but i talk about something different.
Original-Nachricht
Datum: Tue, 20 Oct 2009 13:38:40 +0200
Von: Micha Nelissen mi...@neli.hopto.org
An: FPC developers\' list fpc-devel@lists.freepascal.org
Betreff: Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote:
Marc Weustink
Vinzent Höfler пишет:
Sergei Gorelkin sergei_gorel...@mail.ru:
4) The syntax 'for element in list using TListIterator' is kind of
redundant. I'd suggest:
for element in list.GetForwardIterator do ..., or even
for element in list.GetSubItems(arguments) do ...
Wat's the return type of
Sergei Gorelkin wrote:
Probably yes. A possibility to use any type which has certain
methods/operators instead looks attractive, but I'm afraid it would be
hard to fit that into existing compiler model.
Sorry, what is TIterator? Is this like to the previosly suggested
TIterator =
Marco van de Voort wrote:
btw the earlier discussions about D2005+ functionality are archived at:
http://www.stack.nl/~marcov/delphilater.txt
I wanted to use this for an article, so the log are sligtly processed and
annotated.
There is no much threre regards 'for-in'. I would like if
Paul Ishenin wrote:
Sergei Gorelkin wrote:
Probably yes. A possibility to use any type which has certain
methods/operators instead looks attractive, but I'm afraid it would be
hard to fit that into existing compiler model.
Sorry, what is TIterator? Is this like to the previosly suggested
Sergei Gorelkin wrote:
The question is, what advantage all this specific syntax could give over
simple searching the methods by name?
Some people need less compiler magic, some does not care. New directive
can reduce the magic level :)
Btw, we use similar compiler magic every day. Just
Paul Ishenin wrote:
Marco van de Voort wrote:
btw the earlier discussions about D2005+ functionality are archived at:
http://www.stack.nl/~marcov/delphilater.txt
I wanted to use this for an article, so the log are sligtly processed
and
annotated.
There is no much threre regards 'for-in'.
72 matches
Mail list logo
