FreePascal International Proyect

As you may know I'm trying to translate Pascal into "Spanish Pascal". And it's very difficult. I would like to propose you one thing before it's too late.

Somewhere I've read that you're rewriting completely the code (in order to make it faster?). Well, here is my proposal.

But first a little analogy:

====
I was reading an article in a computer magazine and it said that if Microsoft had sold so many DOS and so many Windows it was because his O.Ss where pirated (copied ilegally). It lost money, but more and more had his O.S. and later... we know the history he has the monopoly.
====

What I would like to do is make a sort of "internalization" of Pascal. Nowadays a lot of schools and universities are teaching Pascal because is one of the most easy and powerful language. (Although we all know that Delphi has to come because it's OOP).

Well, I think it would be easier for these French, Scandinavian, Russian, Spanish, German,... people to program in his/her own language.

Little by little people will use their own language version of FreePascal and then when they became professional, the English one. But these people would be less likely to program in C, Perl, Asp, or whatever language, because they would have learnt Pascal being childs.

Ok. Let's talk about the improvements on code to make it easier to translate FreePascal. You we'll have to use a common library called i.e. translat.pp, this one will have a constant like the one in tokens.pas:

ttoken and arraytokeninfo.

This file will take in account more reserved words, (rtl keywords and package standard keywords) because I've seen that you have them <past participle of spread> in many files, up to the moment:

psystem.inc, tokens.pas, ra386att.pas

What about compatibility? How will we be able to come back to normal (English) Pascal?

Well,... this file translat.pp, will have another constant, which will be for standard English tokens.
A function, procedure or whatever will be determine the English tokens that are not used by new <language> Pascal.

For instance if in Pascal/Hispascal we have:

const const
var var
procedure procedimiento
program programa

const and var will not be in the list (the red/forbiden list), but procedure and program yes.

That's too say there will be treated as tokens (you could not define a variable, or a const, or a procedure, or a function, or anything with them) but there will not have a function, in the code. They will be unuseful.

Of course, this forbiden list checking will be an option, always by default, but you could change it if you wanted to.

This red/forbidden list it's because it will be easier to make programs to translate from <language> Pascal to Pascal. No need to rename some tokens if they are not what they mean in Pascal but variables or other things.

And... that's all. Think about the schools, and they opportunity of making programming genius, because they are a lot of potential genius, but if they have to learn English to make a program, some of them don't do it.

I'm going to hibernate (to study June exams) but if I see that you haven't made any effort to make this international proyect,... don't even doubt that I will go on translating Free Pascal into Spanish or Hispascal, and, of course, asking you doubts.

See you in the future,
adrian15.

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/

And what about all the other RTL routines? And for the assembler the tokens are also used to write the assembler files for usage with an external assembler. So it's more complicated then you think!

I don't like such language. It's your own choice to translate it into Spanish. We don't have to do things, there are no contracts or such that we should do this or that. We decide ourselves what we want to code in for the compiler. And IMHO there are much more important things (widestrings, variant, multithreading) to finish first, so i guess that none of the core developpers will create a translate.pp or whatever to include all translatable tokens.

Peter

Couldn't he do this to some extent by using the macro feature of FPC?

Well, no personal offense, but i think that was a funny one. I'm not a native English speaker either and I have seen in the past similar attempts (i can remember a German BASIC and a German Pascal as well, no Open Source of course, it was at least 10 years ago) and the products ended up in nowhere. I doubt that translating the keywords of a programming language into a "local" language will have any serious advantage for those learning how to program, rather on the contrary.
One of the good things IMHO about the current, existing programming languages is that they are international, as everybody "speaks" the same language, regardless what his native language is.
I work on another, international Open Source project (FreeDOS) and i couldn't imagine that we would make any serious progress if everyone would use his/her localized version of C,Pascal or assembler or whatever. Not to mention that there are languages which use different character sets than the standard 7bit ASCII uses for all existing language (ok, ok, except for APL and maybe some other exotic varieties..;-))). How do you think about localizing FPC into Russian or Chinese????

just my 2c,

take care,

Ralf

Could anyone explain me what's this macro feature? How would it work?

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/

APL and maybe some other exotic varieties..;-))). How do you think about localizing FPC into Russian or Chinese????

It would be relatively complex and not very useful. Complex because
1) you must make support for characters >#127 in keywords.
2) I don't know Chinese but know that this language uses instead true alphabet a more complex hieroglyphic system. In this system every symbol means not a sound or sounds sequence but a 'sense atom'. If it is true, every keyword could be replaced to 1-2 symbols! I think, it would be not Pascal more!
3) Now I sent my opinion about the expediency of keywords translating into forum (as an answer to "kind of problem in translating freepascal" in "Developing for Windows" section and therefore should not repeat all my arguments against it. If they are interesing for somebody, it can find them here. More useful for Russian programmers would be support of Russian (cyrillic) characters in user-defined variables, types etc. But this feature is also not necessary because nearly all characters of Russian Alphabet can be replaced to Latin symbols and Russian words written with these symbols are readable. For other hand, introducing support of cyrillic characters will cause some additional problems because different operating systems use different encoding tables for cyrillic characters (866 in DOS, 1251 in Windows, KOI-8 in UNIX-like systems etc).

Sincerely, Pavel

Hello,
Today Sergey Kosarevsky wrote me that he found a site (http://pixel32.box.sk) with first FPC port for BeOS. I downloaded it at http://pixel32.box.sk/fpc/fpcbeos.zip. Authors are Lukas Pokorny and Pavel Kanzelsberger. They report that this port is only fastly patched Linux version. Authors search also volunteers to continue this work:

If someone can help, please do it, everything will go faster then

Sincerely, Pavel Ozerski

Hello, Today Sergey Kosarevsky wrote me that he found a site (http://pixel32.box.sk) with first

FPC port for BeOS.

I downloaded it at http://pixel32.box.sk/fpc/fpcbeos.zip. Authors are Lukas Pokorny and

Pavel Kanzelsberger.

They report that this port is only fastly patched Linux version. Authors search also

volunteers to continue this work:

>If someone can help, please do it, everything will go faster then

I wrote already (IIRC to fpc-pascal) that the port is included in the 1.1 development version. So there is just someone necessary that has BeOS installed and will maintain the BeOS RTL.

Hello,
I see that also now FPC loses export info in win32 dlls by smartlinking. I think, this problem could be easily solved. I self can try to fix it but I need some information. The mean of my idea: currently all .edatas are localized in static library as separate object modules. When linker builds the chain of references it loses these modules. But we can link these .edatas not as a part of library but as separate object files (.ow). They also could be merged into one object file (but not into library!). I made a preliminary test: I found in temporary .olw folder created by compiler for building the static smart-link library the .ow files with export infos and simplely added them into linker script (link.res), directly into the same GROUP() which contained smart-link libraries (I think, using IMPORT() with startup file would be also correct). This test was successfull: I got correctly built DLL.
If this way seems to be good solution, please report me where I could hook building of these sw/ow files to include them into linker response file (and, desirablely, exclude from library).

Sincerely, Pavel

I wrote already (IIRC to fpc-pascal) that the port is included in the 1.1 development version. So there is just someone necessary that has BeOS installed and will maintain the BeOS RTL.

How with support of C++ classes? Without it BeOS port of FPC will be very defective because it will be not able to use big part of standard BeOS API.

>I wrote already (IIRC to fpc-pascal) that the port is included in the 1.1 development >version. So there is just someone necessary that has BeOS installed and will maintain

the

>BeOS RTL. How with support of C++ classes? Without it BeOS port of FPC will be very defective

because it will be not able

to use big part of standard BeOS API.

C++ classes are not supported.

Hello, I see that also now FPC loses export info in win32 dlls by smartlinking. I think, this

problem could be easily solved.

I self can try to fix it but I need some information. The mean of my idea: currently all .edatas are localized in static library as separate object modules. When

linker builds the chain of references

it loses these modules. But we can link these .edatas not as a part of library but as

separate object files (.ow).

They also could be merged into one object file (but not into library!). I made a preliminary test: I found in temporary .olw folder created by compiler for

building the static smart-link library the .ow

files with export infos and simplely added them into linker script (link.res), directly

into the same GROUP() which contained

smart-link libraries (I think, using IMPORT() with startup file would be also correct).

This test was successfull: I got correctly

built DLL. If this way seems to be good solution, please report me where I could hook building of

these sw/ow files to include them into

linker response file (and, desirablely, exclude from library).

That is very difficult, because normally the internal assembler is used that will create the objectfiles directly in memory to write a signle library when finished.

I guess the an easier fix is to include a reference at the end of each exported procedure to the export data for that procedure.

How does GCC solve this?

C++ classes are not supported.

I know it. Also I know that some initial steps in this direction are done (but I don't like implementation of a lot of new keywords). Does somebody investigate the internals of GNU C++ classes to try to bind them with FPC VMT?

That is very difficult, because normally the internal assembler is used that will create the objectfiles directly in memory to write a signle library when finished.

Is it really so? May be, I mistake, but I think that only .ow object files are creating by internal assembler and static library is building using arw utility. At least if I use -s option I get a folder with a set of .ow files.

At 10:35 06/06/01 , vous avez écrit:

The problem seems to be that even GNU C++ mangling mechanism is version dependant :(
Moreover, this mangling mechanism is quite complex...

And I am not even speaking about virtual and multiple inheritance that might become a nightmare to support :(

On 02-Jun-01 wrote

FreePascal International Proyect

[..]

Well, I think it would be easier for these French, Scandinavian, Russian, Spanish, German,... people to program in his/her own language.

don't you mean substitution of the reserved words by national equivalents?

well, i'll write a nice proggy in such a language (w/ ukrainian keywords) and if you'll want to see source you'll get it. but don't think that you'll understand even a letter, let alone words :)))

---
with best regards, Romio "Lucky" Pedchenko :) //