importing from single function modules is a little verbose..

[mighdoll]

The Lygia library of wgsl functions sensibly breaks up its library into small files with one or two functions in each file. For example, the rgb2hue.wesl file contains only fn rgb2hue() {}. Consuming Lygia becomes a little verbose, with rgb2hue duplicated two or three times:

import lygia::color::space;
  ...
  rgb2hue::rgb2hue();

or:

import lygia::color::space::rgb2hue::rgb2hue;
  ...
  rgb2hue();

Note that the the small file style is handy for WESL users of Lygia. The npm wesl packager makes many small WeslBundle files in the Lygia dist directory, with indexing to each via package.json exports. npm WESL users can include a selected few of the WeslBundles for full dynamic linking of shaders, without unnecessarily bulging their application bundles with unused functions.

Current WESL will work just fine like this, it's just a little wordy. But I bet we can find ways to make this pattern more concise in WESL, even w/o requiring larger application bundles.

cc: @patriciogonzalezvivo @sdedovic @josephreisinger

[sdedovic]

Hey full disclosure, I have a lot of other stuff on my plate to fully contribute but will do what I can!

I think the above is fine. Granular dependencies > (is more important than) short import declarations. Especially for a library like Lygia, which is a grab-bag of utilities, helpers, and simple functions.

Two options, if this is a big concern, in my opinion:

• combine nested namespaces. maybe color::space becomes color_space but that doesn't reduce the character count. (and introduces breaking changes to the API)
• combining namespaces and implementing dead code elimination (tree shaking?) so now lygia::color::space contains the rgb2hue symbol but the compiler removes all other unused symbols from the namespace. The problem here is that not every compiler / optimizer can do this, so not every bundle will be the same.

[mighdoll]

 I think the above is fine. Granular dependencies > (is more important than) short import declarations. Especially for a library like Lygia, which is a grab-bag of utilities, helpers, and simple functions.

Yeah, having a hierarchy for a large utility library like Lygia makes a lot of sense.

Here I was just complaining that the WESL translation ends up repeating rgb2heat two or three times. Admittedly, that's not the most important issue to help Lygia. I bet several things would be higher on your list! (Like function overloading for #126).

Still, I wanted to write this issue down while it was fresh in mind. There are features we've discussed for future versions of WESL/WGSL that might also help fix this small problem. I'm thinking of discussions we've had about a future feature called 're-exports'. Like 'index.js' in the JavaScript world, re-export would allow Lygia to keep the same hierarchy of files, but provide a sort of alias, e.g. to allow referencing the fn rgb2heat as a child of the space module, rather than a child of the rgb2heat module.

* combining namespaces and implementing dead code elimination (tree shaking?)  so now `lygia::color::space` contains the `rgb2hue` symbol but the compiler removes all other unused symbols from the namespace. The problem here is that not every compiler / optimizer can do this, so not every bundle will be the same.

I agree, dead code elimination would only help some of the time. The WESL tools actually already do dead code elimination. But for users that want to link shaders dynamically at runtime, the unused code would still be in the application bundle. WESL-js or WESL-rs can remove the unused code before its sent to WebGPU, but that doesn't help a mobile web developer who's worried about bundle size.

Separately, I suppose Lygia might someday be tempted to make flattened API available too like lygia::rgb2heat. That wasn't my original point here, but I suppose some of the same issues will come up..

[s-ol]

I tried adding index files like the following to lygia but it seems the imported members are not re-exported:

import super::math::{
    adaptiveThreshold,
    bump, 
    const,
    cubic,
    decimate,
    frac,
    gain,
    gaussian,
…
};

The spec page mentions

(Else if re-exported or inline module in current module: We continue with that module.)

and

(Re-exporting changes the path.)

But I'm not sure what the syntax for that would be?

EDIT: reading around other issues a bit, i get the impression that aliasing definitions is an issue due to #65, so we can't do this currently. Maybe the spec page should be adjusted to not give that impression?

[mighdoll]

@s-ol your timing is pretty good! Just yesterday I posted a draft PR to the spec that would address this: #187. The proposed syntax in the PR is public import.

Read through #187 and see if it makes sense? The draft is brand new and comments from a fresh reader would be very helpful.