Re: New editor/Integrated Development Environment/compiler

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

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