Re: New editor/Integrated Development Environment/compiler

HiramEgl schrieb:


> I'm specially concerned about how the source-structure is stored. I
> don't want it to be stored in a file because is not flexible. I would
> like to have the source-structure stored in some binary format
> independent of user-languages or programming-languages, ideally.


This would mean one distinct binary representation for every programming
language. Not very encouraging, when it comes to mix parts
(libraries...) from different source languages.




> With the help of some translation tables it would be possible to
> regenerate source code in a specific user-language or programming-language.
>
> For example, if the user types:
> int Result;
>
> then the editor would have the capability of understanding that the
> first word is a variable type and the second word is a variable
> identifier. It would create a binary representation:
>
> 50 9899
>
> and update a translation table:
>
> Id English
> -------------
> 50 int
> 9899 Result


Now let's this spell out in Pascal:
      Result: integer;
or in Basic
      Result%


What tables have to be created, to make such translations possible?


Or let the user enter
      apple pie;
How to interpret this?


> Afterwards, another user might update the translation table for other
> language:
>
> Id English Espaqol
> -------------------------
> 50 int entero
> 9899 Result Resultado
>
> And regenerate the source code in another language:
>
> entero Resultado;


That's futile work. Programming languages cannot be translated. An "int"
or "for" in C might be something different from an "integer" or "for" in
Pascal. Just when it comes to structures, then every language has its
own object model, mostly incompatible with objects of other languages.
Adding translations into natural languages only increases the confusion.




> All this comes from the frustration of having the structure of
> algorithms or designs trapped in a specific user-language or
> programming-language. Because, I think that a lot of knowledge is
> trapped in source code written in english. I would like to have a tool
> that would help me to reuse very easily the structure of algorithms
> and designs written in other applications.


Nice, but see above: you need a very new programming language, capable
of expressing all the subtle differences between all the source
languages. Most probably you'll end up with a general-purpose (Turing?)
machine language, with only one-way translations *into* that language,
but never back again (meaning decompilation).




> For example, I would like to drag-and-drop a quicksort algorithm into
> an application that later I could regenerate into "c" source-code in
> Spanish or ruby source-code in Swedish.


Obviously you never tried to write international applications. Every
message string must be translated as a whole, with a different insertion
order of variable parts. There is almost no chance to automate such
translations - without the risk of introducing undetectable semantic
errors. Even if the result looks nice, it may mean something very
different. You'll also find out that one word in one language can
correspond to multiple different words in another language. Given such a
polymorphic word, how should it translate into a different language?


Exercise:
English "dot", "period" and "full stop" essentially (can) mean the same.
In German that common meaning would be "Punkt". But there exists also
"Periode", that matches a different (mathematical) meaning of "period",
but it also can mean "menstruation". How to find out what's the
*correct* translation, in both directions?




> I'm interested in transporting algorithms, designs, architectures across
> user-languages, programming-languages, platforms, etc.


Then start to learn more about these issues, before running into well
known dead-ends.


E.g. try to figure out the difference between algorithms and procedures.
An algorithm can be expressed in many programming languages, and even in
a single language in multiple ways. Then it's possible to prove that a
given procedure implements another given algorithm, but you'd be the
first one to provide a perfect automatic translation between both. A not
always perfect translation is inacceptable, when it comes to exact
computation.


DoDi
[We do seem about to dive into the UNCOL Swamp of No Return, don't we? -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.