SLIME + Named readtables

Hi! I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before. So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation. Please see the essay here: https://bitbucket.org/budden/clcon/src/e3c40c555295336a3a13c506cce6a179f9dd8...

Hi budden, On Wed, Aug 2, 2017 at 12:33 PM, 73budden . <budden73@gmail.com> wrote:
I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before.
So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation.
I can see how it's useful to write down your train of thought to reach your current position about how named-readtables should be better support in SLIME. Can you write down a summary of what your recommended solution is? Cheers, -- Luís Oliveira http://kerno.org/~luis/

Hi! Here is a more detailed description of my suggested solution https://bitbucket.org/budden/clcon/src/1685075f335bd6ae5ec3d13a2423b46ff8ae1... 2017-08-11 17:33 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
Hi budden,
On Wed, Aug 2, 2017 at 12:33 PM, 73budden . <budden73@gmail.com> wrote:
I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before.
So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation.
I can see how it's useful to write down your train of thought to reach your current position about how named-readtables should be better support in SLIME. Can you write down a summary of what your recommended solution is?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/

On Sun, Aug 13, 2017 at 9:33 PM, 73budden . <budden73@gmail.com> wrote:
Here is a more detailed description of my suggested solution
I was looking for an executive summary rather than more detail. :-) In any case, your proposal generally makes sense to me. I have a question though: what should happen in the REPL? Following the spirit of your solution, it seems like we should have a new change-readtable operation. How should we represent the current readtable visually? Also, it seems like it might be useful to have some concept of default readtable for a given package: perhaps there's still a use for *readtable-alist* after all? -- Luís Oliveira http://kerno.org/~luis/

On Sun, Aug 13, 2017 at 9:33 PM, 73budden . <budden73@gmail.com> wrote:
Here is a more detailed description of my suggested solution
I was looking for an executive summary rather than more detail. :-)
In any case, your proposal generally makes sense to me. I have a question though: what should happen in the REPL? Following the spirit of your solution, it seems like we should have a new change-readtable operation. I suggest to keep (in-readtable), but it does not touch *readtable-alist* for a packages or readtables from an exclusion
Also, it seems like it might be useful to have some concept of default readtable for a given package: perhaps there's still a use for *readtable-alist* after all? I don't think so, there is no concept of default readtable for the
Hi! Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details. And I had to update my proposal due to your questions - now it has even more details :) Link follows: https://bitbucket.org/budden/clcon/src/9b3ecf3dce35a6978c57352dfc54f4a1653ac832/doc/how-to-support-readtable-with-slime.md?at=default&fileviewer=file-view-default 2017-08-17 1:31 GMT+03:00, Luís Oliveira <luismbo@gmail.com>: list. More important, (in-package) for those packages won't change *readtable* anymore. So no new operation is required. But current behavior is a violation of standard. I remember when I suggested this change last time, I faced some objections from SLIME users, but IMO How should we represent the current readtable visually? package in the standard, so the user would have to change a readtable explicitly. I understand it is inconvenient. So right thing might be the following: 1. Add (swank:in-package-and-readtable :package) form which would take the readtable from *readtable-alist* 2. Learn SLIME to recognise this form in editor files like it recognizes in-package now. The only disadvantage here is a confusion which can originate from interaction of *readtable-alist* and exclusion list. With my current suggestion, we can keep *readtable-alist* and exclusion list disjoint. If we introduce the concept of default readtable for package, *readtable-alist* now serves for two goals and this is not that clear.
How should we represent the current readtable visually? It would be nice to show it on a toolbar for editor buffers, but for REPL I think it is not hard to enter *readtable* and press return :) After all, currently we also can't see the readtable.
-- Luís Oliveira http://kerno.org/~luis/

On Fri, Aug 18, 2017 at 1:03 PM, 73budden . <budden73@gmail.com> wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master? Cheers, -- Luís Oliveira http://kerno.org/~luis/

Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described? 2017-08-18 16:39 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . <budden73@gmail.com> wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/

Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think? Cheers, Luís On Fri, Aug 18, 2017, 17:15 73budden . <budden73@gmail.com> wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . <budden73@gmail.com> wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/

Hi! Do you mean that in any case (in-readtable) form should have a priority over *readtable-alist*? Let's speculate about it a bit. Could the change break something? I guess no: if someone have this form in the file, then it modifies *readtable-alist* already every time the file is loaded. So it looks like this change can make no harm. I think we don't even need exception list for now - just we don't need to alter named readtables at all for this change. Does that sound like a truth? If so, this is a part of what I had implemented already, so I can start re-applying it as soon as I find a time (in a several days). 2017-08-18 22:02 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think?
Cheers, Luís
On Fri, Aug 18, 2017, 17:15 73budden . <budden73@gmail.com> wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . <budden73@gmail.com> wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/

Yes, I agree. Let's have in-readtable take priority. On Sat, Aug 19, 2017, 08:03 73budden . <budden73@gmail.com> wrote:
Hi! Do you mean that in any case (in-readtable) form should have a priority over *readtable-alist*? Let's speculate about it a bit.
Could the change break something? I guess no: if someone have this form in the file, then it modifies *readtable-alist* already every time the file is loaded.
So it looks like this change can make no harm. I think we don't even need exception list for now - just we don't need to alter named readtables at all for this change. Does that sound like a truth?
If so, this is a part of what I had implemented already, so I can start re-applying it as soon as I find a time (in a several days).
2017-08-18 22:02 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think?
Cheers, Luís
On Fri, Aug 18, 2017, 17:15 73budden . <budden73@gmail.com> wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira <luismbo@gmail.com>:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . <budden73@gmail.com> wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
participants (2)
-
73budden .
-
Luís Oliveira