something that's on my mind for gluumy is, of course, how to specify dependencies/external packages
I have no interest in writing a package manager that's more than the equivalent of like maybe 200 lines of shell, because this is an over-and-over-again solved problem in software development
can one of y'all with strong opinions in this space lend some ideas of what you might like to see for a small+~simple functional language's dep packaging situ?
@aw @neauoire @cancel I've thought about "what if you just mandated the use of git submodules/subtrees and the package manager was just a git wrapper" but then like what if you don't use git, what if you use fossil? it's back to the drawing board.
whatever solution it is, it should work for developers on any OS, and not make distributions send me hate mail if they happen to try packaging something written in gluumy some day.
no, I won't just use Nix either, even if I like some of its ideas.
Okay hang on, this is interesting to think about, especially considering I have a similar arity-overloading thingy going on in gluumy to what erlang & co do (ex: https://github.com/klardotsh/gluumy/blob/e46433f1a3e79a97dec8d8a565ae741534118e1b/lib/core/math.glm)
I guess the question in my head is: how do you avoid the C problem, where everything is in one giant namespace, while **also** not standing up the publishing database Joe discusses at the end of that email?
@technomancy I guess in some ways I don't actually care about C code. Hell, gluumy doesn't even support calling *pure lua libraries* without at least redefining the interfaces within gluumy's type system first.
maybe in a content-addressed world the second FFI boundary down to C is the one where I throw my hands up and say "you know what, screw it, your distro needs to be handling this contract"?
this is an interesting thought exercise
@technomancy you've also made me think about another idea: what if *all* .glm files within a tree were just... automatically discovered and included (and flattened to one module-space)? and the "module" system was just like
gluumyc /usr/lib/gluumy/gluuv /usr/lib/gluumy/ncurses-glm ./src
and then each module had to define a namespace.txt or something at the root that contains the importable name of that namespace/module-space. then can just use tarballs for dist?
almost like go in a way. hmmmm
@klardotsh I dunno what glm files are but I think the package.searchers system is a real good idea and allows for all kinds of languages to mix on the Lua runtime, would be a shame to give that up
@technomancy glm are the files in this language (called gluumy) I've been designing / starting to build
as designed so far, it uses lua under the hood as somewhat of an implementation detail, and is not meant to have bidirectional transparent interop with lua the way eg. fennel does
gluumy code importing lua code requires writing explicit bindings because my intent is to have (1) a strong type system, and (2) no nil. I haven't thought about how/if bindings could be autogenerated/inferred
@technomancy @aw @neauoire @cancel Sorry for coming way upthread here but after giving this email time to mentally soak in, implementing (much of) Joe's ideas actually simplifies gluumy and answers a question I'd had for the past week (why have free functions *and* member functions in an immutable-first language?) by simply eliminating member functions
Thanks for linking this, yet more concepts cut out of the language design is a good thing!
@technomancy I remember that one!
"I think this would make open-source projects easier, since the granularity of contribution goes down. You could contribute a single function - not an entire application."
This is the node community - even if functions were strongly typed and well documented - this rapidly reaches a point where it can't be curated by humans.
@clacke I met in the middle to some degree :P
thanks to technomancy's idea share there I think I'm going to try "everything is a big ol pile of functions with no namespacing, the language doesn't care how you get them into the search path, the compiler will provide a way of resolving conflicts using something like CSS's z-index" (I'm thinking of the case where you want to monkey patch ONE FUNCTION out of some library and don't want to maintain a whole fork)
I'm abdicating the retrieval side
@clacke like it shouldn't be every language's job to reinvent package fetching and versioning. that's pkgsrc/nix/guix/debian/yum/alpm/apk/ebuild/omg so many of these things exist, and that's not even counting cargo/npm/pip/gem that are lang-specific.
so I'll leave versioning to the tools that are already good at it. gluumy's contribution is the compiler to stitch it all together.
in theory this should actually make gluumy exceptionally well-fit to a nix environment
the real value for a package manager is IMO not the packages, but having a searchable place for their metadata.
- can I find if functionality has already been written?
- how easy is it to inform the community of a package?
- is documentation beautifully rendered and easily accessible, so I can quickly see if this does what I need?
- is stdlib & default docs accessible the same way?
I'm still not sure that pkg management is a solved problem. I'm not even sure we have a clear description of "the problem" to work from.
I still see package managers where you can publish a tarball that has no upstream source, or where the published version doesn't have to match some src control tag or release, where there are no namespaces, so user ownership can switch but nobody realises that the trust / provenance has changed.
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.