Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-06

Re: type discussion

25 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Angelo Bertolli
Forward declarations are redundant - they exist purely for the benefit of the compiler.

I agree. I hate prototyping. That's why you use top-down design. What's wrong with that?

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. I don't think you're going to convince anyone to change THIS part of Pascal--it's essential. You change begin and end, and you just don't have Pascal anymore. Plus the only reason I love FPC is because it is faithful to older code. If it breaks my code, I'll likely go back to a previous version and I bet there are enough people who feel this way that there will be the beginning of another project based on the older FPC code.

manual memory management of tobjects is redundant as you can get good performance with ref counting tobjects.

Oh yes, this old argument. I remember reading this on the list before. I guess it's still on your mind ;) I really don't know about the pros and cons for ref counting, so maybe someone can explain it.

Reply by email

Hans-Peter Diettrich
to Angelo Bertolli
Angelo Bertolli wrote 5 lines
> 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
        ...
      end
    else
      if

...

I don't think you're going to convince anyone to change THIS part of Pascal--it's essential. You change begin and end, and you just don't have Pascal anymore.

Some things could be changed, and have been changed for good reasons, in subsequent designs (Modula, Oberon). When all arbitrary occurrences of statement and statement_sequence in the Pascal grammar are replaced by a unique statement_list, where a statement list is terminated with an "end", the whole language becomes simpler and much clearer. It also will eliminate the "dangling else" ambiguity, that exists in the majority of all existing language designs.

You'll notice the difference neither by looking at the code, written according to this syntax, nor by simply looking at the grammars. But you'll notice the difference when you're writing the parsers and find the semantics actually different from the syntax. In many languages the syntactical grammar is a simplified and generalized picture of the semantics, so that the parser has to check for specific cases in many places. In good designs, as provided by Wirth, no difference between syntax and semantics can exist.

This unfortunately is no more true for OPL, where optional semicolons must be introduced into to the syntax in very many places. Then only the parser can decide, whether in such places a semicolon is actually mandatory, optional, or illegal, depending on whether a semicolon has already been consumed by some preceding optional occurence. Consequentially the meaning of some code can change dramatically, only depending on the occurence or absence of a semicolon in a specific place! My favorite example:

case i of
0: if a then b
; //<--- illegal, optional or required?
else c
end;
Show quoted text 6 lines
> manual memory management of tobjects is redundant as you can get good > performance with ref counting tobjects. > Oh yes, this old argument. I remember reading this on the list before. I guess it's still on your mind ;) I really don't know about the pros and cons for ref counting, so maybe someone can explain it.

Two cons for reference counting:
- It fails on circular references. Fatal :-(
- Counting operations increase with the number of executed statements.

Mark/sweep collections, in contrast, increase with the number of object creations, not with the number of object uses. But their execution time depends on the number of existing object references, regardless of whether objects really can be removed.

Both kinds of garbage collection can work (reliably) only under specific conditions, which are not satisfied in OPL :-(

DoDi

Reply by email

Jamie McCracken
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 13 lines
>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 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.

Two cons for reference counting: - It fails on circular references. Fatal :-(

Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that.

jamie.

Reply by email

Michael Van Canneyt
to Jamie McCracken
Jamie McCracken wrote 19 lines
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 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.

Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal...

Michael.

Reply by email

Jamie McCracken
to Michael Van Canneyt
Michael Van Canneyt wrote 30 lines
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 - 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. Visual, yes. But not for the compiler: it folds whitespace. The compiler NEEDS the begin...end to check your syntax. How is it supposed to know where a stament block begins/ends ? Based on indendation alone ? That would not be Pascal...

yes you are right it exists for the benefit of the compiler rather than the developer.

My plan in the RAD Pascal dialect is to preprocess each line and put back the begin/end where the indentation occurs/varies without altering the line numbers. The compiler already has an internal preprocessor so I will simply be extending that. If the end result is not to your liking then continue using other dialects as none of my changes will affect them. Of course there is nothing stopping you from continuing to use begin end blocks in RAD Pascal if you really want to but they will be optional whereas indenting will be compulsory (you will get an error if your indenting is not consistent!)

jamie.

Reply by email

Daniël Mantione
to Jamie McCracken: lol - thats not what I meant. If you want readable code you indent inside the begin..end…

Op Sun, 5 Jun 2005, schreef Jamie McCracken:

Show quoted text 13 lines
Its not a black or white issue IMO its a shade of grey. At the end of the day you have to make a judgement call based on the facts. Im asserting that with non-component objects the incidence of cycles is so rare that provided we have a means of adding weak refs so that knowledgable developers can overcome them when they do occur then the issue of cycles can be ignored - after all if the probability of leaks is based on a one in a million occurance of a cycle (Im not saying thats an accurate probability!) coupled with an ignorant or naive developer then thats an acceptable risk to me. If it turns out that cyclic occurances are far more common than that then yeah that could be a killer. There are of course workarounds but I dont like any of them - EG python 2.3 does ref counting but also uses a mark sweep GC to mop up cicrular refs but I really dont think we need to consider that.

Hmmmm... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example.

Daniël

Reply by email

Jamie McCracken
to Daniël Mantione
Daniël Mantione wrote 22 lines
Op Sun, 5 Jun 2005, schreef Jamie McCracken: >Its not a black or white issue IMO its a shade of grey. At the end of >the day you have to make a judgement call based on the facts. Im >asserting that with non-component objects the incidence of cycles is so >rare that provided we have a means of adding weak refs so that >knowledgable developers can overcome them when they do occur then the >issue of cycles can be ignored - after all if the probability of leaks >is based on a one in a million occurance of a cycle (Im not saying thats >an accurate probability!) coupled with an ignorant or naive developer >then thats an acceptable risk to me. If it turns out that cyclic >occurances are far more common than that then yeah that could be a >killer. There are of course workarounds but I dont like any of them - EG >python 2.3 does ref counting but also uses a mark sweep GC to mop up >cicrular refs but I really dont think we need to consider that. Hmmmm... I don't think a programming language where one cannot safely build graphs or ringbuffers will be very powerfull. Writing a compiler in it would be impossible to give an example.

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?

My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs?

jamie.

Show quoted text 9 lines
Daniël _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jamie McCracken
to L505: | | lol - thats not what I meant. If you want readable code you indent | inside the…
L505 wrote
Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline?

of course it is - any formal language will have some "bondage" in their syntax. Indentation and Begin..End are such examples but in my case forcing developers to write properly indented code (which is essential for legibility as im sure you will agree) is not a disadvantage as such if you consider it a neccesity anyhow.

I suggest you wait until I have something working then we can discuss the finer points.

jamie.

Reply by email

Daniël Mantione
to Jamie McCracken: yes but isn't it fair to say that such developers that require such structures would be…

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?

Show quoted text 6 lines
My point is that the everyday structures that most developers (and in particular the more naive and less knowledgable ones) will use are not vulnerable to cycles and its only the more obscure and specialised use cases that will need to use weak refs. In those cases like building a compiler is it reasonable to assume that they will be smart enough to handle cycles with weak refs?

I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes using them hard or impossible becomes a toy language.

Hmmm... Is a double linked list a cycle? I think yes.

Daniël

Reply by email

L505
to Jamie McCracken: lol - thats not what I meant. If you want readable code you indent inside the begin..end…

|
| 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 question marks if you know it is a question? If there is a space after the question, and the question always starts with something like "what", "where" "when" why", then -what good- is a question mark?

There are plenty of reasons. One is that the human brain doesn't have time to figure out whether or not it is a question.. it is just a extra helper symbol to verify that. The other is that if you are looking specifically for questions and you don't have time to read the entire article, at least you can easily see them ( ¿even easier in spanish?). The other is that when you start deleting words from the sentence, at least the question mark still is there after you've deleted some text. And you know that the structure of words is still supposed to be a question, even if after deleting things. You would have less change of knowing it was a question if there was no question mark.. because after deleting some stuff and reorganizing your article, it may appear as though it is a regular sentence, not a question.

Personally I like spanish upside down question mark, because it would help me when I was scanning articles for questions from forward to end. English question marks only help me when I am scanning the article from backward to forward. I've never taken or learned spanish though, so I am not bias. So maybe you think spanish is redundant, but I think even one question mark is sometimes not enough.

Start deleting your code without begin end blocks and reorganizing things.. if these visual pointers are not there you may end up putting code in places that are not correct, because you accidentally lost that indentation while hitting delete key, and while the editor wasn't indenting the way you thought it would. If the begin end were there, at least you'd have a secondary opinion from the code telling you.. "hey.. wait, this is supposed to be a begin end block here, even if your indentation is wrong after refactoring."

I lost my indentation, but at least I know where it goes, due to the secondary helpers
begin and end. Just because my text editor was acting funny with tabs today, all my
code is not broken? Because of the secondary savers.
begin
Ididntindent:= 'yes';
afterrefactor:= true;
end;

Where does this code go below? I lost my indentation, so where does it go in the code??? Just because my text editor was acting funny with tabs one day all my code is broken now?
Ididntindent:= 'yes';
afterrefactor:= true;

Personally, I use indenting for other parts of organizing code once in a while.. not just for begin end. So if was to write:

othervar:= 'test';
othervar2:= 'test2';
  setting1:= true;
    for i:= 1 to 5 do
    begin
      edit1.color:= red;
      ...
      ...
    end;
othervar:= 'testa';
othervar2:= 'testb';
   setting2:= true;
     for i:= 1 to 5 do
     begin
       edit1.color:= red;
       ...
       ...
     end;

See how setting1 and setting2 is tied to the for statement using indentation of the for statement? I do that because the for statement only applies to setting 2. Helps organize code. Helps show that setting2 only really applies to that for statement. So if I had forced indentation on me, that may be illegal and that may initiate a begin end when I didn't even want it to.

Now there are some bondage discipline languages and Pascal is considered one.. even though it's not case sensitive.. isn't indentation sort of bondage-discipline?

Reply by email

L505
to Jamie McCracken: yes you are right it exists for the benefit of the compiler rather than the developer. My…

| yes you are right it exists for the benefit of the compiler rather than | the developer.

incorrect. When reading code I always use the bold begin/end's. Why do you think they are bold? Are they bold because the compiler likes them bold? See, a bold begin and end is a lot easier to see than a parenthesis. Parenthesis is tough to see on a high res monitor. There is a reason begin and end are bold, and that has nothing to do with the compiler. They are useful also for the developer.

Reply by email

Jamie McCracken
to Daniël Mantione: Op Sun, 5 Jun 2005, schreef Jamie McCracken: What is a weak ref? I don't know, anyway,…
Daniël Mantione wrote 9 lines
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 affecting the ref count of an object.

Show quoted text 13 lines
>My point is that the everyday structures that most developers (and in >particular the more naive and less knowledgable ones) will use are not >vulnerable to cycles and its only the more obscure and specialised use >cases that will need to use weak refs. In those cases like building a >compiler is it reasonable to assume that they will be smart enough to >handle cycles with weak refs? I don't know, anyway, structures like trees, graphs, stacks, ringbuffers, linked lists etc. etc. are the basis of programming. A language that makes 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 most likely case for that is if you added a self reference -

EG

mylist : Tlist;
mylist := TList.create;
mylist.add (mylist);
// now you have a self referencing cycle

The above could still be implemented safely in the add method of Tlist by testing for a cycle and using a weak ref to add mylist to mylist. BUt of course why would you ever want to add a self referencing cycle to a TList?

Hmmm... Is a double linked list a cycle? I think yes.

I dont think so. The list nodes are usally a record/struct not an *object* and whilst they do form a chain, the items pointed to in the list dont point back to that list so no it is not a cycle.

Cycles are rare by the nature in objects however they are more common in GUIs where widgets and components link together.

jamie.

Reply by email

Michael Van Canneyt
to Jamie McCracken: yes you are right it exists for the benefit of the compiler rather than the developer. My…
Jamie McCracken wrote 46 lines
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 - 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. > > > Visual, yes. But not for the compiler: it folds whitespace. > The compiler NEEDS the begin...end to check your syntax. How is it > supposed to know where a stament block begins/ends ? Based on indendation > alone ? That would not be Pascal... yes you are right it exists for the benefit of the compiler rather than the developer. My plan in the RAD Pascal dialect is to preprocess each line and put back the begin/end where the indentation occurs/varies without altering the line numbers. The compiler already has an internal preprocessor so I will simply be extending that. If the end result is not to your liking then continue using other dialects as none of my changes will affect them. Of course there is nothing stopping you from continuing to use begin end blocks in RAD Pascal if you really want to but they will be optional whereas indenting will be compulsory (you will get an error if your indenting is not consistent!)

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.

The compiler is GPL, so you are free to change it, but that doesn't necessarily mean your changes will make it back in the compiler main sources. Things that are considered constructive, may make it in. This does not fall under that category, in my opinion.

Michael.

Reply by email

Jamie McCracken
to Michael Van Canneyt
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 give it a chance. If you still feel bad about it then we can discuss what to do then. If it turns out that you all insist on begin..end being mandatory then i 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 hope that's taken into account.

The compiler is GPL, so you are free to change it, but that doesn't necessarily mean your changes will make it back in the compiler main sources.

If not I can always maintain a branch that does. (though I would prefer it if it is included of course)

jamie.

Reply by email

Jonas Maebe
to Jamie McCracken
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 people who wish to continue this thread to either move to fpc- other, or to continue in private.

Thank you.

Jonas
FPC mailing lists moderator

Reply by email

Michael Van Canneyt
to Jamie McCracken: Well all I ask is you wait til I have written it then give it a chance. If you still feel…
Jamie McCracken wrote 12 lines
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 give it a chance. If you still feel bad about it then we can discuss what to do then. If it turns out that you all insist on begin..end being mandatory then i will respect your wishes and no feelings will be hurt.

Look, it's a matter of principle. I consider ANY language which uses the amount of whitespace in it's grammar to be inherently badly designed.

I believe it will help Pascal and breathe new life into it especially as its a dying language.

It has lived longer than most languages, so I don't think this is so.

I also note there is no such thing as "Pascal" as such even Delphi has significant syntax differences with earlier pascal variants so I hope that's taken into account.

No it is not. The change you suggest is fundamentally different from the dialects we have till now; you are changing one of the fundamental principles, namely whitespace is irrelevant, just as casing is. This is, in my eyes, a different language - anything BUT pascal.

Show quoted text 8 lines
> > The compiler is GPL, so you are free to change it, but that doesn't > necessarily mean your changes will make it back in the compiler main > sources. If not I can always maintain a branch that does. (though I would prefer it if it is included of course)

Not if I can help it.

I realize this may come over quite hard, but I prefer you would do something USEFUL which actually contributes to Free Pascal. Creating yet another obscure dialect is not helpful. We are having enough problems getting in Delphi compatibility stuff. It would be MUCH more appreciated if you would help with that.

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.

You want to be useful ? Do one of the following:
- Complete Variant support.
- Implement Packages support.
- Overloading for property indexes.
- DISPINTERFACE support, plus OLE automation calls.
- Extend the Optimizer.

You want to make some 'Auto-Maintained' variable support, of the kind: Autovar

  S  : TStrings;
begin
  S:=TStringList.Create;
end; // compiler disposes of S.

Please, go ahead. Anything that is useful. But not creating another dialect.

I've been on the compiler team for almost 10 years, and we've heard lots of crazy offers in that time. We've ignored most of them, and good too, or else we wouldn't be where we are today. Yours just happens to be one of them. Sorry.

I prefer to let you know in advance instead of letting you work hard and then shoot off your efforts.

Michael.

Reply by email

Hans-Jörg Vasold
to Florian Klaempfl

----- Original Message -----

Earlier message 21 lines
From: "Florian Klaempfl" To: "FPC developers' list" Sent: Sunday, June 05, 2005 3:59 PM Subject: Re: [fpc-devel] using strupper,strlower on german words > Hans-Jörg Vasold wrote: > >> StrUpper, StrLower will not work for the german "äöüß". >> >> Are any equivalent functions like Delphi's AnsiUpperCase or any fix > > AnsiUpperCase? Oh ? Sorry, wrong question! What i really want to know is : Are any equivalent functions like AnsiUpperCase avaliable for pChar parameter and result (StrLower,StrUpper works with pChar) ? cu Hans-Joerg

Reply by email

Florian Klaempfl
to Hans-Jörg Vasold
Hans-Jörg Vasold wrote 15 lines
----- Original Message ----- From: "Florian Klaempfl" To: "FPC developers' list" Sent: Sunday, June 05, 2005 3:59 PM Subject: Re: [fpc-devel] using strupper,strlower on german words > Hans-Jörg Vasold wrote: > >> StrUpper, StrLower will not work for the german "äöüß". >> >> Are any equivalent functions like Delphi's AnsiUpperCase or any fix > > > AnsiUpperCase?

AnsiStrUpper
The AnsiStr* functions operate on pchars.

http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html

For Michael vC: the remark is wrong/outdated, if you include cwstrings, language settings on linux are taken care of.

Show quoted text 13 lines
Oh ? Sorry, wrong question! What i really want to know is : Are any equivalent functions like AnsiUpperCase avaliable for pChar parameter and result (StrLower,StrUpper works with pChar) ? cu Hans-Joerg _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

L505
to Jamie McCracken: Well all I ask is you wait til I have written it then give it a chance. If you still feel…

| 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 hope that's taken into account.
|

Things like smalltalk, tcl.. those are dying according to sourceforge (40 projects or so.. whereas Delphi has hundreds or 1000's.

If you want to tell smalltalkers that they are dying because there are only 30 or 50 projects on source forge.. well go to c2.com wiki, there are plenty of them programmers there, doing work for banks and all sorts of places.

If you want to tell Borland that Delphi is dying due to dotNet, then just download any popular Delphi application out there like the latest version of totalcommander and you tell me if it has any significant amount of dotNet code in it. What is said to be "dying" is most likely a rumor placed out by foolish of fools like Bryan Kerinighan who even sell books on Pascal themselves.

In fact Pascal/Delphi is still one of the most popular languages - at one time I think there were more projects in Pascal than visual basic on source forge.. now VB has slightly more. But it's not as if there are 50 projects in Pascal... like other languages. No there are hundreds, thousands in Pascal/Delphi.

I guess the problem is that once you start changing a language, what is it anymore? When does a Mercedes car become no longer a Mercedes car when it has 80 percent your own parts on it? Wouldn't you kill the Mercedes name and call it something else.. a new breed of car? i.e. why would you even call your language Pascal or why would it have anything to do with Pascal in the first place.. why not call it something else, since it is a new breed.. Wouldn't want to carry the Pascal "bad name" anyway, right? Maybe because there is already a compiler and you want to re-use code? I don't know. I think maybe even a better place to start then might be python mailing lists or python compiler sites if there are any.

Reply by email

Michael Van Canneyt
to Florian Klaempfl: AnsiStrUpper The AnsiStr* functions operate on pchars.…
Florian Klaempfl wrote 25 lines
Hans-Jörg Vasold wrote: > > ----- Original Message ----- From: "Florian Klaempfl" > To: "FPC developers' list" > Sent: Sunday, June 05, 2005 3:59 PM > Subject: Re: [fpc-devel] using strupper,strlower on german words > > >> Hans-Jörg Vasold wrote: >> >>> StrUpper, StrLower will not work for the german "äöüß". >>> >>> Are any equivalent functions like Delphi's AnsiUpperCase or any fix >> >> >> AnsiUpperCase? AnsiStrUpper The AnsiStr* functions operate on pchars. http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html For Michael vC: the remark is wrong/outdated, if you include cwstrings, language settings on linux are taken care of.

This is not so, because the cwstrings is for WideStrings only, and the AnsUpperCase is AnsiString. We'd need a separate unit to load the conversion tables for ansistrings.

Michael.

Reply by email

Marco van de Voort
to Jamie McCracken: Allows you to make a reference without increasing or affecting the ref count of an object.
Show quoted text 7 lines
> 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 most likely case for that is if you added a self reference -

I prefer languages that work, not that most likely work.

Reply by email

Hans-Peter Diettrich
to Michael Van Canneyt: Look, it's a matter of principle. I consider ANY language which uses the amount of…
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.

Show quoted text 7 lines
You want to make some 'Auto-Maintained' variable support, of the kind: Autovar S : TStrings; begin S:=TStringList.Create; end; // compiler disposes of S.

If somebody wants local objects, then he should use Object instead of Class.

DoDi

Reply by email

Hans-Jörg Vasold
to Florian Klaempfl: AnsiStrUpper The AnsiStr* functions operate on pchars.…

----- Original Message -----

Earlier message 42 lines
From: "Florian Klaempfl" To: "FPC developers' list" Sent: Sunday, June 05, 2005 4:23 PM Subject: Re: [fpc-devel] using strupper,strlower on german words > Hans-Jörg Vasold wrote: > >> >> ----- Original Message ----- From: "Florian Klaempfl" >> To: "FPC developers' list" >> Sent: Sunday, June 05, 2005 3:59 PM >> Subject: Re: [fpc-devel] using strupper,strlower on german words >> >> >>> Hans-Jörg Vasold wrote: >>> >>>> StrUpper, StrLower will not work for the german "äöüß". >>>> >>>> Are any equivalent functions like Delphi's AnsiUpperCase or any fix >>> >>> >>> AnsiUpperCase? > > AnsiStrUpper > The AnsiStr* functions operate on pchars. > > http://www.freepascal.org/docs-html/rtl/sysutils/ansistrupper.html Yes but // Tested in Lazarus Edit1.Text := AnsiStrUpper ( 'Ärzte' ) results in 'äRZTE' Edit1.Text := AnsiStrUpper ('ärzte') results also in 'äRZTE'; cu Hans-Joerg

Reply by email