Comments (7)
Can you please provide a more concrete example of what you're proposing here? I'm not sure I follow... if this is just to avoid having to give a name for args when also wanting to specify its SymOpts
, then I'd propse to change the type of Arg
instead (because I don't understand your proposal for defn
...) and change the tuple type into an arg object:
// current
export type Arg<A extends Type> = A | [A, string?, SymOpts?];
// maybe could be...
export type Arg<A extends Type> = A | Pick<SymOpts, "q" | "num" | "prec"> & { type: A, id?: string };
Then use in situ like so:
defn("float", [{q: "in", type: "float", num: 4}], (x) => [...])
from umbrella.
I expect something like
defn("float", [arg('float'), inarg('float'), outarg('float')], (x, y, z) => [...])
from umbrella.
And also, simple type like export type Arg<A extends Type> = { type: A, id?: string, tag: 'arg' };
could be better if we just expect users to use factories like above instead of plain objects.
(Although we would anyway deal with backward compatibility of keeping A
as bare strings)
from umbrella.
@sylee957 Thank you for all these thoughts, but may I please ask a question here: What is your general use case for this library? I'm just genuinely super curious, since you've been filing a ton of issues in a very short amount of time and mainly about aspects I'd personally consider pretty specialized (not necessarily edge cases, but definitely aspects I've rarely needed in the 4.5 years since this project started). E.g. case in hand here: The times I've required defining function args with options was only when working with arrays args or a handful of cases with inout
qualified args. The other 99% is just passing the arg type names. Please don't take this the wrong way, I'm just trying to understand how all these different issues, requests & preferences all fit together (from your POV)... What are you working on (if I may ask)?
Also, related, there're features (like support for structs and uniform blocks) I definitely would like to support and have attempted several times in the past, but always got stuck by getting into super complex type constructs and generics nightmares before giving up again. In those situations, I often come to the conclusion that my time is better spent on more useful things... at least until there's a more obvious way forward.
Lastly, I also want to stress once more that GLSL (and its semantics/details) is always just gonna be one (if currently still the main) target of multiple others and 100% feature parity with GLSL was never the aim. This coming year I want to focus more on WebGPU/WGSL — so please do keep these aspects in mind here too...
from umbrella.
I often come to the conclusion that my time is better spent on more useful things... at least until there's a more obvious way forward.
Unfortunately, I'm unclear about the interest or roadmap about the project, after hearing this comment though.
Sadly, I don't think that there is much competitor projects in implementing shader languages in Javascript.
I think that I may look for TSL in three.js, if they have more interests and bigger community to deal with more general use cases, thanks.
from umbrella.
@sylee957 I think you're very much misreading my previous comment: "My time being better spent" referred to my own previous attempts to add struct & UBO support, absolutely NOT regarding your efforts... I was (still am) genuinely interested in learning more abour your use case(s), since it would help me to better understand how you're intending to use this package (and what for). Some of the changes & syntax features you address are great for general completeness, but I've been trying to explain in your various issues a) why certain things are not there (yet) or are currently implemented differently than what you propose (e.g. template literal types discussion in #438 ) and b) I'm always cautious about spending too much precious time on things with dubious ROI, since each of these additions also means increased long term maintenance effort (usually on my end). I believe these are all fair points, but obviously you beg to differ... it's also why I've been repeatedly asking you to provide a bit more context about your own interest/usage of this project.
I've not said "no" to any of your points, just please understand that this package is just a small fragment of a much larger undertaking and there's a need to first experiment with some of these proposals (to get a better "feel" for them) before comitting to them. Some of the things in question are quite fundational (but also subjective/opinionated) changes (e.g. the above proposed arg handling) and so please understand that I need to ask for more context (or have different views) and/or need more time to think about wider implications of some of these proposals. None of these things should imply disinterest and I apologize if this is what you took away from this....
from umbrella.
I was (still am) genuinely interested in learning more abour your use case(s), since it would help me to better understand how you're intending to use this package (and what for).
I’m doing studies of how to supplement all the knowledges I have about typescript, functional programming, object oriented programming, dependent types,
to implement shaders more formally and completely in GLSL specifications,
and implement some complimentary features in downstream project for the things that you find opinionated, difficult, or hadn’t worked on, important, or less important.
from umbrella.
Related Issues (20)
- [shader-ast] Dependency for ternary operators, while and for loop HOT 1
- [shader-ast] Array texture types are missing HOT 1
- [shader-ast] Missing matrix types HOT 1
- [malloc] Multi-threaded allocations HOT 4
- Prototype Pollution vulnerability affecting @thi.ng/paths, versions <=5.1.62 HOT 7
- [hiccup-canvas] "packedPolyline" needs separate implementation or packedPoly needs to accept stride options?
- [color] ? [binary] Comparison with -0 using the "===" operator will also match 0 [equals-negative-zero] HOT 2
- RDMS based on rstream-query HOT 1
- [examples] Issue running the examples (failed to resolve entry for package) HOT 3
- [hiccup-svg] hiccup-svg's attributes don't seem to handle rstream HOT 7
- [rstream] error when using skypack build HOT 5
- [geom-accel] SpatialGrid2 hangs runtime when using `set` method HOT 3
- Polygons with holes? HOT 8
- [shader-ast] "Building a shader graph editor (WebGL, shader AST transpiler, UI)" HOT 2
- [rdom] Issue understanding $klist HOT 4
- [geom] update polymorphic function signatures to provide better return types
- [atom & rstream] Asking for advice on good practices
- [rdom] SVG el add class > Uncaught (in promise) TypeError HOT 1
- [rdom] Error: illegal state: operation not allowed in state 3 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from umbrella.