From: Mark H Weaver <mhw@netris.org>
To: Fis Trivial <ybbs.daans@hotmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: How to record source properties for all symbols?
Date: Tue, 05 Jun 2018 18:09:57 -0400 [thread overview]
Message-ID: <87a7s83mx6.fsf@netris.org> (raw)
In-Reply-To: <BLUPR16MB05008EAD2DE2F5417B26F41392670@BLUPR16MB0500.namprd16.prod.outlook.com> (Fis Trivial's message of "Mon, 4 Jun 2018 15:41:52 +0000")
Hi,
Fis Trivial <ybbs.daans@hotmail.com> writes:
> Mark H Weaver writes:
>
>> The problem is that there's no place to store the source information for
>> symbols in the standard S-expression representation.
>>
>> The principal defining characteristic of symbols -- that "two symbols
>> are identical (in the sense of 'eqv?') if and only if their names are
>> spelled the same way" (R5RS § 6.3.3) -- combined with the fact that
>> 'eq?' is specified to be the same as 'eqv?' for symbols, leaves us no
>> way to distinguish two instances of the same symbol, and therefore no
>> way to store per-instance annotations such as source information.
>>
>> Fixing this would require abandoning the plain S-expression
>> representation in favor of one in which symbols are represented by a
>> different data structure. Our reader would need to be extended to
>> support the option of returning this new data representation instead of
>> plain S-expressions, and our macro expander would need to be modified to
>> accept this new representation as input.
>
> I still believe it's crucial to give user correct and detailed error
> message,
I agree. I didn't intend to dispute the importance of good error
messages. I merely intended to explain what the problem is, and why it
hasn't yet been done.
> After poking for a few days, I found that I have hard time understanding
> the code, can you give me some hints for reading the code so that I can
> understand how to encode the source information. Currently, I am still
> trying to make a baby step, encode source information into symbol.
It can't be done. I tried to explain the reason in my earlier message,
but I guess you don't understand. I don't have time right now to make
another attempt.
> I know that will break everything, but at least I will have basic
> understanding of underlying mechanic.
No, it simply won't work at all.
> Though I didn't find any keyword like `parser' or `lexer', but I tried
> to dig into `scm_read_expression', which returns a stringbuf.
What makes you think 'scm_read_expression' returns a stringbuf?
It returns an S-expression.
I appreciate your willingness to help with this, but I think that you've
chosen a task that's too difficult given your level of experience with
Guile. If it was straightforward, it would have been done long ago.
Mark
prev parent reply other threads:[~2018-06-05 22:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 19:48 How to record source properties for all symbols? Fis Trivial
2018-06-04 10:07 ` Mark H Weaver
2018-06-04 15:41 ` Fis Trivial
2018-06-05 22:09 ` Mark H Weaver [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7s83mx6.fsf@netris.org \
--to=mhw@netris.org \
--cc=guile-devel@gnu.org \
--cc=ybbs.daans@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).