Opened 5 weeks ago

Last modified 10 hours 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 2 weeks ago.
0002-Also-documentation.patch (715 bytes) - added by Idiomdrottning 2 weeks ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 4 weeks 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 2 weeks 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 2 weeks ago by Idiomdrottning

Changed 2 weeks ago by Idiomdrottning

comment:3 Changed 10 days 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 10 days 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 15 hours 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 13 hours 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 11 hours 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 11 hours 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 10 hours 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.

Note: See TracTickets for help on using tickets.