Opened 9 months ago

Last modified 8 months ago

#1735 new enhancement

Strip away prefix when importing

Reported by: Idiomdrottning Owned by:
Priority: minor Milestone: someday
Component: core libraries Version: 5.2.0
Keywords: Cc:
Estimated difficulty: medium

Description

I know we can easily add prefix when importing but some eggs already come with too much prefix on all of their procedures. Wouldn't it be pretty sweet if we could import sans them?

(import (sans filepath "filepath:") (sans irregex "irregex-"))

I tried my jolly best to implement it in https://idiomdrottning.org/chicken-core

To support both sans and prefix at the same time (when you want to remove their prefix and add your own much cooler prefix) is left as an exercise for the reader. This just removes it for now.

Attachments (2)

0001-Import-modules-sans-their-prefixes.patch (1.7 KB) - added by Idiomdrottning 8 months ago.
0002-Also-documentation.patch (715 bytes) - added by Idiomdrottning 8 months ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 8 months ago by Diego

I like this idea, though as a side note I'd argue the irregex case isn't an example of a prefix but rather an example of scheme's type-verb convention (as in string-length). In any case, I think I would prefer sans-prefix or no-prefix (or some single-word antonym of prefix), since as is sans feels a bit too similar in meaning to except.

comment:2 Changed 8 months ago by Idiomdrottning

I don't really wanna bikeshed too much about the name.

Re the type-verb thing: that's always been an annoying convention, even with string-null? and friends. But it's out of necessity... but isn't any longer, with a good module system♥

BTW the provided code only strips away the prefix from the names that actually start with the prefix.♥♥👍🐣🐤🤘

Changed 8 months ago by Idiomdrottning

Changed 8 months ago by Idiomdrottning

comment:3 Changed 8 months ago by megane

Estimated difficulty: trivialmedium

I'd like answers to at least these questions answers before adding a new language feature:

  • How hard is it to work around this?
    • Why not write a macro that does the automatic renaming?
  • How does this combine with other import features?
  • Does any other scheme have this feature?
    • If so, does it cause any problems?
    • How do they handle the combinations of other import modifiers?
  • What does Felix or other devs think about this?

Also we could consider adding a more general irregex based renaming facility?

comment:4 Changed 8 months ago by sjamaan

Also we could consider adding a more general irregex based renaming facility?

Please let's not! Import should be deterministic and simple, and ideally easy to process by automated tools.

In general I'm not sure this change is desirable, especially as it introduces nondeterminism (what if a module exports both foo and my-foo, and we strip the prefix "my-"?)

comment:5 Changed 8 months ago by Idiomdrottning

Why did you change the difficulty since there is an implementation?

But implementing it as a macro might work.

Here is one that works:

https://idiomdrottning.org/import-sans.scm

It has a bit of a different interface.

Instead of

(import (sans filepath "filepath:") (sans irregex "irregex-"))

You go

(import import-sans)
(import-sans filepath: filepath)
(import-sans irregex- irregex)

i.e. separate calls.

I guess I could wrap, walk, and shadow the import form so that I could instead implement something like

(import import-sans)
(import (sans filepath: filepath) (sans irregex- irregex) shell srfi-42 (chicken pretty-print))

for example. If that is possible and/or a good idea. Also (import import-sans) looks dorky so another name would be fine. Maybe just sans.

comment:6 Changed 8 months ago by Idiomdrottning

OK, here is an attempt to do that:

https://idiomdrottning.org/sans.scm

I haven't figured out how to use the name "import".

This currently works:

(import sans)
(imports (sans filepath: filepath) (sans irregex- irregex) shell srfi-42 (chicken pretty-print))

With the "imports" instead of "import".

comment:7 in reply to:  4 Changed 8 months ago by megane

In general I'm not sure this change is desirable, especially as it introduces nondeterminism (what if a module exports both foo and my-foo, and we strip the prefix "my-"?)

Shouldn't it in that case behave like (import (rename foo (foo bar) when there's already bar in foo, i.e. silently shadow the original bar?

comment:8 in reply to:  5 Changed 8 months ago by megane

Replying to Idiomdrottning:

Why did you change the difficulty since there is an implementation?

My thinking was that this needs more thought. And maybe warnings. And maybe more documentation about the semantics. The code itself is simple indeed.

comment:9 Changed 8 months ago by Idiomdrottning

The macro version of this expands to import rename so it does whatever that does, which seems to be that when there is foo-bar and bar, it ignores foo-bar and just gives you bar.

I agree with giving the original bar a higher priority than the renamed foo-bar.

Ideally / pragmatically I would want it to give you bar and foo-bar under their original names and only strip non-colliding names. That's an easy enough change if people agree.

Another change I might want is to not rename if the new name would be empty. That's a corner case that might never come up, since say there is filter and filter-map, the prefix is filter- rather than filter.

comment:10 Changed 8 months ago by evhan

Ticket #988 is back I see. :)

This is interesting stuff, I just wanted to say that if we go this direction I'm also in favour of a more general mechanism for import rewriting, rather than stacking up single-use forms like "drop-prefix", "add-prefix", and so on. Rather than something regex-based, though, I think some expansion-time method by which arbitrary transformations could be applied to the imported identifiers would be better, if these can be written as normal Scheme code similar to the way ER macros work. Perhaps this could even take the form of some helper procedures that make rewriting import specifications *within* the ER macro framework easy?

Regarding importing "import" itself, that's not likely to work without other changes since that is one of the few (possibly the only?) identifiers that is treated unhygienically in places, to pull things into an empty syntax environment. Ideally it would be nicely shadow-able, but I don't think that's how it is today.

Just my two cents, otherwise I'd echo what megane has said above.

comment:11 Changed 8 months ago by Idiomdrottning

Rather than something regex-based, though, I think some expansion-time method by which arbitrary transformations could be applied to the imported identifiers would be better

👍

comment:12 Changed 8 months ago by sjamaan

It's an interesting and exciting idea. It certainly fits the general Scheme idea of not piling feature on top of feature!

At first my mind reeled against it, because it would make a lot of tooling even more difficult. On the other hand, we do generate import libraries which are fully static, and we already have macros which can introduce arbitrarily complex import statements anyway. Just adding helpers to make that easier isn't going to hurt anyone.

However, an import statement dropping prefixes is trivial to write (for the user). Writing a custom macro that inspects a module and mangles the identifiers into an import list is a whole different ballgame. Remember, the entire point of drop-prefix or sans was to reduce the number of keystrokes...

Note: See TracTickets for help on using tickets.