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 <nalagin...@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 <m...@netris.org> wrote:
>
>> Nala Ginrut <nalagin...@gmail.com> writes:
>>
>> > On Tue, Mar 6, 2012 at 12:35 PM, Mark H Weaver <m...@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
>>
>
>
