Re: Modern Pascal Dialect [was Re: [fpc-devel] Re: [fpc-l] type discussion]
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 in this list. I asked the very same thing. For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar. If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here. I've been playing with the same concept for years, so I think I do have some advice :-) The preprocessor is the right step to start. I have a working scanner and the next tasks (conditional compilation and expressions) planned in detail. If you're interested, we could share the work. -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
El Viernes, 3 de Junio de 2005 09:56, Marco van de Voort escribió: If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. In the executable? Isn't there any previous step to hook into? Anyway, where could I find information about the structures that should be edited? -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to manually control debug information
El Viernes, 3 de Junio de 2005 11:44, Marco van de Voort escribió: El Viernes, 3 de Junio de 2005 09:56, Marco van de Voort escribi?: If you have a preprocessor, you will also need a binary postprocessor to edit the linenumbers. In the executable? Isn't there any previous step to hook into? Yes. The generated assembler. Anyway, where could I find information about the structures that should be edited? gcc docs mainly (stabs) Thank you, also Florian and Peter, of course. It seems that I have more than enough options :-) -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modernising Pascal
El Viernes, 25 de Febrero de 2005 01:36, Sebastian Kaliszewski escribió: You could do partial GC as well. No one forces yo to do GC on everything. Free Pascal object model is very flexible. If I'm not mistaken, it's compatible with Delphi so it has the same construction mechanism so it's possible to override InstanceSize, InitInstance, NewInstance and FreeInstance. There is also a reference counting hooks for interfaces. Combining all these facilities, it's possible to create a parallel hierarchies of objects that use reference count or garbage collection. -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:
you are forciblly putting an out of range value in a variable what do you
expect to happen?
I think it's slightly subtler. I guess that this code:
if not b then
WriteLn('False')
else if b then
WriteLn('True')
else
WriteLn('Other');
...could throw a different result.
IIRC, any non-zero value is evaluated as True for a Boolean variable. The
problem with the case statement is that Jesús is asking the compiler which
specific value it chooses for assignements... and getting surprised because
it's not what he expected. I guess the compiler uses 1 instead of 255. But
it's surely documented anyway.
--
saludos,
Nico Aragón
[EMAIL PROTECTED]
http://espira.net/nico/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Sábado, 1 de Enero de 2005 09:06, Jose Manuel escribiste: So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of As far as I know: Ord(True) Ord(False) = True Succ(False) = True ...are not only legal but also mandatory in the standard. But that doesn't mean anything. You can implement Ord and Succ to return that values for booleans no matter how you implemented the type. type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant). It's possible to implement the boolean type as an enumeration and still implement the boolean evaluation as 0. I'm pretty sure to have seen this in some specification, I just can't remember in which right now :-) -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
[merged responses to two messages] El Sábado, 1 de Enero de 2005 06:54, DrDiettrich escribiste: ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-) http://hotel.jp-guide.net/job/point/melon.jpg (Eierkopf? ;-) My rudimentary... I meant my non-existent... whatever :-) ¡Feliz año, torpedo! :-) (Blindgänger? ;-) It's the same in English. Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein Gutes Neues Jahr allerseits! All of that! :-) * El Sábado, 1 de Enero de 2005 06:29, DrDiettrich escribiste: Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. I don't. Do I? Yes, you do. No, I don't. Maybe you're confusing me with Jesús? If you read my last answer to José Manuel, you'll see that I say exactly the opposite. So I can't agree more with the rest of your post. -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Viernes, 31 de Diciembre de 2004 17:18, Florian Klaempfl escribiste: That's great! But why do you tell it *to me*? I only cross read the thread and wanted to clarify things :) Oh, I see. Happy new year! :-) -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Viernes, 31 de Diciembre de 2004 18:40, Jose Manuel escribiste:
else
WriteLn('Other');
This better should read:
WriteLn('corrupt data space!!!'); Panic;
Much more useful :-
(AFAIK) you do.
¡Serás melón! ¿A qué se supone que estás respondiendo ahí? X'D
You're programing, the C way.
You can't expect that -1 equals True, and any other value equals false, (I
You can expect whatever it's documented equals true and sometimes you must
know what's the internal representation of the data, i.e. when you're linking
with code written in different languages or writing inline assembler.
¡Feliz año, torpedo! :-)
--
saludos,
Nico Aragón
http://espira.net/nico/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Jueves, 30 de Diciembre de 2004 22:48, Jesus Reyes escribiste: procedure doAorB(value: boolean); begin case value of true: doA; false: doB; end; end; if Value then DoA else BoB; -- saludos, Nico Aragón http://espira.net/nico/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Mon, 20 Sep 2004 00:37:44 +0600, Yakov Sudeikin [EMAIL PROTECTED] wrote: You can just take the source code and do what you want with it and release it as AragonPascal or whatever. Thank you for your interest. But I'm writting something more alike a text editor than a compiler. I will need some compiler type code to do syntax highlightning, code completion and so on, but it seems easier to write the needed parts from scratch. -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Sun, 12 Sep 2004 13:02:52 +0200, Marc Weustink [EMAIL PROTECTED] wrote: Procedure Something; Var T:tMyClass;Auto; Begin - T auto created here ... If ... Then Exit; - T auto destructed here ... End;- T auto destructed here P.P.S. The auto modifier should affect only stack variables. There's no great need of this for global vars. Again, what if you assign T to a global var or a class member ? Why would you want to do that? You still can declare var T: MyClass if you plan to use T as a local reference. Obviously you only declare variables as automatic when you want to bind its lifecycle to the current procedure. -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Sun, 12 Sep 2004 13:07:24 +0200 (CEST), [EMAIL PROTECTED] (Marco van de Voort) wrote: Absence of automatic construction/destruction of classes is very painfull and it can significantly degrade the development process (i.e. smart pointers and RAII are impossible). Very painfull is a bit exaggerated :-) Sometimes, it's. F.i.: procedure CopyFile(SourceFileName, TargetFileName: string); var s, t: TStream; begin s := TFileStream.Create(SourceFileName, fmOpenRead); try t := TFileStream.Create(TargetFileName, fmCreate); try t.CopyFrom(s); finally t.Free; end; finally s.Free; end; end; Imagine you could write: procedure CopyFile(SourceFileName, TargetFileName: string); auto s, t: TStream; begin s := TFileStream.Create(SourceFileName, fmOpenRead); t := TFileStream.Create(TargetFileName, fmCreate); t.CopyFrom(s); end; Eight lines instead of sixteen and much clearer. The compiler would internally translate it to something like: procedure CopyFile(SourceFileName, TargetFileName: string); var s, t: TStream; begin // -- Start initialization block --- s := nil; t := nil; try // -- End initialization block - s := TFileStream.Create(SourceFileName, fmOpenRead); t := TFileStream.Create(TargetFileName, fmCreate); t.CopyFrom(s); // -- Start finalization block - finally s.Free; t.Free; end; // -- End finalization block --- end; I guess it's much alike to what happens with AnsiStrings. Are there any plans for serious language extensions in this way for post 2.0 releases of FPC ? No. There is a big resistance against such features, mostly because the benefits are superficial, and the idea is unpascallike. What I like of Pascal is clarity. I feel much more pascal-like the eight lines version than the sixteen lines one. And you can still declare normal variables with explicit destruction. It's not like Java and other languages that forces you to use automatically disposed variables. You can choose. I wonder what big resistance means exactly. It could be that none of FPC developers wants to spend his time with this feature. But what if someone implemented it as a patch? Would it be rejected? Another option: would it be possible to plug in the compiler to add user extensions? Moreover it will be a Delphi incompability. * You aren't forced to use this feature. You can be compatible simply not using it. * There are other FPC features that aren't present in Delphi like overloaded operators. * It's better to be incompatible because you have more features than because you have less features. * Delphi is going to implement something like this anyway to keep its compatibility with its .NET version. P.S. The simpliest proposal for syntax for auto construction/destruction could be like (maybe with some restrictions on constructors/destructors): Procedure Something; Var T:tMyClass;Auto; Begin - T auto created here ... If ... Then Exit; - T auto destructed here ... End;- T auto destructed here P.P.S. The auto modifier should affect only stack variables. There's no great need of this for global vars. I don't like it. Either go the full way (like e.g. with ansistrings) or don't go there at all. This is a hack. Why? Its implementation is straight-forward, simpler than ansistrings' and eliminates all that distracting memory plumbing code. -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Sun, 12 Sep 2004 15:28:40 +0200 (CEST), [EMAIL PROTECTED] wrote: procedure CopyFile(SourceFileName, TargetFileName: string); auto s, t: TStream; begin s := TFileStream.Create(SourceFileName, fmOpenRead); t := TFileStream.Create(TargetFileName, fmCreate); t.CopyFrom(s); end; It is not so easy. What about the following code: procedure CreateIOStream(Var AStream : TStream); auto t: TStream; begin s := TFileStream.Create(SourceFileName, fmOpenRead); // Something AStream:=S; end; This code is wrong. If you use auto, your goal is to schedule the variable for destruction when the current function is left. If you want the variable to survive outside, then you should declare it as normal var. The question would be how should the compiler react to this error. I think that issuing a warning would be a sensible choice, because it's sort of symmetrical to variable 'foo' might not have been initialized. Borland way, since the first versions of TP has been to allow programmers to shoot theirselves in the foot... if they're really decided to do so and explicitily state it. Here the assignment is explicit, but it could be implicit as well. A direct assignment (to global variable or output parameter) would be easy to detect and warn the programmer. If you use Move or something like that, then you're badly begging to shoot yourself in the foot :-) I can only think of a case, that's really difficult (not impossible) to track: a local variable that is assigned to a global one by means of a call to a function. It's not possible to solve this kind of issue without some form of reference counting. Reference counting is more complex. You have written the implementation for ansistring anyway. It would be nice to have it extended to objects too. The matter has been discussed several times by the FPC core group, at great length. No satisfying solution on which everyone agreed was reached. I would really appreciate some comments on my question about patches that would implement optional, unofficial or pluggable features. I would like very much to be able to build extensions for particular idioms. I understand that not everybody will like this possibility. The question is if core developers would dislike it so much as to prefer to keep it off the official code. It's also possible to implement extensions using some kind of preprocessor. But then a lot of code would be duplicated because the preprocessor must do a considerably more complex job than macro substitution... much like what the compiler itself does later. I'm not asking just out of curiosity. I have some ideas and code and would like to know if/how could fit with FPC. -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Sun, 12 Sep 2004 17:38:22 +0200 (CEST), Peter Vreman [EMAIL PROTECTED] wrote: Plugin support for the parser is impossible, everything is too much dependent on other parts. Only assembler/linker etc. could maybe made an plugin. Would it be feasible to write a different parser that outputs some intermediate format to pass to code generator? -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello,
On Sun, 12 Sep 2004 20:38:52 +0400, [EMAIL PROTECTED] wrote:
Again, what if you assign T to a global var or a
class member ?
Why would you want to do that?
You still can declare var T: MyClass if you plan to
use T as a local
reference. Obviously you only declare variables as
automatic when you
want to bind its lifecycle to the current procedure.
The problem actualy is not in automated destructors,
but in that the Class
types are actually pointers in Delphi OO model. That
IIRC, at binary level everything is in place:
var
x: TSomeClass;
{ I don't know if following line would compile,
but it could be hardcoded }
y: array[1..SomeClass.InstanceSize] of Byte;
begin
x := SomeClass.InitInstance(@y);
x.Create(params...);
...
--
saludos,
Nico Aragón
NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Proposal for audo-destructors
Hello, On Sun, 12 Sep 2004 18:45:53 +0200 (CEST), [EMAIL PROTECTED] (Marco van de Voort) wrote: Would it be feasible to write a different parser that outputs some intermediate format to pass to code generator? It would boil down to rewriting most of the compiler, except the real assembler/linker parts, since a lot of core dataformats would change. A pity. FPC source code could be generated by external parser after translating extra features, but it would bad for debugger support, etc. It seems that I must look elsewhere. Thank you again for clarifications. -- saludos, Nico Aragón NOTE: na-list address only works for messages coming from lists. Please, write to nico at the same domain for direct email. ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
