Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #190 > unrolled thread

New editor/Integrated Development Environment/compiler

Back to article view | Back to comp.programming

Contents

  New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-08 11:40 +0200
    Re: New editor/Integrated Development Environment/compiler "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-04-08 20:40 +0200
      Re: New editor/Integrated Development Environment/compiler Willem <willem@toad.stack.nl> - 2011-04-10 19:26 +0000
        Re: New editor/Integrated Development Environment/compiler "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-04-11 18:53 +0200
          Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-12 20:31 +0200
        Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-12 00:33 +0200
      Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-12 00:17 +0200
        Re: New editor/Integrated Development Environment/compiler "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-04-12 06:00 +0200
        Re: New editor/Integrated Development Environment/compiler Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2011-04-12 13:36 +0200
          Re: New editor/Integrated Development Environment/compiler glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-04-15 21:36 +0000
    Re: New editor/Integrated Development Environment/compiler Thomas David Rivers <rivers@dignus.com> - 2011-04-08 15:11 -0400
      Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-11 22:53 +0200
    Re: New editor/Integrated Development Environment/compiler Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2011-04-08 23:39 +0200
      Re: New editor/Integrated Development Environment/compiler "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-04-10 20:53 +0200
      Re: New editor/Integrated Development Environment/compiler Patricia Shanahan <pats@acm.org> - 2011-04-10 13:30 -0700
        Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-12 00:54 +0200
    Re: New editor/Integrated Development Environment/compiler arnold@skeeve.com (Aharon Robbins) - 2011-04-10 18:46 +0000
    Re: New editor/Integrated Development Environment/compiler Patricia Shanahan <pats@acm.org> - 2011-04-10 13:33 -0700
    Re: New editor/Integrated Development Environment/compiler "ekkehard.horner" <ekkehard.horner@arcor.de> - 2011-04-11 21:14 +0200
      Re: New editor/Integrated Development Environment/compiler HiramEgl <hiramegl@hotmail.com> - 2011-04-12 00:35 +0200
    Re: New editor/Integrated Development Environment/compiler Ralph Boland <rpboland@gmail.com> - 2011-04-11 10:01 -0700
      Re: New editor/Integrated Development Environment/compiler "Pascal J. Bourguignon" <pjb@informatimago.com> - 2011-04-12 05:21 +0200
        Re: New editor/Integrated Development Environment/compiler Al Kossow <aek@bitsavers.org> - 2011-04-15 13:25 -0700
    Re: New editor/Integrated Development Environment/compiler Mike Austin <mike@mike-nospam-austin.com> - 2011-04-13 00:46 -0700
      Re: New editor/Integrated Development Environment/compiler Giacomo Boffi <giacomo.boffi@polimi.it> - 2011-04-13 18:09 +0200

Page 1 of 2  [1] 2  Next page →

#190 — New editor/Integrated Development Environment/compiler

Hi,

My name is Hiram and I would like to know if somebody is interested in
joining the development of a new kind of editor/Integrated Development
Environment/compiler.

I'm not happy with the current free (or open-source) alternatives that
I've found. I think that all those tools (Eclipse, NetBeans, QtCreator,
Emacs, Vim, ...) have in the bottom the same problem: they work with
directories, files and text.

Personally, I like Vim and I love that it has different modes (command,
insert, visual, ...). The best is that it is fast to open (compared to
the other heavy IDE:s) and that there are thousands of plugins to boost
the development. However, it also works with dirs, files and text.

But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.

And note that I say << STRUCTURE >> and not << MODEL >>. I've worked
with free tools that manage models in order to generate source code but
these models are, most of the time, limited in the level of detail of
the instructions. Those tools do not keep a clean-and-tight relation
between the model and the source code. Sometimes they just make things
messier. I've also worked with UML and have noticed that, in large and
stressing projects, is difficult to keep in sync the UML diagrams with
the source code, most of the time people cares about getting things
done, not about getting designs well-documented.

So, what's the difference between STRUCTURE and MODEL?

I don't want to get into definition problems, everybody can have their
own definition for both words. I would like to refer specially to the
TREE-STRUCTURE of the source code, that I would like to call the <<
SOURCE-STRUCTURE >>.

The source code is composed (as I mentioned previously) by directories
containing more directories and files, and files containing text.
* Going a step further:
- The text of the files is composed by a root level that contains
include/import instructions, class and struct definitions, methods
definitions, etc.
- Structs contain other structs or basic typed elements.
- Classes may include other classes, enumerations, attributes, methods, etc.
- Attributes include type and name.
- Methods include arguments and instructions, ... etc.
* Going a step backwards:
- Directories are found in computers (hosts)
- Hosts are found in networks or in other sort of clustered infrastructures.

Therefore, I see all these elements as branches and leaves of a big
tree-structure (the SOURCE-STRUCTURE).

What I want to create is a tool that works with this source-structure
and that, with the help of different rulesets, transforms the
source-structure into source-code or documentation files or webpages or
three-dimensional worlds, etc. The source-code (directories, files and
text) can then be compiled or interpreted. Going a step further, I think
it might be possible to transform the source-structure directly into
executable code, skipping the compilation/interpretation step.

Having different rulesets for the transformation might help to create
deployment rulesets, debug rulesets, obfuscated rulesets, documentation
rulesets, windows rulesets, linux rulesets, i.e., the same
source-structure can be transformed into deployment source-code or debug
source-code or obfuscated source-code or documentation files, etc.

This is nothing but an extrapolation of using XML (source) and XSL
(rules) to create HTML (product). An even more obvious analogy is: usign
c++ code (source) use gcc (rules) to obtain an executable binary
(product). I'm talking about doing the same but in a higher level: using
the source-structure (source) use some rules (rules) to obtain whatever
you need (product).

Another problem that I found in the current IDE/editors is that revision
control is an optional feature. One might use CVS, SVN, git, etc. to
keep track of changes in the code and to allow collaboration between
developers.

In the application I want to develop, revision control and collaboration
are found at the core level. I think that the current IDE/editors were
developed with old functionality principles in mind. The fact is that
complex applications require the coordinated collaboration of tenths or
hundreds of developers. Thus, the new tool has to be a
collaborative/change-tracking tool with edition features on top, and not
the opposite.

I have tough about many more features that I would like to talk about
but I don't want to make this email longer than it is. Just want to
mention that the tool I want to develop use a Presentation-Logic-Data
architecture, has a three-dimensional interface, allows easy integration
of design-patterns and has an inherent multi-language capability.

Hope you find this interesting. Many thanks for your attention,

/Hiram
[There were structure based tools back in the 1970s.  My recollection
is that they were completely unusable other than by the people who
wrote them. -John]

[toc] | [next] | [standalone]

#192

HiramEgl <hiramegl@hotmail.com> writes:
> My name is Hiram and I would like to know if somebody is interested in
> joining the development of a new kind of editor/Integrated Development
> Environment/compiler.
>
> I'm not happy with the current free (or open-source) alternatives that
> I've found. I think that all those tools (Eclipse, NetBeans, QtCreator,
> Emacs, Vim, ...) have in the bottom the same problem: they work with
> directories, files and text.
>
> Personally, I like Vim and I love that it has different modes (command,
> insert, visual, ...). The best is that it is fast to open (compared to
> the other heavy IDE:s) and that there are thousands of plugins to boost
> the development. However, it also works with dirs, files and text.
>
> But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.

Indeed.  Have a look at the InterLisp environment.

http;//larry.masinter.net/interlisp-ieee.pdf
http://www.ida.liu.se/ext/caisor/archive/1978/001/caisor-1978-001.pdf


And a simple recreation of a structure editor:
http://www.informatimago.com/develop/lisp/small-cl-pgms/sedit/index.html


Basically, while emacs integrates into a unix environment, and therefore
takes its data from text files, it's really a lisp machine, and would
love to run from an image based environment (like most Smalltalk
environments).

Actually, implementing an emacs mode that would be strictly structure
editor like the above sedit example, would be rather easy.  But not
strictly necessary: the ability to fall down to the character level is
nice.  In any case, you have to edit a lot of random text, either
documentation strings, or if only identifiers.

When you consider things like paredit-mode we already have structural
editing in emacs.


So what's missing?  The filing part.  One thing you can do to ensure a
clear break of mindset is to store the code into a data base instead of
text files.   For a start, you could store it in a postgres database.
There's a pg.el on the web, which let you communicate directly to
postgres.  You may store each definition in a different row.

Then, instead of editing whole files at one, load in each buffer only a
single definition, and implement the navigation commands you need to
easily browse the code and skip from one function to another.  (Again,
most of all of this is already implemented in emacs).


--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[toc] | [prev] | [next] | [standalone]

#198

Pascal J. Bourguignon wrote:
) So what's missing?  The filing part.  One thing you can do to ensure a
) clear break of mindset is to store the code into a data base instead of
) text files.   For a start, you could store it in a postgres database.
) There's a pg.el on the web, which let you communicate directly to
) postgres.  You may store each definition in a different row.

NOOOO!  Not Uniface again!  I can tell you from experience that storing
code into a database instead of text files is absolutely horrible.

Of course, it looks great at the beginning when you're whipping up code
and you don't need to worry about file structure or whatever, but when it
grows bigger you're left with a horrible mess in a proprietary format.

And then you want to put the whole thing into some kind of version control
system, preferrably with multiple staging areas and whatnot, and then
you're *really* in trouble.


Here's a break of mindset for you: A filesystem is a database, but with the
added advantages that it's atransparent, and there are loads and loads of
existing tools that integrate with it, including version control, backup,
to name but a few.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#203

Willem <willem@toad.stack.nl> writes:

> Pascal J. Bourguignon wrote:
> ) So what's missing?  The filing part.  One thing you can do to ensure a
> ) clear break of mindset is to store the code into a data base instead of
> ) text files.   For a start, you could store it in a postgres database.
> ) There's a pg.el on the web, which let you communicate directly to
> ) postgres.  You may store each definition in a different row.
>
> NOOOO!  Not Uniface again!  I can tell you from experience that storing
> code into a database instead of text files is absolutely horrible.
>
> Of course, it looks great at the beginning when you're whipping up code
> and you don't need to worry about file structure or whatever, but when it
> grows bigger you're left with a horrible mess in a proprietary format.
>
> And then you want to put the whole thing into some kind of version control
> system, preferrably with multiple staging areas and whatnot, and then
> you're *really* in trouble.


> Here's a break of mindset for you: A filesystem is a database, but with the
> added advantages that it's atransparent, and there are loads and loads of
> existing tools that integrate with it, including version control, backup,
> to name but a few.

Yes.  But that's the point in this thread, we want to get rid of the
existing tools.  Remember, the key words were: IDE, and code
structure.

Of course, we know that unix is the ultimate Integrated Development
Environment.  But some people don't like unix (there are arguments,
see one below), and want something even more "integrated", ie. in a
single application.  Never mind that applications or systems are all
the same: they're virtual machines.

So the question is that we want a non-unix virtual machine, in which
it may be easier to provide integrated tools of higher quality than
unix.  One way to do this, is to provide an image based environment,
where there is no separation of addressing spaces (nowadays, with
64-bit processors, and with controlled environment programming
languages, there's no technical reason to keep separate addressing
spaces), and therefore where the tools can better integrate.  This is
what you observe in emacs, Lisp Machines and Smalltalk.

The single critisism of unix I'll mention here is that (due to the
separation of addressing spaces), it favors communication between
processes based on serialized text streams.  Hence tools such as vi,
which deal with lines of characters, instead of syntaxic editors,
working on the syntactical structure of the code.

On the contrary, when you have all your objects in the same addressing
space, you can easily "edit", ie. modify directly those objects
(ie. the syntactic tree of a program, there's no need to "edit" lines
of characters), and the compilers can use directly the modified
syntactic tree to compile the modified function.

There's no need for files, each function or method can be compiled
separately.  This helps greatly while developing because instead of
having a edit-save-compile-debug-loop, you can use a
read-eval-print-loop, with feedback at a much finer grain.


So you don't need files to store code.  No programming language use this
notion of file.  Either they have notions such as units (Pascal),
modules (Modula-2), packages (Ada), or just a full stream of characters
making up a compilation unit (C, C++).

You may want to structure your code at a higher level than the syntactic
elements provided by the language, but this can be done easily with
simple tools, eg. the method categories in Smalltalk.  Notably, it means
that you can organize your code dynamically, having different views,
different classifications than the rigid sequence of a file.


As for versionning, of course, databases don't prevent it.  On the
contrary, it's easy to add a column "version", to store several versions
of a function in a database.

But again, as I mentioned above, this means you won't use git (or not
the git as it is, which uses the unix files as units of versionning),
but a better versionning system, well integrated to your system.

As for the proprietary format, I entirely agree.  We want to be able to
exchange our programs, possibly on different systems.  That's why there
are features such as the fileOut: and fileIn: methods in Smalltalk (and
equivalent in InterLisp, see the reference provided), to serialize or
deserialize the code into ASCII for interchange.



So remember, we're not in the context of the unix IDE, with tools such
as vim, gcc, git and tag, but in the context of a different system, with
a different granularity of integration, and where the tools can work
directly with the data objects that represent the programs, instead of
having to serialize/deserialize constantly meaningless ASCII streams.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.
[One big address space with a database?  Sounds like we're on our way
to reinventing the IBM S/38. -John]

[toc] | [prev] | [next] | [standalone]

#239

> Of course, we know that unix is the ultimate Integrated Development
> Environment.  But some people don't like unix (there are arguments,
> see one below), and want something even more "integrated", ie. in a
> single application.  Never mind that applications or systems are all
> the same: they're virtual machines.
>
Totally agreed!

> There's no need for files, each function or method can be compiled
> separately.  This helps greatly while developing because instead of
> having a edit-save-compile-debug-loop, you can use a
> read-eval-print-loop, with feedback at a much finer grain.

This is exactly one of the advantages of working with the structure,
Isn't it a waste of resources the possibility to write a program with
wrong syntax? Shouldn't be much easier to validate and restrict the
typed text as the user types, and even restructure the binary product
immediately? No need of compilation stage, that's pure waste of time and
resources, from my point of view.

> As for the proprietary format, I entirely agree.  We want to be able to
> exchange our programs, possibly on different systems.  That's why there
> are features such as the fileOut: and fileIn: methods in Smalltalk (and
> equivalent in InterLisp, see the reference provided), to serialize or
> deserialize the code into ASCII for interchange.
I think that it should be possible to create a standard-representation
of symbols, like an international table, similar to ascii.

> So remember, we're not in the context of the unix IDE, with tools such
> as vim, gcc, git and tag, but in the context of a different system, with
> a different granularity of integration, and where the tools can work
> directly with the data objects that represent the programs, instead of
> having to serialize/deserialize constantly meaningless ASCII streams.
Yep, absolutely.

[I think I'll bring this thread to a close now. Structure editors are
not new -- there were lots of them in the 1970s and 1980s, and they
all died for reasons unrelated to lack of broadband connections.  You
can find many papers written on them (not neccessarily all available
for free online), and I really think anyone planning to go down that
road should start by learning about all the sinkholes that smart
people ran into before. -John]

[toc] | [prev] | [next] | [standalone]

#207

Hi Willem,

> Pascal J. Bourguignon wrote:
> ) So what's missing?  The filing part.  One thing you can do to ensure a
> ) clear break of mindset is to store the code into a data base instead of
> ) text files.   For a start, you could store it in a postgres database.
> ) There's a pg.el on the web, which let you communicate directly to
> ) postgres.  You may store each definition in a different row.
>
> NOOOO!  Not Uniface again!  I can tell you from experience that storing
> code into a database instead of text files is absolutely horrible.
>
> Of course, it looks great at the beginning when you're whipping up code
> and you don't need to worry about file structure or whatever, but when it
> grows bigger you're left with a horrible mess in a proprietary format.

I'm not familiar with the Uniface system, but it would be interesting
to know some specific problems that you experienced. Was structure
navigation an issue? Or the rulesets to generate the source code? Or
some collaboration conflicts?

> And then you want to put the whole thing into some kind of version control
> system, preferrably with multiple staging areas and whatnot, and then
> you're *really* in trouble.

That's what I think the new editor should have collaboration and
revision control at its core level, with edition features on top. My
experience is that communication and collaboration are the biggest
problems in big projects.

> Here's a break of mindset for you: A filesystem is a database, but with the
> added advantages that it's atransparent, and there are loads and loads of
> existing tools that integrate with it, including version control, backup,
> to name but a few.

The fact that the filesystem is a well-stablished development-system
doesn't make me feel less frustrated about the problems that I find when
I develop my applications in it ;). I have to endure it.

[toc] | [prev] | [next] | [standalone]

#206

Hi Pascal,

>> But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.
>
> Indeed.  Have a look at the InterLisp environment.
>
> http;//larry.masinter.net/interlisp-ieee.pdf
> http://www.ida.liu.se/ext/caisor/archive/1978/001/caisor-1978-001.pdf

Thanks for the link to the paper, certainly this "tree-structure" idea
is older than me! I think it was very incorrect to say "a new kind of
editor" since there seem to be old (and/or commercial) solutions using
this "structured" approach. Now I'm only worried about the fate of
this kind of tools, since they didn't seem to become very popular
after all these years. What were/are the problems? That would be very
interesting to find out.

> And a simple recreation of a structure editor:
> http://www.informatimago.com/develop/lisp/small-cl-pgms/sedit/index.html
>
> Basically, while emacs integrates into a unix environment, and therefore
> takes its data from text files, it's really a lisp machine, and would
> love to run from an image based environment (like most Smalltalk
> environments).
>
> Actually, implementing an emacs mode that would be strictly structure
> editor like the above sedit example, would be rather easy.  But not
> strictly necessary: the ability to fall down to the character level is
> nice.  In any case, you have to edit a lot of random text, either
> documentation strings, or if only identifiers.
>
> When you consider things like paredit-mode we already have structural
> editing in emacs.

Yep, this paredit-mode of emacs seems to help developing structural
editing and it seems to be a good start for exploring the addition of
more advanced features.

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.

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

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;

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.

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.

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

> So what's missing?  The filing part.  One thing you can do to ensure a
> clear break of mindset is to store the code into a data base instead of
> text files.   For a start, you could store it in a postgres database.
> There's a pg.el on the web, which let you communicate directly to
> postgres.  You may store each definition in a different row.
>
> Then, instead of editing whole files at one, load in each buffer only a
> single definition, and implement the navigation commands you need to
> easily browse the code and skip from one function to another.  (Again,
> most of all of this is already implemented in emacs).

I have also thought about using a relational database to manage the data
layer, but later I though that it might be more efficient to use a
specialized database that manages branches, leaves and translation
tables. Oh, yeah, and keeps all these elements in some inherent revision
control system.

Thanks for your reply!

/Hiram

[toc] | [prev] | [next] | [standalone]

#237

HiramEgl <hiramegl@hotmail.com> writes:

> 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.

It might be liberating to think only about objects (as in OO).  We may
still have to use file to implement persistency of these objects (as
mentionned in another answer, file systems are a kind of database that
has its advantages too), but you can ignore it for now, since it should
be considered an implementation detail.  (Objects could as well be stored
in a OO database, or mapped to a relationnal database.  Another quite
interesting option, but unfortunately totally theoric for now, would be
to have a persistent system such as EROS http://www.eros-os.org/ ; but
this is what you have in a first approximation when you have an image
based environment such as lisp or Smalltalk, the only difference with
EROS, is that in Lisp or Smalltalk, you have to remember saving the
image yourself, while in EROS it's done automatically).



> 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
>
> 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;

There exist already a binary format to serialize and deserialize
syntactic trees.

Each node of the syntactic tree is serialized as follow (all bytes given
in decimal):

   node ::= 40 <node-label> { 20 <child> } 41 .

   node-label ::= <identifier>

identifier  is a sequence of non-space characters encoded in ASCII (most
special characters are also allowed, apart a few exception).

  child ::= <integer> | <floating-point> | <string> | <identifier>  | <node> .

integer is a sequence of digits encoded in ASCII possibly preceeded by a
sign.

floating-point is likewise.

    string ::= 34 <characters-but-double-quote> 34


So for example:

  40 73 70 32 40 61 32 65 32 50 41 32 40 80 82 73 78 84 32 34 101 113
  117 97 108 34 41 32 40 68 69 67 70 32 65 41 41

represents the syntactic tree:

                      if
                  /   |   \
               /      |      \
               =     print   decf
             /  \     |        |
            a    2  "equal"    a

Of course, when you translate this tree to text, you can generate:


     SI a=2 ALORS AFFICHE "equal" SINON DECREMENTE a

or:

     if a=2 then begin write("equal"); end else dec(a);

or:
     if(a==2){printf("equal")}else{a--}

depending on the preferences of the programmer.



(An unsophisticated programmer (what is usually and depreciatedly called
a "real programmer") would edit the binary directly, which would give,
with an ASCII editor:

    (if (= a 2) (print "equal") (decf a))


[perhaps with the help of paredit thought ;-)])



> 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.

But apart from some popular languages who aren't really different at the
semantic level (eg Pascal and C share mostly the same semantics), in
most cases the semantic differences are the real problem.

    Let's take a simple example:

      (defun fact (x)
         (if (= 1 x)
             1
             (* x (fact (- x 1)))))

      int fact(int x){
         return (1==x)
            ? 1
            : x*fact(x-1);}

    fact(17) in C will return -288522240, while
    (fact 17) in lisp will return 355687428096000.

And we're not even speaking of object systems, type systems, exception
handling, etc.


If the purpose is to reuse algorithms written  in specific languages, it
means 90% of the time, C or C++, and  unfortunately since those are very
low level programming languages, the implementation of the algorithms in
these languages is mirred by implementation details entirely irrelevant
to the algorithms.  Filtering out those details is not easy.


In practice, you can reuse algorithm written in language X from language
Y, by using what is called a FFI, a Foreign Function Interface.


When the languages X and Y share some "common language", such as the way
the manage memory, the representation of values of various types, etc,
it's easy enough.  We can call C functions from a Pascal program, and
vice-versa.  We may also call Fortran functions from C programs, but
even this is already more delicate.  We can also do something even more
complex, crossing borders of quite different environments, such as
controlled environments (Smalltalk, Python, Lisp, etc) and uncontrolled
environments such as C, but the cost becomes higher, since each FFI
function call involves some value conversion.

And to revert to the example above, using a library such as libecl
(http://ecls.sourceforge.net), you could call from C the function fact
written and compiled in Lisp, and get the correct result 355687428096000
in your C program.  But since this is not a value that can be handled by
any native C type, you cannot use it easily, you cannot pass it to
printf, basically, you cannot do anything with it in C,  you have to
call library functions in libecl to deal with it.  So even for a simple
arithmetic algorithms, the languages are so different that you cannot
really cross the border, you may just play puppets across the FFI.


And if you want more fun, try to write a subclass of a C++ class in
Smalltalk or vice-versa.


> 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.
>
> I'm interested in transporting algorithms, designs, architectures across
> user-languages, programming-languages, platforms, etc.

IMO, the only way to do it is to hire programmers, or to implement
Strong AI, and once you have Strong AI, you don't need to translate
programs anymore (the AI does it itself).

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[toc] | [prev] | [next] | [standalone]

#238

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]

[toc] | [prev] | [next] | [standalone]

#247

In comp.compilers Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

(snip)
> 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.

Java has the Serializable interface, such that a class that implements
it can have its Object converted to a byte stream, sent somewhere else,
and then converted back into the Object again.

Otherwise, there is XDR which is meant to be used when moving data
between different internal representations.  (It will, for example,
convert floating point formats between otherwise incompatible systems.)

-- glen

[toc] | [prev] | [next] | [standalone]

#193

HiramEgl wrote:

>My name is Hiram and I would like to know if somebody is interested in
>joining the development of a new kind of editor/Integrated Development
>Environment/compiler.
   ...

>But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.

This sounds a lot like the "folding editors" of yore.

See http://en.wikipedia.org/wiki/Folding_editor

Here's an example of one:  http://www.moria.de/~michael/fe/
in case that is along the lines of your investigation.

  - Dave Rivers -

--
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

[toc] | [prev] | [next] | [standalone]

#205

On 2011-04-08 21:11, Thomas David Rivers wrote:
> HiramEgl wrote:
>
>> My name is Hiram and I would like to know if somebody is interested in
>> joining the development of a new kind of editor/Integrated Development
>> Environment/compiler.
>     ...
>
>> But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.
>
> This sounds a lot like the "folding editors" of yore.
>
> See http://en.wikipedia.org/wiki/Folding_editor
>
> Here's an example of one:  http://www.moria.de/~michael/fe/
> in case that is along the lines of your investigation.

Hi Dave,

Yes, like a folding editor or, maybe more exactly, a drill-down
visual-modeling tool, like simulink or LabVIEW. The thing is that
there might be commercial solutions but not free or open-source
solutions, not with the characteristics i'm looking for. Therefore, I
would like to develop one.

Thanks for your attention!

/Hiram

[toc] | [prev] | [next] | [standalone]

#194

HiramEgl schrieb:

> Therefore, I see all these elements as branches and leaves of a big
> tree-structure (the SOURCE-STRUCTURE).

Where do you want to start and stop building that tree?

To start you need kind of a project, that contains a number of source
modules, which then refer to other modules or interfaces, depending on
the source language; C uses #include for importing external
declarations, Pascal dialects have "uses" for the same purpose. How
shall your editor find the related files? In the case of C, where
shall your editor find the definitions, related to the imported
declarations?  At least you'll need according parsers, for every
supported language and compiler.

Do you want to recurse down into every additional external
declaration, including all libraries used in the project? In the case
of Free Pascal this requires to add not only a compiler attribute and
related search pathes to the configuration, but also for the target
machine, OS and (Lazarus) widgetset.

Your approach looks nice, as soon as such a structure tree exists, but I
see the biggest problems just in the construction of that tree.

DoDi

[toc] | [prev] | [next] | [standalone]

#197

Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:

> HiramEgl schrieb:
>
>> Therefore, I see all these elements as branches and leaves of a big
>> tree-structure (the SOURCE-STRUCTURE).
>
> Where do you want to start and stop building that tree?
>
> To start you need kind of a project, that contains a number of source
> modules, which then refer to other modules or interfaces, depending on
> the source language; C uses #include for importing external
> declarations, Pascal dialects have "uses" for the same purpose. How
> shall your editor find the related files? In the case of C, where
> shall your editor find the definitions, related to the imported
> declarations?  At least you'll need according parsers, for every
> supported language and compiler.
>
> Do you want to recurse down into every additional external
> declaration, including all libraries used in the project? In the case
> of Free Pascal this requires to add not only a compiler attribute and
> related search pathes to the configuration, but also for the target
> machine, OS and (Lazarus) widgetset.
>
> Your approach looks nice, as soon as such a structure tree exists, but I
> see the biggest problems just in the construction of that tree.

Indeed, it's much easier to do it when your environment is really
Integrated, that is, Image based, like Smalltalk systems or Lisp Machines.

But it's not impossible with thicker external components.  After all,
even on a Lisp Machine or in a Smalltalk environment, the hardware is
not included in the environment.  And it could be argued that having
access to the kernel (being able to see its sources, its state, and
being able to modify it while it's running), while fine when developing
this kernel, would not be too wise for an application programmmer.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[toc] | [prev] | [next] | [standalone]

#199

On 4/8/2011 2:39 PM, Hans-Peter Diettrich wrote:
> HiramEgl schrieb:
>
>> Therefore, I see all these elements as branches and leaves of a big
>> tree-structure (the SOURCE-STRUCTURE).
>
> Where do you want to start and stop building that tree?
>
> To start you need kind of a project, that contains a number of source
> modules, which then refer to other modules or interfaces, depending on
> the source language; C uses #include for importing external
> declarations, Pascal dialects have "uses" for the same purpose. How
> shall your editor find the related files? In the case of C, where
> shall your editor find the definitions, related to the imported
> declarations?  At least you'll need according parsers, for every
> supported language and compiler.
>
> Do you want to recurse down into every additional external
> declaration, including all libraries used in the project? In the case
> of Free Pascal this requires to add not only a compiler attribute and
> related search pathes to the configuration, but also for the target
> machine, OS and (Lazarus) widgetset.
>
> Your approach looks nice, as soon as such a structure tree exists, but I
> see the biggest problems just in the construction of that tree.

I think the import issue is important, but so is export.

I would not start using such a system without being certain I could
recover the file view of my code any time I needed it. Moreover, a
programmer might want to combine the IDE with file orientated tools such
as an existing revision control system.

The IDE would need smooth, reliable, efficient import and export to
stand any chance of widespread adoption.

Patricia

[toc] | [prev] | [next] | [standalone]

#208

Hi Patricia,

> I think the import issue is important, but so is export.
>
> I would not start using such a system without being certain I could
> recover the file view of my code any time I needed it. Moreover, a
> programmer might want to combine the IDE with file orientated tools such
> as an existing revision control system.
>
> The IDE would need smooth, reliable, efficient import and export to
> stand any chance of widespread adoption.

I agree, export should be easy to achieve, specially considering that
the source-structure might be dumped into different products.

The creation of rulesets and a smooth ruleset management system seems to
be quite a challenge, therefore, I would like to have some help with
ideas and collaboration, which doesn't seem to be an easy job :)

Thanks again for your reply!

/Hiram

[toc] | [prev] | [next] | [standalone]

#195

This sounds related to D.E. Knuth's literate programming. An
interesting "IDE" along these lines is Leo,
http://webpages.charter.net/edreamleo/front.html.

Arnold

 HiramEgl  <hiramegl@hotmail.com> wrote:
>My name is Hiram and I would like to know if somebody is interested in
>joining the development of a new kind of editor/Integrated Development
>Environment/compiler. ...

[toc] | [prev] | [next] | [standalone]

#200

On 4/8/2011 2:40 AM, HiramEgl wrote:
....
> Therefore, I see all these elements as branches and leaves of a big
> tree-structure (the SOURCE-STRUCTURE).
....

The directory-file view of code forces giving special weight to one of
the numerous hierarchies of code. Are you sure you should keep that bias
in your editor? Some O-O language refactoring tasks, for example, are
really operations on the type inheritance hierarchy.

Patricia

[toc] | [prev] | [next] | [standalone]

#201

HiramEgl schrieb:
> Hi,
>
> My name is Hiram and I would like to know if somebody is interested in
> joining the development of a new kind of editor/Integrated Development
> Environment/compiler.
>
[ Lots of interesting ideas ... ]

As the topics "code in database" and "version control" and the problem 
of "getting it in and out" were mentioned, I'd like to point to:

    http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

(I'm aware this covers only one aspect of the project)

[toc] | [prev] | [next] | [standalone]

#202

Hi Ekkehard,

On 2011-04-11 21:14, ekkehard.horner wrote:
> HiramEgl schrieb:
>> Hi,
>>
>> My name is Hiram and I would like to know if somebody is interested in
>> joining the development of a new kind of editor/Integrated Development
>> Environment/compiler.
>>
> [ Lots of interesting ideas ... ]
>
> As the topics "code in database" and "version control" and the problem
> of "getting it in and out" were mentioned, I'd like to point to:
>
> http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
>
> (I'm aware this covers only one aspect of the project)

Thanks for the link, I think this looks very interesting, specially for 
the current projects I develop.

Best regards,

/Hiram

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web