About sweet-expression

About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

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.
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.
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?

[-- Attachment #2: Type: text/html, Size: 2779 bytes --]

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 58 bytes --]

sorry for stupid typo:
s/Python of C/Python or C

Regards

[-- Attachment #2: Type: text/html, Size: 92 bytes --]

Re: About sweet-expression

[Mark H Weaver]

Nala Ginrut <nalaginrut@gmail.com> 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

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <mhw@netris.org> wrote:
> 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.

So, is there any standard for Guile what error messages should I provide?
Are port-filename ,port-line ,port-column three enough?
And how about the format should I throw with them?
What about this:
------------------------------cut-------------------------------------------
(error "invalid syntax!" port-filename port-line port-column)
------------------------------end------------------------------------------

Regards.

[-- Attachment #2: Type: text/html, Size: 1427 bytes --]

Re: About sweet-expression

[Mark H Weaver]

Nala Ginrut <nalaginrut@gmail.com> writes:

> On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <mhw@netris.org> wrote:
>> Guile's reader is of no help at all with source properties.

To clarify, the above quotation was taken out of context.  I was only
talking about one particular example, not making a general statement.

>> 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.
>
> So, is there any standard for Guile what error messages should I
> provide?

Yes, the format of error messages should be:

  <FILENAME>:<LINE>:<COLUMN>: <MESSAGE>

You must take into account the fact the the filename might be #f, in
which case you should print "#<unknown port>" instead.  Also, the
printed line number should be 1+ the line number returned by
'port-line', and _maybe_ the same should be done with the column number,
I'm not sure.  Internally, the first line is line 0, but for most people
expect that to be printed as 1.

See 'scm_i_input_error' in read.c or 'syntax-error-printer' in
boot-9.scm for examples.

> And how about the format should I throw with them?
> What about this:
> ------------------------------cut--------------------------------------
> (error "invalid syntax!" port-filename port-line port-column)
> ------------------------------end--------------------------------------

'port-filename', 'port-line', and 'port-column' are procedures that must
be applied to a port.  See the manual for details.

However, these remarks concern only error messages generated by your
sweet expression reader itself.  Your other responsibility is to add
source properties to every datum that you read, so that if an error is
detected later in compilation, the resulting error message will include
the filename, line number, and column number.

If you are able to use Guile's internal 'read' procedure, then you may
rely on it to apply the source properties for anything that it reads.
However, you will still need to use 'set-source-properties!' on anything
that isn't taken care of by the internal 'read', such as lists that are
written in a non-standard way.

   Regards,
     Mark

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

Thanks Mark! And another question:
I think there isn't an easy way to use Guile inner reader directly.
In simpler case, we can read the exp with it, say:
{2 * 3 - 6}
We may use inner reader to read the exp within {} or [] or ()
But the nested exp is not so easy:
{2 * {3 - 6}}
This CFG is easy to handle with calling modern-reader recursively. If not,
the original modern-reader should be rewritten to use Guile inner reader.
And the modern-reader must prognosis whether there's nested exp within. In
this way, Guile inner reader works when there's simple exp left only. Most
of the nested exp will be handled by modern-reader itself.
So I think it maybe not worthy to use Guile inner reader instead. What do
you think?

Regards.

On Tue, Mar 13, 2012 at 3:05 AM, Mark H Weaver <mhw@netris.org> wrote:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <mhw@netris.org> wrote:
> >> Guile's reader is of no help at all with source properties.
>
> To clarify, the above quotation was taken out of context.  I was only
> talking about one particular example, not making a general statement.
>
> >> 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.
> >
> > So, is there any standard for Guile what error messages should I
> > provide?
>
> Yes, the format of error messages should be:
>
>  <FILENAME>:<LINE>:<COLUMN>: <MESSAGE>
>
> You must take into account the fact the the filename might be #f, in
> which case you should print "#<unknown port>" instead.  Also, the
> printed line number should be 1+ the line number returned by
> 'port-line', and _maybe_ the same should be done with the column number,
> I'm not sure.  Internally, the first line is line 0, but for most people
> expect that to be printed as 1.
>
> See 'scm_i_input_error' in read.c or 'syntax-error-printer' in
> boot-9.scm for examples.
>
> > And how about the format should I throw with them?
> > What about this:
> > ------------------------------cut--------------------------------------
> > (error "invalid syntax!" port-filename port-line port-column)
> > ------------------------------end--------------------------------------
>
> 'port-filename', 'port-line', and 'port-column' are procedures that must
> be applied to a port.  See the manual for details.
>
> However, these remarks concern only error messages generated by your
> sweet expression reader itself.  Your other responsibility is to add
> source properties to every datum that you read, so that if an error is
> detected later in compilation, the resulting error message will include
> the filename, line number, and column number.
>
> If you are able to use Guile's internal 'read' procedure, then you may
> rely on it to apply the source properties for anything that it reads.
> However, you will still need to use 'set-source-properties!' on anything
> that isn't taken care of by the internal 'read', such as lists that are
> written in a non-standard way.
>
>   Regards,
>     Mark
>

[-- Attachment #2: Type: text/html, Size: 4131 bytes --]

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

I've noticed the mistake of my last mail.
If we make curly-braces a delimiter, it's easier to read infix exp.
And I think we may add an new option to read-options for curly-braces since
there *is* an option for square-brackets.
Considering such a patch for curly-braces could be delay applied. I think
it's better to not touch modern-reader now. I'll look forward to patching
curly-braces as delimiter first.

On Tue, Mar 13, 2012 at 10:01 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:

> Thanks Mark! And another question:
> I think there isn't an easy way to use Guile inner reader directly.
> In simpler case, we can read the exp with it, say:
> {2 * 3 - 6}
> We may use inner reader to read the exp within {} or [] or ()
> But the nested exp is not so easy:
> {2 * {3 - 6}}
> This CFG is easy to handle with calling modern-reader recursively. If not,
> the original modern-reader should be rewritten to use Guile inner reader.
> And the modern-reader must prognosis whether there's nested exp within. In
> this way, Guile inner reader works when there's simple exp left only. Most
> of the nested exp will be handled by modern-reader itself.
> So I think it maybe not worthy to use Guile inner reader instead. What do
> you think?
>
> Regards.
>
> On Tue, Mar 13, 2012 at 3:05 AM, Mark H Weaver <mhw@netris.org> wrote:
>
>> Nala Ginrut <nalaginrut@gmail.com> writes:
>>
>> > On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <mhw@netris.org> wrote:
>> >> Guile's reader is of no help at all with source properties.
>>
>> To clarify, the above quotation was taken out of context.  I was only
>> talking about one particular example, not making a general statement.
>>
>> >> 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.
>> >
>> > So, is there any standard for Guile what error messages should I
>> > provide?
>>
>> Yes, the format of error messages should be:
>>
>>  <FILENAME>:<LINE>:<COLUMN>: <MESSAGE>
>>
>> You must take into account the fact the the filename might be #f, in
>> which case you should print "#<unknown port>" instead.  Also, the
>> printed line number should be 1+ the line number returned by
>> 'port-line', and _maybe_ the same should be done with the column number,
>> I'm not sure.  Internally, the first line is line 0, but for most people
>> expect that to be printed as 1.
>>
>> See 'scm_i_input_error' in read.c or 'syntax-error-printer' in
>> boot-9.scm for examples.
>>
>> > And how about the format should I throw with them?
>> > What about this:
>> > ------------------------------cut--------------------------------------
>> > (error "invalid syntax!" port-filename port-line port-column)
>> > ------------------------------end--------------------------------------
>>
>> 'port-filename', 'port-line', and 'port-column' are procedures that must
>> be applied to a port.  See the manual for details.
>>
>> However, these remarks concern only error messages generated by your
>> sweet expression reader itself.  Your other responsibility is to add
>> source properties to every datum that you read, so that if an error is
>> detected later in compilation, the resulting error message will include
>> the filename, line number, and column number.
>>
>> If you are able to use Guile's internal 'read' procedure, then you may
>> rely on it to apply the source properties for anything that it reads.
>> However, you will still need to use 'set-source-properties!' on anything
>> that isn't taken care of by the internal 'read', such as lists that are
>> written in a non-standard way.
>>
>>   Regards,
>>     Mark
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4966 bytes --]

Re: About sweet-expression

[Nala Ginrut]

Sorry for very slowly updating. Because I have lot of interesting
ideas to try. ;-)
Now I added "syntax-error" which could catch the error token location
and throw more details.
For a instance:
------------------------------------cut-------------------------------
sweet@(guile-user)> #c
While reading expression:
ERROR: Syntax error:
unknown file:2:2: Invalid #-prefixed string in form #\c
-------------------------------------end-----------------------------

But there're also BAD news, and I believe they are the
bugs/immature-things in the original code:
1.  Special chars can't be read. The curious point is the char will be
treated as a string.
And the string reader is Guile's "read". But the code do handle the
special chars.
--------------------cut--------------------
sweet@(guile-user)> #\space
While reading expression:
ERROR: In procedure string: Wrong type argument in position 1: (#\s . "pace")
--------------------end-------------------

2. I can't trace in Sweet mode. Maybe I missed something:
--------------------cut--------------------
sweet@(guile-user)> ,trace {1+1}
Throw to key `wrong-type-arg' while reading argument `form' of command `trace':
ERROR: In procedure car: Wrong type argument in position 1 (expecting pair): ()
--------------------end-------------------

3. Original code didn't handle the errors properly:
--------------------cut--------------------
sweet@(guile-user)> {1*  1}
While reading expression:
ERROR: In procedure car: Wrong type argument in position 1 (expecting pair): ()
-------------------end--------------------
In this case, I think it should throw:
ERROR: In procedure module-lookup: Unbound variable: #{1*}#

Well, I think if we use Guile's inner reader instead of my reader,
these problems maybe gone?

On Tue, Mar 13, 2012 at 11:51 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:
> I've noticed the mistake of my last mail.
> If we make curly-braces a delimiter, it's easier to read infix exp.
> And I think we may add an new option to read-options for curly-braces since
> there *is* an option for square-brackets.
> Considering such a patch for curly-braces could be delay applied. I think
> it's better to not touch modern-reader now. I'll look forward to patching
> curly-braces as delimiter first.
>
> On Tue, Mar 13, 2012 at 10:01 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:
>>
>> Thanks Mark! And another question:
>> I think there isn't an easy way to use Guile inner reader directly.
>> In simpler case, we can read the exp with it, say:
>> {2 * 3 - 6}
>> We may use inner reader to read the exp within {} or [] or ()
>> But the nested exp is not so easy:
>> {2 * {3 - 6}}
>> This CFG is easy to handle with calling modern-reader recursively. If not,
>> the original modern-reader should be rewritten to use Guile inner reader.
>> And the modern-reader must prognosis whether there's nested exp within. In
>> this way, Guile inner reader works when there's simple exp left only. Most
>> of the nested exp will be handled by modern-reader itself.
>> So I think it maybe not worthy to use Guile inner reader instead. What do
>> you think?
>>
>> Regards.
>>
>> On Tue, Mar 13, 2012 at 3:05 AM, Mark H Weaver <mhw@netris.org> wrote:
>>>
>>> Nala Ginrut <nalaginrut@gmail.com> writes:
>>>
>>> > On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <mhw@netris.org> wrote:
>>> >> Guile's reader is of no help at all with source properties.
>>>
>>> To clarify, the above quotation was taken out of context.  I was only
>>> talking about one particular example, not making a general statement.
>>>
>>> >> 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.
>>> >
>>> > So, is there any standard for Guile what error messages should I
>>> > provide?
>>>
>>> Yes, the format of error messages should be:
>>>
>>>  <FILENAME>:<LINE>:<COLUMN>: <MESSAGE>
>>>
>>> You must take into account the fact the the filename might be #f, in
>>> which case you should print "#<unknown port>" instead.  Also, the
>>> printed line number should be 1+ the line number returned by
>>> 'port-line', and _maybe_ the same should be done with the column number,
>>> I'm not sure.  Internally, the first line is line 0, but for most people
>>> expect that to be printed as 1.
>>>
>>> See 'scm_i_input_error' in read.c or 'syntax-error-printer' in
>>> boot-9.scm for examples.
>>>
>>> > And how about the format should I throw with them?
>>> > What about this:
>>> > ------------------------------cut--------------------------------------
>>> > (error "invalid syntax!" port-filename port-line port-column)
>>> > ------------------------------end--------------------------------------
>>>
>>> 'port-filename', 'port-line', and 'port-column' are procedures that must
>>> be applied to a port.  See the manual for details.
>>>
>>> However, these remarks concern only error messages generated by your
>>> sweet expression reader itself.  Your other responsibility is to add
>>> source properties to every datum that you read, so that if an error is
>>> detected later in compilation, the resulting error message will include
>>> the filename, line number, and column number.
>>>
>>> If you are able to use Guile's internal 'read' procedure, then you may
>>> rely on it to apply the source properties for anything that it reads.
>>> However, you will still need to use 'set-source-properties!' on anything
>>> that isn't taken care of by the internal 'read', such as lists that are
>>> written in a non-standard way.
>>>
>>>   Regards,
>>>     Mark
>>
>>
>

Re: About sweet-expression

[David Kastrup]

Nala Ginrut <nalaginrut@gmail.com> 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.

That's like thinking the easiest path for a Franch-speaking newbie to
learn English is to start by learning Latin.

You'll find that kind of opinion expressed mostly by people fascinated
with Latin rather than English.

-- 
David Kastrup

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Tue, Mar 6, 2012 at 2:42 PM, David Kastrup <dak@gnu.org> wrote:

> Nala Ginrut <nalaginrut@gmail.com> 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.
>
> That's like thinking the easiest path for a Franch-speaking newbie to
> learn English is to start by learning Latin.
>
> You'll find that kind of opinion expressed mostly by people fascinated
> with Latin rather than English.
>
>
Oh~well, let them be. This sweet won't make Latin fans engulf English
world.
Take it easy. I believe it's a good way to show how prefix is better than
infix in some cases.



> --
> David Kastrup
>
>
>

[-- Attachment #2: Type: text/html, Size: 1905 bytes --]

Re: About sweet-expression

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

Sorry for the slow updating. But I think this pretty thing could be written
as leisure.

I added 'nfx', so the complex infix rocks:
{1 + 2 - 5 / 4 * 3 + expt(2 3)} ==> 13/2

Enjoy!

[-- Attachment #2: Type: text/html, Size: 251 bytes --]