I just observe that the signature of defn is a bit messy to work in practice, for some reasons:
- Although named arguments may be useful for some debugging purpose, however, I think that it is least useful in practice. There may be some reason that function names, or global variable names to have fixed name, if I need to link the shader into some other code, however, names of function parameter variables or local variables are completely arbitrary.
And making them anonymous is often better because I don't want to repeat names, one for javascript variable identifier and the other for shader
(const myfunc = defn(..., 'myfunc', ...), or defn(..., [['float', 'x'], ['float', 'y']], (x, y) => {})
- Qualifiers, like
out or inout, are much more useful, especially if I have to port some code that someone have made, or if I have to work around to avoid struct.
Although I can around the issue by implementing some 'helper' for defn, however, I wonder the better design of the signature could be:
defn(type: Type, args: Arg<Type>[], body: (...Arg<Type>[]) => Term[], name?: string)
where it has advantages
- It may be better to pull out
_args.map(defArg) expose factory like defArg as user API. I think that it is better for deciphering the types if we expect user to make objects homogeneously.
- The names should be more optional and put into backwards, so users don't need to fill
undefined or null positionally if they want anonymous functions or variables.
I just observe that the signature of
defnis a bit messy to work in practice, for some reasons:And making them anonymous is often better because I don't want to repeat names, one for javascript variable identifier and the other for shader
(
const myfunc = defn(..., 'myfunc', ...), ordefn(..., [['float', 'x'], ['float', 'y']], (x, y) => {})outorinout, are much more useful, especially if I have to port some code that someone have made, or if I have to work around to avoidstruct.Although I can around the issue by implementing some 'helper' for
defn, however, I wonder the better design of the signature could be:defn(type: Type, args: Arg<Type>[], body: (...Arg<Type>[]) => Term[], name?: string)where it has advantages
_args.map(defArg)expose factory likedefArgas user API. I think that it is better for deciphering the types if we expect user to make objects homogeneously.undefinedornullpositionally if they want anonymous functions or variables.