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 2 of 2 — ← Prev page 1 [2]

#204

On Apr 8, 3:40 am, HiramEgl <hiram...@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.
...
>
> /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]

Warning:  Long, and possibly pointless post.

I have always wanted to build a parser generator tool that also builds
a syntax directed editor based on the grammar.  Presumably this would
make editing easier and the user would only need to know one editor
though the editor would behave differently for different languages
(grammars).

Of particular interest to me is that, once a text is parsed, more is
known about the structure of the text and thus, in principle, you can
use this information to construct a representation of the text that is
more compact than the original text and that is faster to process by
the compiler than processing starting from the original text.  What
the syntax directed editor would do then is deparse the parsed and
compressed text on demand for the user to edit and parse and
recompress the user's changes on the fly.  With this set up the cost
of parsing during compilation would be close to 0.  Well, parsing is
not a major cost of compiling anyway so the saving would not be that
great.

But there are other advantages.  Since the text is efficiently
compressed, presumably better than generic text compressors, the
actual source files would be smaller.  Of course with all the disk
space available this isn't all that important (when my source code
exceeds my 250GB hard drive I will let you know).  An interesting
question is: Can the syntax directed editor file in a compressed
program file and decompress it faster than a regular editor can file
in the equivalent uncompressed program file?  My expectation is that
it would. Of course, given the speed of computers today, this
performance improvement would rarely matter. In any case a smart
editor would not necessarily file in all of the source file before
displaying the part required by the user.

But there are other advantages.  After parsing, the result can also be
fed to other tools for analyzing the program.  These would also see
the same improvement as shown for compiling above.

But there are other advantages.  One interesting thing that could be
done is have the parsed version of the program be broken into three
sections (perhaps three files):

   1) The core of the program.  This section has everything except the
following sections.
   2) The comment section.  This section contains all the comments and
also all spacing text.
   3) The naming section.  This section would contain the equivalent
of the symbol table.

With this set up the program could be edited to change the comment
section and/or the naming section without requiring a recompile.  I
think this is a useful feature though I don't know how many would
agree.  In particular this would be useful when comparing two versions
of the program, one that works and one that doesn't. The user could
then ask to only see only the differences that affect the core
section.  Also, during code freezes, the developer could be allowed to
update the comment and naming sections (and thus the he/she could
delay this work until the code freeze ;-) ).

The big issue though is that the syntax directed editor would need to
be easy enough to use and productive enough that developers will
actually use it.  As John pointed out this is a major issue that
should not be underestimated.

It is also worth noting that this would be a lot of work, well unless
I do it in Smalltalk. :-)

Comments welcome.

Ralph Boland

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

#236

Ralph Boland <rpboland@gmail.com> writes:

> On Apr 8, 3:40 am, HiramEgl <hiram...@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.
> ...
>>
>> /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]
>
> Warning:  Long, and possibly pointless post.
>
> I have always wanted to build a parser generator tool that also builds
> a syntax directed editor based on the grammar.  Presumably this would
> make editing easier and the user would only need to know one editor
> though the editor would behave differently for different languages
> (grammars).


http://portal.acm.org/ft_gateway.cfm?id=358755&type=pdf
http://portal.acm.org/ft_gateway.cfm?id=954001&type=pdf
http://www.ics.uci.edu/~andre/ics228s2006/repsteitelbaum.pdf

But this was before the Internet and free software took over the world,
so nothing remains of it...  Perhaps the results weren't satisfactory.


> The big issue though is that the syntax directed editor would need to
> be easy enough to use and productive enough that developers will
> actually use it.  As John pointed out this is a major issue that
> should not be underestimated.

Indeed.  And the point here is that it is often much easier to type
linearly:

      x=a*square(x)+b*x+d;

than it would be to select the = operator, to click on the left box, to
type x, to click on the right box, to select the + operator, to click on
the left box, to select the * operator, to click on the left box, to
type a, to click on the right box, to search square in the list of
functions, to click on the argument list box, to type x, etc...


> It is also worth noting that this would be a lot of work, well unless
> I do it in Smalltalk. :-)

Or Lisp.  But it would be not much work to synthesize the structural
editor from the grammar of the language.  On the other hand, you
couldn't use the same grammar as the compiler: you would have to
annotate it to let the editor accept textual input for some
non-terminal, as shown above.


On the other hand, since it is hard to decide at what level in the
syntactic tree it is worthwhile to switch between the textual input and
the structured editing, perhaps we should let the user choose himself.

This is exactly what we get in emacs with things like paredit,
skeletons, abbrev, etc.  The user gets to choose the level of structured
editing he wants to use.

Also, have a look at:

http://groups.google.com/group/comp.lang.lisp/msg/3050088218d355e5




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

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

#240

On 4/11/11 8:21 PM, Pascal J. Bourguignon wrote:

> http://portal.acm.org/ft_gateway.cfm?id=358755&type=pdf
> http://portal.acm.org/ft_gateway.cfm?id=954001&type=pdf
> http://www.ics.uci.edu/~andre/ics228s2006/repsteitelbaum.pdf
>
> But this was before the Internet and free software took over the world,
> so nothing remains of it...  Perhaps the results weren't satisfactory.
>

Are you saying you were unable to find any copies of the Cornell Program Synthesizer?

http://www.threedee.com/jcm/terak/docs.html
Cornell Program Synthesizer manual and disk, v1.02(QB), by Prof. Tim Teitelbaum, June 1981.
[Tim started a company to commercialize it which is still in business.
See www.grammatech.com -John]

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

#221

What I'd like to see in an editor is half-spaced empty lines.  What this allows 
you do to is separate pieces of code vertically - but not too far.

For example:

def map()
   array = []

   val = self.fold do |item|
     yield item
   end

   return val
end

A little too spaced out.

def map()
   array = []
   val = self.fold do |item|
     yield item
   end
   return val
end

A little too packed together.

(Imagine half spaced empty lines)

Ahh, much better :)  I experimented with this a bit, but haven't had time to 
work on the idea lately.


Regards,
Mike

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

#226

Mike Austin <mike@mike-nospam-austin.com> writes:

> What I'd like to see in an editor is half-spaced empty lines.

in 2003 there was a thread on comp.emacs entitled "Fractional line
spacing"

if you use {,X}Emacs ask google groups the following question
         group:comp.emacs insubject:"fractional line spacing"
i found Ted Zlatanov's post particularly useful

ciao

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming

csiph-web