Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Persistent use (if desired) #85

Open
tinmarino opened this issue Apr 5, 2020 · 7 comments
Open

Feature: Persistent use (if desired) #85

tinmarino opened this issue Apr 5, 2020 · 7 comments

Comments

@tinmarino
Copy link
Contributor

I'd like to avoid prefixing commands with use at each command and have a useall keyword or something similar to persistently use a module in the sandbox.

  • Requirement: compile this module only once.
  • Example use: I release my first module in the ecosystem. A slang permitting scalar without sigils. This issue do not really add unreachable features, just fasten typing:
    1. Test the module during dev.
    2. Use the module in a REPL
    3. Create a custom (in user scope) shell

I'd like to get your opinion before coding: easy code, hard negotiation as always with default parameters.

@bduggan
Copy link
Owner

bduggan commented Apr 5, 2020

Usually I would think a single use would be enough...but in this case changes to the grammar are not persisted. It seems like perhaps the behavior that would would make this work would be to run use nogil every time a cell is executed.

How about a magic? Something like

#% always
use nogil;

To automatically always prepend the contents of this cell to every cell just before running eval. This would also provide a way to add custom operators, etc

@tinmarino
Copy link
Contributor Author

I would think a single use would be enough.

I did not know that. I'll have a look at making grammar and operator persistent by default in that case.
If I don't manage, thanks for proposing the magic, it'll be good for me.

@tinmarino
Copy link
Contributor Author

I made 2/3 in #88. What follow is to prepare the last 1/3 (to share and remember):

How (slang, operator): The idea was that whatever you do inside the compiler (sandbox), you cannot change the grammar. You change only some Language Braid variables $?LANG in TOP (anyway you are trapped in this method). So one way or another, some variables must get out ($*JUPYTER).

Future (pragma): The target of the set_pragma is in Cursor, most of them are treated as slang. As shown:

for $?LANG.slangs.kv -> $k, $v { say $k }

They are discriminated in World

But apparently the TOP Grammar is treating really bad my pragmas, at each new parse.
I'm sure it the guilty because I found a dirty way to "decorate" it but it was pretty nasty which is not a good decoration 😄.

List of Non slang pragmas:

  1. strict -> $*STRICT
  2. precompilation -> ??
  3. lib -> RepositoryRegistry
  4. experimental -> p6/lib/experimental.rakumod

@tinmarino
Copy link
Contributor Author

I see 3 solutions:

  1. Hook the do_pragma in Word to do_it at every cell
  2. #% always use nogil (not really MY idea but solves everything except copy paste and #% run)
  3. Dead end: Discriminate also the 4 dirty pragma in our side our support only the rest (and doc that) with some tricky hacky introspection in grammar.

@bduggan
Copy link
Owner

bduggan commented Apr 7, 2020

#% run could still work -- always would just really mean always -- so if the first cell has an always and the second one has run, the always would also be executed

@tinmarino
Copy link
Contributor Author

We've just add a similar issue in jupyter-vim client.
I've added ... 4 variables. Say exec_(before|pre|post|after).
The user can decide if send:

  1. in another execute_request (or compilation unit for the kernel) with before or after.
  2. same request prepended or appended
    In the issue, the user wanted to send in another request before to clear the screen.

Is that overkill ?

@bduggan
Copy link
Owner

bduggan commented Apr 8, 2020

Is that overkill ?

No -- makes total sense -- I was thinking of just starting with always but there might be more options later, like always after or always clear (to reset), or always show (to see what's in the current always) or always append (or prepend?) or maybe always when /regex/?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants