home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / editors / 3044 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.6 KB  |  81 lines
  1. Newsgroups: comp.editors
  2. Path: sparky!uunet!world!jhallen
  3. From: jhallen@world.std.com (Joseph H Allen)
  4. Subject: Re: Extension Languages
  5. Message-ID: <BzAu68.7AA@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <3859@iris.mincom.oz.au>
  8. Date: Tue, 15 Dec 1992 11:49:19 GMT
  9. Lines: 70
  10.  
  11. In article <3859@iris.mincom.oz.au> marks@iris.mincom.oz.au (Mark Stavar) writes:
  12. >IS there any specific reason why one would choose to utilise an prefix notation
  13. >language for extensions to an editor as opposed to infix or post-fix?
  14.  
  15. Because they're so trivial to implement.  Fully prefix or postfix languages
  16. eliminate the need for a parser.  Other areas of the language may be
  17. difficult to implement (storeage management issues), but for an interpreted
  18. language, the parser would be the most difficult part (assuming the person
  19. writing the language doesn't know yacc).
  20.  
  21. >Does prefix notation provide some facilities for better performance for
  22. >interpretive languages.
  23.  
  24. I think a postfix language is probably slightly easier to implement (and
  25. hence easier to make fast), but prefix is slightly more natural to use.  Or
  26. at least, somewhat more acceptable because of the prevelance of lisp.
  27.  
  28. >I am particularly interested since, as both 
  29. >Emacs lisp and the Brief macro language were specifically written for
  30. >their respective products, I would have thought that the options would
  31. >have been available to utilise a more *natural* language interface.
  32.  
  33. I have a neat language which I was thinking of adding to my editor JOE.  The
  34. language is a block-structured language like C but with no stupid punctuation. 
  35. Here's a sample of it:
  36.  
  37.     ; Type character 'ch' at 'cursor'.  Handle left margin, overtype
  38.     ; mode and word-wrap.
  39.  
  40.     void type(*P cursor,int ch)
  41.         if isblankline(cursor)
  42.             ; Cursor line is blank.  Insert spaces until we're at left
  43.             ; margin
  44.             while cursor.column<left_margin
  45.                 insert(cursor,SPACE)
  46.                 getc(cursor)
  47.         ; Insert typed character and advance cursor
  48.         insert(cursor,ch)
  49.         getc(cursor)
  50.         if word_wrap && cursor.column>right_margin && !iswhite(ch)
  51.             ; We went past right margin, wrap word to next left margin
  52.             ; of next line
  53.             wrapword(cursor,left_margin)
  54.         else if overtype &&
  55.                 !iseol(cursor) &&
  56.                 ch!=TAB
  57.             ; We're in overtype mode, so delete character to make it
  58.             ; like a typewriter
  59.             *P tmp    ; Temporary marker
  60.             delete(cursor,getc(tmp=dup(cursor))) rm(tmp)
  61.  
  62. The block structuring is determined by the indentation.  Ambiguous operators
  63. like '-' are resolved with line breaks and by checking how close the
  64. operator is to its potential operands (think about it... this really works,
  65. but you have to write the parser by hand).  Otherwise it's like C++ with a
  66. simpler syntax.
  67.  
  68. Right now I'm just tinkering with a compiler for it.  Whenever I think of
  69. adding it to JOE, I end up reasoning that it would be saner to either not
  70. have an extension language and allow external extension programs to control
  71. the editor through pipes, or to have some form of dynamic linking. At this
  72. point I realize how hard it would be to make dynamic linking portable and
  73. how difficult it is to write a portable optimizing compiler, leaving my
  74. American minimalist-functionalist-hacker tendancies unsatisfied, and get
  75. depressed.
  76. -- 
  77. /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
  78. int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
  79. +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
  80. ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
  81.