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?

maybe @aw, @neauoire, or @cancel ?


@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.

@technomancy @aw @neauoire @cancel no, but when I see erlang in the url, I click the url, I am but a simple man

one sec

@klardotsh @aw @neauoire @cancel it's definitely nix-adjacent; similar ideas to Unison and A Personal Computer for Children of All Cultures.


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:

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?

@klardotsh it's true, C ruins literally everything. I have a sketch of this that works reasonably well until you start caring about C code, then everything goes completely out the window.

@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!

@klardotsh @technomancy @aw @neauoire I hate package managers and I don’t use them (except when required to make some Linux distribution thing work)

I avoid using software libraries and I don’t use any that only work in the context of a package ecosystem. I also don’t use any programming languages that rely heavily on package management (like rust and JavaScript)

@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.

@klardotsh Have you considered ... Would you gave a moment to ...

> no, I won't just use Nix either, even if I like some of its ideas.

I feel called out. 😁

@neauoire @cancel @aw

@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

Sign in to participate in the conversation

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.