🚀 go-pugleaf

In article <3859@iris.mincom.oz.au> marks@iris.mincom.oz.au (Mark Stavar) writes:
>IS there any specific reason why one would choose to utilise an prefix notation
>language for extensions to an editor as opposed to infix or post-fix?

Because they're so trivial to implement.  Fully prefix or postfix languages
eliminate the need for a parser.  Other areas of the language may be
difficult to implement (storeage management issues), but for an interpreted
language, the parser would be the most difficult part (assuming the person
writing the language doesn't know yacc).

>Does prefix notation provide some facilities for better performance for
>interpretive languages.

I think a postfix language is probably slightly easier to implement (and
hence easier to make fast), but prefix is slightly more natural to use.  Or
at least, somewhat more acceptable because of the prevelance of lisp.

>I am particularly interested since, as both 
>Emacs lisp and the Brief macro language were specifically written for
>their respective products, I would have thought that the options would
>have been available to utilise a more *natural* language interface.

I have a neat language which I was thinking of adding to my editor JOE.  The
language is a block-structured language like C but with no stupid punctuation. 
Here's a sample of it:

	; Type character 'ch' at 'cursor'.  Handle left margin, overtype
	; mode and word-wrap.

	void type(*P cursor,int ch)
	    if isblankline(cursor)
	        ; Cursor line is blank.  Insert spaces until we're at left
	        ; margin
	        while cursor.column<left_margin
	            insert(cursor,SPACE)
	            getc(cursor)
	    ; Insert typed character and advance cursor
	    insert(cursor,ch)
	    getc(cursor)
	    if word_wrap && cursor.column>right_margin && !iswhite(ch)
	        ; We went past right margin, wrap word to next left margin
	        ; of next line
	        wrapword(cursor,left_margin)
	    else if overtype &&
	            !iseol(cursor) &&
	            ch!=TAB
	        ; We're in overtype mode, so delete character to make it
	        ; like a typewriter
	        *P tmp	; Temporary marker
	        delete(cursor,getc(tmp=dup(cursor))) rm(tmp)

The block structuring is determined by the indentation.  Ambiguous operators
like '-' are resolved with line breaks and by checking how close the
operator is to its potential operands (think about it... this really works,
but you have to write the parser by hand).  Otherwise it's like C++ with a
simpler syntax.

Right now I'm just tinkering with a compiler for it.  Whenever I think of
adding it to JOE, I end up reasoning that it would be saner to either not
have an extension language and allow external extension programs to control
the editor through pipes, or to have some form of dynamic linking. At this
point I realize how hard it would be to make dynamic linking portable and
how difficult it is to write a portable optimizing compiler, leaving my
American minimalist-functionalist-hacker tendancies unsatisfied, and get
depressed.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
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)
+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
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}