On Tue, Sep 6, 2011 at 22:17, Jonas Maebe wrote:
>> For at least last few months, I write down bugs I encounter in the local
>> file,
>> since by the time the "Report Issue" page loads, I forget what I
>> wanted to report.
>> I suspect the server is severely overloaded.
>
> In general, not really.
On Tue, Sep 6, 2011 at 22:43, Jonas Maebe wrote:
> There is one known problem: the server is behind a brain dead firewall,
> which drops most icmp packets (except for ping). This includes the
> "fragmentation needed" packets used for path mtu discovery
> (http://www.networksorcery.com/enp/rfc/rfc1
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe wrote:
> It's more that even though both are called "array of const", they are
> completely different things. They also don't support the same types.
Perhaps varargs-compatible parameter type should be called something else then?
--
Alexander S. Klenin
the following code:
{$mode objfpc}
var
a: Integer;
begin
a := a + 1;
asm nop end;
end.
generates (under -O2):
movlU_P$PROGRAM_A,%eax
incl%eax
movl%eax,U_P$PROGRAM_A
nop
instead of a single "incl".
removing either "asm" statement OR $mode directiv
2011/10/3 Jonas Maebe :
> asm nop end [];
>
> then the statement will optimized. Otherwise the compiler assumes that the
> contents of eax may still be used inside the assembler block and hence
> cannot remove its use.
>
> The fact that the optimization is performed in case the used register is ax
On Mon, Oct 3, 2011 at 21:13, Felipe Monteiro de Carvalho
wrote:
> On Mon, Oct 3, 2011 at 11:38 AM, Marco van de Voort wrote:
>> These things are related to Lazarus UTF8
>> decision and thus logically belong in Lazarus,
>
> Not really. One can write a non-visual library which uses utf8string
> as
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl wrote:
> Am 03.10.2011 13:23, schrieb Alexander Klenin:
>>
>> This way, you can develop much faster, without the need to fight for
>> your changes,
>
> Others call this fighting "review" and consider it as importa
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl wrote:
>> Anyway, what I suggest is IMO a good compromise and should satisfy both
>> sides --
>> Felipe can continue development of his packages unobstucted,
>> while the quality of FPC will not suffer.
>
> That's why I proposed a branch and that's wha
On Tue, Oct 4, 2011 at 01:01, Felipe Monteiro de Carvalho
wrote:
>
> I think we should agree to disagree: Let's delete fpvectorial from
> FPC, I'll export it into lazarus/components/fpvectorial and we move
> our separate ways.
+1
Among other things, this will simplify management of TAChart's
fpve
On Tue, Oct 4, 2011 at 00:49, Paul Ishenin wrote:
> 03.10.2011 21:32, Alexander Klenin wrote:
>>
>> I'd say there is a continuum between those extremes, and (unfortunately)
>> from my point of vew, FPC review is sometimes rather close to the former.
>> I have been
On Tue, Oct 4, 2011 at 08:48, Michael Van Canneyt
wrote:
>> There is, again, a continuum between careful development and stangation.
>> While acknowledging great work that FPC team has done on the former,
>> I'd venture to say that is came uncomfortably close to the latter.
>
> I'd venture to disa
On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt
wrote:
> We'd like people to try it and comment on the design and speed of the
> engine,
> and if you have suggestions for improvements, they're more than welcome.
A good use/test would be to speed up "Find in Files" in Lazarus.
--
Alexander S
On Fri, Mar 16, 2012 at 21:06, Mattias Gaertner
wrote:
> On Fri, 16 Mar 2012 20:47:15 +1100
> Alexander Klenin wrote:
>
>> On Fri, Mar 16, 2012 at 19:36, Mattias Gaertner
>> wrote:
>> >> Is it possible to iterate through all items in a TAvgLvlTree? I
>> &g
On Tue, Mar 27, 2012 at 19:30, Mark Morgan Lloyd
wrote:
> Gennadiy Poryev wrote:
>>
>> Hi all,
>>
>> I’ve recently ran into weird problem with “C style operators”. Though the
>> story is about Lazarus, I thought I better ask it here. All of a sudden, my
>> Lazarus trunk had refused to build
>> (ht
I have used class helpers feature for the first time.
(See components/tachart/tachartteechart.pas, r36916).
The good news is that I was able to get it working.
The bad news is that I have encountered 4 bugs and 1 missing feature
in about 10 lines of code :)
(Also, Lazaus does not seem to support cl
On Fri, Apr 20, 2012 at 23:23, Sven Barth wrote:
> Am 20.04.2012 05:41 schrieb "Alexander Klenin" :
>> The bad news is that I have encountered 4 bugs and 1 missing feature
>> in about 10 lines of code :)
>
> Why do you need to test so much? Just kidding...
> I&
On Fri, Apr 27, 2012 at 20:28, Marco van de Voort wrote:
> Calling a virtual(!) method when a bookmark is no longer needed allows to do
> other things too, like releasing something with db handles, and allows
> descendents of TDataset to do such things.
Did you consider declaring TBookmark an int
One user reported that latest FPC fails to compile a recent Lazarus:
http://bugs.freepascal.org/view.php?id=22029
The bug was assigned to me, but I can't do much about it except to commit
some workaround. And I am now away (at ACM ICPC World Finals),
so it will take more than a week till my return
On Fri, May 18, 2012 at 12:16 PM, Joost van der Sluis wrote:
> I think I can. But in Delphi you can also give a non-exsisting
> attribute, ie:
>
> TMyClass=class
> private
> FName: string;
> published
> [TThisTypeIsNowhereDefined('You','Can','Enter','Anything','here'1)]
> property Name
The following code compiles both with :
procedure F(const A: array of ShortInt); begin end;
begin F(1); end.
I think this is a bug in FPC, but if not -- it should be documented here:
http://freepascal.org/docs-html/ref/refsu59.html#x157-16700014.4.5
I am willing to file an issue one way or anoth
On Fri, Jun 8, 2012 at 6:08 PM, Marc Weustink wrote:
> Unfortunately Delphi (6) accepts this too. It took me some time at work to
> figure out why some code suddenly behaved weird. (I changed a integer
> argument to array of integer and assumed the compiler would help me to find
> the places where
On Fri, Jun 8, 2012 at 7:22 PM, Sven Barth wrote:
>> I suggest this "feature" to be disabled in objfpc mode then.
>>
>
> This would not be backwards compatible, thus the answer to this request is
> most likely: No.
On the other hand, FPC has an established history of breaking
backwards compatibil
On Mon, Jun 11, 2012 at 9:03 AM, Skybuck Flying wrote:
>> Unfortunately Delphi (6) accepts this too. It took me some time at work
>> Delphi XE2 does not ;)
> Delphi XE does not accept constants either, but scalar variables. So the
> following compiles:
Given the above, I suggest to leave Delph
On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner
wrote:
> What do you think?
>
Why not -- although IMO it would be much better to have some
lagnuage-level support
for things like single-owner semantics.
Independenty, it seems that the unit should be updated to support "is
nested" modifier.
--
On Tue, Sep 11, 2012 at 8:03 AM, Jonas Maebe wrote:
>
> If you want to do that, you need to add a layer in between that converts the
> sets into integer bitmasks in a reliable, portable and future-proof way.
>
How about packed sets? Do they have well-defined memory layout? If
not, then maybe the
Will global variables and static global arrays be always initialized to zero?
It seems that they in fact are, and there is quite a lot of code
relying on it. On the other hand, the documentation denies that.
What is the official position?
--
Alexander S. Klenin
On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe wrote:
>
>> Will global variables and static global arrays be always initialized to
>> zero?
>
> Yes.
Then I suggest to amend the first paragraph of
http://www.freepascal.org/docs-html/ref/refse22.html
which directly contradicts this.
I have rather cu
In my ongoing efforts to prevent elimination of Pascal/FPC from a set
of languages used to teach programming, I have recently encountered
another problem:
although FPC does include "gmp" unit for arbitrary-precision calculations,
programs compiled with it require "gmp" dynamic library.
This library
On Sun, Dec 2, 2012 at 2:02 PM, Sven Barth wrote:
> We can not bundle such libaries as different (Linux) distributions will have
> different dependencies like different versions of the libc and then this
> library would not load anyway (and Free Pascal would be accused for being
> crap because of
On Sun, Dec 2, 2012 at 2:08 PM, Michael Van Canneyt
wrote:
> That is a bit of a difficult one. gmp just provides just the interface of an
> external library.
> If we do it fo this one, we should do it for all the libraries for which we
> provide headers.
For marketing purposes, mostly. I speak a
On Sun, Dec 2, 2012 at 2:42 PM, Michael Van Canneyt
wrote:
>> Writing high-quality arbitrary precision arithmetics is hard.
>> The fact that Free Pascal uses GMP instead of homegrown solution has
>> actually earned some praise.
>
> Define homegown ? GMP most likely also is homegrown, as a lot of o
On Sun, Dec 2, 2012 at 4:52 PM, Tomas Hajny wrote:
>> As for fairness, the usual argument is "just solve problems in
>> Java/Python",
>> which is exactly what I am trying to prevent :)
>
> Who defines what is the right file to choose if there are multiple
> options?
I am not sure which options do
On Sun, Dec 2, 2012 at 6:21 PM, Sven Barth wrote:
> On 02.12.2012 13:11, Henry Vermaak wrote:
> Yes, "<<" and ">>" are converted in scanner stage to "shl" and "shr" which
> will give me headaches once I want to support nested specializations
> (basically the same problem that C++ had):
>
> TTest>
On Sun, Dec 2, 2012 at 9:47 PM, Tomas Hajny wrote:
> On 2 Dec 12, at 16:45, Alexander Klenin wrote:
>> I am not sure which options do you mean,
>> I refer to the dll mentioned here: http://wiki.freepascal.org/gmp
>
> I meant multiple 2.6.2 installers (in particular, if we
On Thu, Dec 6, 2012 at 2:16 PM, Nikolay Nikolov
wrote:
> Just to make it clear how these people usually think, I was part of the
> IOI2009 technical committee and I was responsible for setting up the pascal
> environment (fpc & lazarus under ubuntu) to work. In that year, Henadzi
> Karatkevitch fr
On Thu, Dec 6, 2012 at 8:29 PM, Jonas Maebe wrote:
> If a major problem is really the lack of standard support for
> arbitrary-precision arithmetic, does that not mean that C and C++ are no
> longer serious options either?
Actually, this is considered a drawback of C++ (nobody uses pure C in
comp
On Fri, Jan 25, 2013 at 4:45 AM, Michael Van Canneyt
wrote:
> Enumerators are not iterators.
Eh... actually, they are? Why do you think otherwise?
> If you want a full-fledged iterator, you should use classes.
Enumerators *are* classes, except for built-in ones.
> The for syntax is not meant for
On Fri, Jan 25, 2013 at 7:18 AM, Jeppe Græsdal Johansen
wrote:
>
> I think the idea is good if the feature is implemented as "optional".
>
> That way:
> - If the enumerator class implements a CurrentIndex method then the for loop
> can have an index variable.
> - If not then the for loop can only
On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl wrote:
> Am 24.01.2013 20:36, schrieb Alexander Klenin:
>> That's debatable.
>
> As long as there is only some few line idea, there cannot debated much.
It is more: an idea with implementation and tests ;)
> Just an examp
On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort wrote:
> In our previous episode, Florian Kl?mpfl said:
>> As long as there is only some few line idea, there cannot debated much.
>
> http://www.freepascal.org/faq.var#extensionselect
Yes, current discussion is based on that guideline.
--
Alex
On Fri, Jan 25, 2013 at 7:56 AM, Florian Klämpfl wrote:
>>> Just an example: what happens with i if I start to delete from s during
>>> the for loop?
>>
>> Exactly the same thing as in the current for-in loop: either a range check
>> error
>> of nothing, depending on what you delete.
>
> How do y
On Fri, Jan 25, 2013 at 8:44 AM, Florian Klämpfl wrote:
> Am 24.01.2013 22:26, schrieb Alexander Klenin:
>> in all three cases, the effect will be more-or-less the same.
>
> In the first two cases the programmer knows that he does something
> strange, actually he can even adju
On Fri, Jan 25, 2013 at 9:36 AM, Michael Van Canneyt
wrote:
>>> If you want full fledged iterators, use classes.
>>
>> Please provide example of your suggestion for the case in the wiki.
>
> I don't need to provide *anything*.
Of course you do not, this is why I said "please" :)
However, it is im
On Fri, Jan 25, 2013 at 10:13 AM, Graeme Geldenhuys
wrote:
> On 01/24/13 19:36, Alexander Klenin wrote:
>>> Enumerators are not iterators.
>> Eh... actually, they are? Why do you think otherwise?
>
> Enumerators are limited in functionality. Iterators are the full-blown
On Fri, Jan 25, 2013 at 10:38 AM, Graeme Geldenhuys
wrote:
> On 01/24/13 23:26, Alexander Klenin wrote:
>>>>> If you want full fledged iterators, use classes.
>>>>
>>>> Please provide example of your suggestion for the case in the wiki.
>>>
>
On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
wrote:
> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
Hm... Do not you think this is a bit of an overstatement?
> There are plenty to choose from. He said maybe he'd look after fcl-stl. The
> silence since was deafenin
On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl wrote:
>> "for-in-index" extension was actually planned by me as a prerequisite
>> for fcl-stl work.
>
> Using indicies is against all principles of iterators.
I am not sure what princilpes you are talking about,
but accessing the key of the current
On Sat, Jan 26, 2013 at 4:38 AM, Michael Van Canneyt
wrote:
>>> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
>> Hm... Do not you think this is a bit of an overstatement?
> No, not really. I really feel that we are deviating a lot from what pascal
> stands for.
If you me
On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
wrote:
>> Consider these arguments:
>> 1) Even for simple arrays, depending on array element type,
>> and optimizer implementation, for-in can be more efficient since it
>> can avoid multiplication for element access.
> True, but it shouldn't. Loop
On Sat, Jan 26, 2013 at 6:11 AM, Sven Barth wrote:
> I think he also means things like (without critizing):
Yes, thank for a dose of sanity :)
Few more examples, taken from just one standard package:
while Node.NextBrother<>nil do begin
...
Node:=Node.NextBrother;
end;
while Node<>nil do b
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
> Am 25.01.2013 18:17, schrieb Alexander Klenin:
>>> Using indicies is against all principles of iterators.
>> I am not sure what princilpes you are talking about,
>
> The theory of iterators.
You mean Alexande
On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth wrote:
>> What is "concrete code"? The code I provided only missed loop bodies.
>> I can provide that too, but I do not think it will add anything to the
>> discussion.
>
> I believe he wants to have real world examples (of other languages) where
> this
On Sat, Jan 26, 2013 at 7:10 AM, Mark Morgan Lloyd
wrote:
> However, I'd suggest that there are two possible category of extension:
> those that implement a clearly-delimited first-class object with interesting
> properties, and those that don't.
>
> Something like a , or a /regular expression/ (b
On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl wrote:
> Where? Concrete code of a serious language! Not some "oh, yes, this
> language has it and that as well"
On Sat, Jan 26, 2013 at 7:34 AM, Florian Klämpfl wrote:
> No. I want to see a language which provides something like the explicit
> i
On Sat, Jan 26, 2013 at 8:54 AM, Florian Klämpfl wrote:
> Maybe I wouldn't have to ask if there would be a clear proposal what
> shall be implemented, what are alternatives, what do other languages,
> why is a so strange approach chosen etc.
I agree that the quality of initial proposal could be b
On Sat, Jan 26, 2013 at 9:27 AM, Sven Barth wrote:
>
> Regarding tuples:
> http://wiki.oxygenelanguage.com/en/Tuples
I know, but I consider this particular implementation an unpleasant example of
"no need to change the language -- lets do it in the library" philosophy.
Just look:
>The Tuple type i
On Sat, Jan 26, 2013 at 9:31 AM, Sven Barth wrote:
> After implementing support for Delphi style generics I came to the
> conclusion that I would have preferred the following syntax:
>
> type
> TFPGListLongInt = specialize TFPGList as (Integer);
>
> or
>
> type
> TFPGListLongInt = specialize T
On Sat, Jan 26, 2013 at 5:17 AM, Sven Barth wrote:
> One could also do an alternative (though currently not with arrays, but with
> type helper support even that would be possible...):
Yes, this is certainly the most interesting alternative. Actually,
anonymous procedures/closures
is the "real" t
On Sat, Jan 26, 2013 at 9:50 AM, Marco van de Voort wrote:
>> Whatever the particular syntax, I do agree that the decision to use
>> angular brackets
>> was unnecessarily copied from C++ -- round ones (or, at least, square
>> ones) would be much better.
>
> Delphi got its generics from .NET. The .
On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
wrote:
>> Generics was implemented without my knowledge. I only found out when
>> suddenly
>> the classes unit had been changed to use them. After a horrible
>> discussion, this was reversed, because of the drop in speed you got when
>> using generics.
On Sat, Jan 26, 2013 at 10:34 PM, Michael Van Canneyt
wrote:
> But if I must choose between
>
> for a,b in c do
>
> (with C a tuple enumerator/iterator) or
>
> for a in c index b do
>
> Then the former is ten times (well, a lot) better.
>
> So if someone were to introduce that to solve the origina
On Sat, Jan 26, 2013 at 10:58 PM, Sven Barth
wrote:
>
> I mean less the implementation specific details, but more the syntax they
> chose:
>
> === example begin ===
>
> TTestTuple = tuple of (Integer, String, TObject);
>
> var
> t: TTestTuple;
> i: Integer;
> s: String;
> o: TObject;
> beg
On Sat, Jan 26, 2013 at 3:14 PM, Hans-Peter Diettrich
wrote:
> Alexander Klenin schrieb:
>> 2) Indeed, introducing tuples to Pascal might be an alternative
>> solution. Below is a proposal:
>> 2.1) Tuple definition. Tuple is an anonymous list of values, possibly
>> of
On Sun, Jan 27, 2013 at 12:26 AM, Paul Ishenin wrote:
> 26.01.13, 6:57, Alexander Klenin пишет:
>
> Why to invent a new solution if Delphi already have one:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
>
On Sat, Jan 26, 2013 at 8:31 PM, Sven Barth wrote:
> On 25.01.2013 23:57, Alexander Klenin wrote:
>> You have also proposed lambda-expressions:
>>>
>>> map.Iterate(lambda TFPGMapLongInt.TIteratorProc(aKey, aData) as
>>> Writeln(aKey, ' => ', aDat
On Sun, Jan 27, 2013 at 1:59 AM, kyan wrote:
>> I assume this is because anonymous functions are not plain methods. Thus
>> they are not compatible with TMethod (the type behind "procedure/function of
>> object"). They are instead based on a different (internal) type.
>
> Please take a look at thi
On Sun, Jan 27, 2013 at 1:05 AM, Mark Morgan Lloyd
wrote:
> Sven Barth wrote:
> Some way of extending a single value to fill a tuple where all the elements
> are of the same type would be useful, note that I'm not suggesting any other
> relaxation of type checking.
>
> (x, y, z) := (0, 0, 0);
On Sun, Jan 27, 2013 at 3:10 AM, Sven Barth wrote:
> On 26.01.2013 16:34, Alexander Klenin wrote:
>> Ok, then let's take just one step back:
>> SomeProc(lambda TProc1 as Writeln(aArg));
>>
>> This way, but problems are solved -- procedure type is specified
>>
On Sun, Jan 27, 2013 at 3:51 AM, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> >
>> > Please take a look at this:
>> > http://blog.barrkel.com/2010/01/using-anonymous-methods-in-method.html
>>
>> While this article
On Sun, Jan 27, 2013 at 4:43 AM, Sven Barth wrote:
> Based on the results of the "for-in-index" thread I've decided to come up
> with a draft for the Tuple type which is thought by many people to be a
> better alternative to "for-in-index".
>
> Please note the following points:
> * This is not the
On Sun, Jan 27, 2013 at 8:40 AM, Mark Morgan Lloyd
wrote:
> If you can't define a tuple type then you can't check that it's
> assignment-compatible with e.g. an array.
I do not see a link here.
>> 2.2) Tuples construction: after some thinking, I propose to define a
>> plain comma as an operator c
On Sun, Jan 27, 2013 at 12:11 PM, Alexander Klenin wrote:
> Nothin useful is gained by abbing extra pair of brackets.
Sorry, I mean "Nothing useful is gained by adding ..."
--
Alexander S. Klenin
___
fpc-devel maillist
On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich
wrote:
>> (a, b) := (b, a); // the compiler needs to ensure the correct usage of
>> temps here!
>
>
> What will happen here?
>
> At compile time a tuple type (integer; integer) has to be defined, and an
> instance must be allocated for it. I
On Sun, Jan 27, 2013 at 10:10 PM, Michael Van Canneyt
wrote:
>> 2.1) Tuples are always temporary and anonymous. You can not store a
>> tuple, define tuple type, of variable of tuple type.
>> So tuples are 100% static, compile-time feature -- no change to
>> RTTI, variants etc.
> No.
>
> I think t
On Sun, Jan 27, 2013 at 11:29 PM, Michael Van Canneyt
wrote:
>>
>> Let me restate:
>> 1) Tuple as a type does nothing new compared to a record, except for
>> possibility to omit field names.
> That's all we need.
I disagree. In fact, the ability to omit field names is, in my opinion,
the least val
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin wrote:
> 27.01.13, 1:43, Sven Barth wrote:
>>
>> Based on the results of the "for-in-index" thread I've decided to come
>> up with a draft for the Tuple type which is thought by many people to be
>> a better alternative to "for-in-index".
> I think it
On Mon, Jan 28, 2013 at 1:38 AM, Jonas Maebe wrote:
> you no longer have a tuple type, but rather a
> deconstruct_into_component_types()
> type conversion operator along with anonymous records.
Yes, this is quite close to what I wanted to propose.
I am glad someone has understood me :)
Please see
On Mon, Jan 28, 2013 at 2:01 AM, Martin wrote:
>> Of course. But note that in this thread, many more uses of tuples
>> (which I do NOT want to make a type -- see my previous mail for
>> lengthy explanation why).
>> Some of the uses are: record and array constructors, adaptation of
>> inconvenient
On Mon, Jan 28, 2013 at 2:59 AM, Michael Van Canneyt
wrote:
>
>
> On Mon, 28 Jan 2013, Alexander Klenin wrote:
>> I have a compromise suggestion:
>> Implement for-index extension with the syntax:
>> for (k, v) in a do
>> this syntax is forward-compatible with bo
On Mon, Jan 28, 2013 at 4:19 AM, Michael Van Canneyt
wrote:
> Define an iterator type/operator.
>
> - No interface
> - No 'specially named function' in the class. The iterator should be
> separate from the class.
> Now they promoted 1 function with a special name to a special status:
> 'GetEnumera
On Mon, Jan 28, 2013 at 4:46 AM, Hans-Peter Diettrich
wrote:
> Preface: In the following I assume that tuples can be implemented by
> records. The proposed syntax extensions can be applied to records as well,
> they are not restricted to a new type.
Ok, with a few caveats listed below.
>> Any ti
On Tue, Jan 29, 2013 at 12:39 AM, Paul Ishenin wrote:
>>> I would use anonymouse methods in pascal - I use them in javascript
>>> when I need to perform something asynchronosly.
>>
>>
>> Since you can do the same with simple named methods too, I see no need
>> for creating the readibility horror t
On Mon, Jan 28, 2013 at 7:25 PM, Hans-Peter Diettrich
wrote:
>> Consider these examples:
>> var
>> x, y, z: Integer;
>> pt: TPoint;
>> ...
>> (x, y) // record a, b: Integer; end;
>> (x, (y))// record a, b: Integer; end;
>> (x, (y, z))//
On Sat, Feb 2, 2013 at 7:42 PM, Nikolai Zhubr wrote:
>
> Apparently the test suite database needs some love?
Wow, I did not even know such a thing existed! How is it populated?
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepasca
On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell wrote:
>> point.x := x;
>> point.y := y;
>> s := point.ToString;
>>
> or
> s := (x,y).ToString;
>
> Has there not recently been a discussion on Tupels ?!?!?! :-)
>
At least according to my proposal, tuples will not be a type,
so you'll have
On Sat, Feb 9, 2013 at 1:13 PM, Vittorio Giovara
wrote:
> I think we could make this work thanks to the Google Summer of Code! This
> program (*if* they announce it) basically introduces students to the world
> of FOSS development by having them work on projects for an open source
> organization d
On Sun, Mar 3, 2013 at 11:21 PM, Sven Barth wrote:
>> This will also help to split implementation.
>> 1. Implement Sven's proposal. Anonymous functions which can capture
>> local variables only by value.
>> 2. Create Delphi-compatible capturing by reference.
>> 3. Discuss and implement short lamb
On Mon, Mar 4, 2013 at 11:15 AM, Graeme Geldenhuys
wrote:
> >From what I can see, anonymous methods are just like the above code...
> allowing a declaration of a procedure/method in-line inside a code block
> where in shouldn't belong. It is very, very un-Pascal like.
Because computer science is
On Mon, Mar 4, 2013 at 4:06 PM, Boian Mitov wrote:
> Here is another even simpler example:
>
> AItem := GComponentEditorList.Find(
>function( AItem : IComponentEditorItem ) : Boolean
>begin
> Result := ( AComponent is AItem.GetInstance().ComponentCl
On Mon, Mar 4, 2013 at 2:38 PM, Martin wrote:
> Closures, do not need to be written/declared in the middle of other code
> (in-line)
Strictly speaking, they do not. However, if the closures are required
to be named,
their expressive power and readability will suffer greatly.
Nevertheless, I ag
On Mon, Mar 4, 2013 at 10:35 PM, Martin wrote:
> On 04/03/2013 06:06, Boian Mitov wrote:
>>
>> It may be a good idea to analyze the current Delphi implementation.
>> In essence the anonymous method expands to a class and interface.
>> The interface Execute method has the parameters of the anonymou
On Mon, Mar 4, 2013 at 10:34 PM, Martin wrote:
> Nevertheless, I agree what the implementation plan can be detailed even
> further:
> 1) Anonymous procedures *without* closures -- basically, just another
> syntax for nested procedures.
>
> That might be interested for mode Delphi
No, this would be
On Tue, Mar 5, 2013 at 1:28 AM, Michael Van Canneyt
wrote:
> Pascal is declarative,
Please... no, Pascal is not declarative, and we have establised that
fact just about two weeks ago.
>not functional.
>Trying to import elements from the second into the first is misguided.
Pascal is also procedura
On Tue, Mar 5, 2013 at 1:49 AM, Sven Barth wrote:
>> The use of "as" is based on an idea of mine. C# for example has "=>" and
> Oxygene has "->" which I didn't consider much Pascal like. Also the compiler
> needs to know the type of the lambda so it can correctly typecheck its code
> (after all we
On Tue, Mar 5, 2013 at 2:10 AM, Martin wrote:
>
> First: Stressing out: I don't like it. But if we must have one, the lambda
> approach is the best one yet.
> Reason: At least the type is declared at a pascal-like location.
I certainly agree that it is subjective in the sense that some persons
do
On Tue, Mar 5, 2013 at 3:34 AM, Martin wrote:
> On 04/03/2013 16:05, Alexander Klenin wrote:
>>
>> Anonymous functions (with good syntax, of course) fall in this category.
>> The world recognized that fact -- rather slowly, to be sure, but
>> remember that "while&q
On Tue, Mar 5, 2013 at 9:10 PM, Paul Ishenin wrote:
> 05.03.13, 17:55, Sven Barth wrote:
>
> I see you, Graeme, Michael and probably some more 5-6 developers.
>
The level of Delphi compatibility vs. syntax quality is, as always in
engineering,
a matter of compromise and cost/benefit analysis.
For
On Tue, Mar 5, 2013 at 10:24 PM, Marco van de Voort wrote:
>> Just to say one thing clear: I will NOT drop FPC's generic
>> implementation and I'll revert every commit that tries to do so, because
>> not only do we have to keep backwards compatibility, but the Delphi
>> syntax is a nightmare to pa
On Wed, Mar 6, 2013 at 12:16 AM, Sven Barth wrote:
>
> SomeVar := SomeFunc - SomeType.SomeMethod *
> SomeOtherType.SomeMethod;
>
> === example end ===
>
> while this will be much easier to implement:
>
> === example begin ===
>
> SomeVar := specialize SomeFunc - specialize
> SomeType.SomeMethod *
On Wed, Mar 6, 2013 at 12:27 AM, Sven Barth wrote:
> I don't know why the one who first implemented them chose them, but now the
> reason is backwards compatibility.
>
> Please note that I wouldn't have choosen round brackets either (potential
> conflicts with type casting)
Is not "specialize" ke
1 - 100 of 311 matches
Mail list logo
