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 <address@hidden> 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 <address@hidden> 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 <address@hidden> wrote:
>>>
>>> Nala Ginrut <address@hidden> writes:
>>>
>>> > On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <address@hidden> 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
>>
>>
>