This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Translation for extension is a bad idea


I think the syntax problem is not necessarily infix vs. prefix, but rather
where the parenthesis go.  I think most people would like scheme a lot
better if they could say

lambda (expression) 
{
	display(subtract(add(2 3) 5))
}

instead of 

(lambda (expression) 
(
	(display (- (+ 2 3) 4) )
)

The problems being

a) you use the same syntactic symbol for different semantic meaning.
Although technically in scheme, this is not a real semantic difference, it
"feels" that way.  It is easier to tell what things do if common semantic
idioms are expressed with specialized symbols.  Basically, what I'm trying
to say, is that when you _always_ use parenthesis, its hard to break up a
program mentally by looking at it.  

b) There is no separation of program from the arguments.  Since they all
are in the same position with respect to the parenthesis, the procedures
seem to have the same function as the arguments.

c) special forms are a pain in the butt both to remember how to type
them, and also to know what they are doing when you look at them.

Interestingly enough, these syntactic problems are precisely what define
scheme - namely - a uniform representation of programs and data.  As
always, a program's strength is also its weakness.  

Jon

On 12 Jul 2000, Jorgen 'forcer' Schaefer wrote:

> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > * there is consensus that Scheme is scary due to prefix notation. This
> >   suggest that there should be some infix dialect of Scheme.
> 
> I think this is misunderstandable.  The arithmetic of Scheme is
> prefix, due to the fact that mathematical operators are functions
> like everything else.  That function calls are "prefix" is normal
> with most widely used languages nowadays (except where you can
> define your own infix functions, e.g. in SML or Haskell), or if
> the language is stack-oriented like Forth.
> 
> For example, in C++, you *can* also use operator+(1,1) (i'm not
> so sure about the syntax).
> 
> What you say is that it's inconvient for users to use prefix
> syntax for mathematical expressions.  The only thing required is
> a special form which handles infix syntax, or maybe even just a
> function like Tcl's expr.
> 
> That is, either something like
> (define a 3)
> [syntax] (expr (1+1) * a)
>          -> (* (+ 1 1) a)
>          => 6
> or
> [function] (expr "(1+1)*a")
>            => 6
> 
> Actually, the first is just a matter of
> 
> (define-syntax expr
>   (syntax-rules ()
>     ((_ expressions ...)
>      (expr*
>       (with-output-to-string
>         (lambda ()
> 	  (write '(expressions ...)))))))
> 
> If you have expr* as the function which evaluates a string.
> 
> expr* has to be able to get the value of variables.
> 
> It would of course be nicer if this would just be syntax that
> rewrites the expression, but that's not easy (considering that
> parsing (expr 1+1) in define-syntax isn't trivial...)
> 
> 
> The point of the multiple language reader idea in guile is that
> the program author just writes his program's interface to the
> Scheme world, and the user decides which syntax to chose for
> scripting the program at hand.
> 
> This means that the author maybe offers his own language for his
> program, but which translates to scheme, so the user can use
> Scheme (or actually, any other language which guile supports) as
> well if the author's language isn't powerful enough for him.
> 
> Thus, it's not really necessary for Guile to *completely* grok
> the language which it wants to read, but "mostly" is enough, it
> should just be that the user can use his knowledge of his FPL to
> script the application.
>         -- forcer
> 
> -- 
> ((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
>  (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]