Re: About sweet-expression

[Mark H Weaver]

Nala Ginrut <address@hidden> writes:

> I try to port sweet-expression to newest Guile. Fortunately, the
> author wrote a compatible version for old Guile in 2008. So I just try
> to rewrite part of it for some obvious reasons. It woks fine now.
>
> Though some guys doesn't like sweet-expression at all (OK, they're
> real Lispers! But me too ;-)). I'm not a big fan to write Scheme like
> this:
> -----------------------
> define fibfast(n)  
>   if {n < 2}       
>     n
>     fibup(n 2 1 0)
> -----------------------
> But I think it maybe useful for newbies especially came from Python of
> C. If we can fix the problems which I'll mention later, I expect it to
> be added as inner language support.
>
> I put it here, if you're interested, please checkout here:
> git://gitorious.org/nacre/guile-sweet.git
> It supports Modern & Sugar both. You may read the README and try the
> example.
>
> But there're some problems for the original implementation, so I didn't
> format a patch. I think there should be something to be fixed.
> 1.  The author's comment shows that we don't need to re-implement a
> reader if our reader treats "[]" and "{}" as delimiter.  But seems "
> {}" is not delimiter in current Guile. Mark Weaver said it should be
> fixed. 

Yes, it would be good to at least have a reader option to treat {} as
delimiters.  I haven't looked carefully at this, but I suspect the main
requirement is to stop reading when we reach a '}', and furthermore to
unget that delimiter when we reach it.

Without this, the sweet expression reader will need to reimplement the
entire reader from scratch, which seem suboptimal for several reasons.

> 2. And the second suggestion of Mark Weaver is we *must* try the Guile
> inner reader tools and keep some information if there's errors
> happened. I think it's a more worthy consideration. The current sweet
> is too weak to be a productive thing. 

To clarify, I was talking about the need to set source properties on the
datums that are read.  However, having thought a bit more about this,
it's clear that Guile's reader can be of very little help here.

The sweet expression reader itself must be responsible for setting
source properties on all the resulting lists that are not written with
normal parentheses.  For example, in the following sweet expression:

  define fibfast(n)  
    if {n < 2}       
      n
      fibup(n 2 1 0)

Guile's reader is of no help at all with source properties.
Fortunately, Guile provides all of the interfaces you need to do this
job from Scheme: 'set-source-properties!', 'port-filename', 'port-line'
and 'port-column'.  This will have to be implemented in the sweet
expression reader.

> 3. We don't have "nfx" macro in current Guile, so only simple infix
> expression can be evaluated. Say, all the operators are homologous: 
> {1 + 2 + 3} is simple infix expression
> {1 + 2 - 3} is not.
> Anyway, it's not a big deal, I'll fix it later. But I'm not sure
> whether it should be in Guile or in app? Since the author use "nfx"
> directly, maybe it's a common thing we missed?

It seems clear to me that David Wheeler intended for 'nfx' to be defined
by the user, to implement whatever operator precedence they wish for
their particular module.  There's no universally good 'nfx' macro.

    Thanks,
      Mark