So the end user would install goat_recognizer as an application bundle, and image_recognizer would be (the interpreted equivalent of) a dynamically linked library?
That removes the issue of duplicate libraries for the end user too
Since presumably image_recognizer.bun would be stored in some central place where both goat_recognizer.abun and sheep_recognizer.abun could depend on the same file
and if goat_recognizer and sheep_recognizer both depend on fancy_terminal, since that's not a big library each bundle would have its own copy (or if I did the cache-based solution the single download would be symlinked in during the install)
Why can't all modules/module-groups just be modules, and ones that would typically be the small dependencies in module groups would just be declared/imported/configured as static by the application
One program's tiny dependency is another's huge dependency. What if I'm super restricted resource-wise and have fifty programs that all depend on a bigint module?
I have no choice but to have fifty copies of that bigint module as the end user
Okay so goat_recognizer uses image_recognizer and fancy_terminal, and image_recognizer uses neural_network and bigint, which are both small dependencies which would be modules in your module-module-group dichotomy
All of those would just be modules
goat_recognizer would mark image_recognizer as dynamic
So image_recognizer would be bundled as its own thing, with neural_network and bigint statically linked, and goat_recognizer would have fancy_terminal statically linked and rely on image_recognizer as an external bundle
Basically instead of the library creator deciding it's either a module or a module group, they just write a module, which may or may not depend on other modules
Then the user of that library can decide to statically or dynamically link it
This also gives you flexibility regarding libraries which themselves have dynamic dependencies. You could pass that decision on to the user of the library. E.g., if image_recognizer decides that neural_network is big enough to be worth dynamically linking in some situations, goat_recognizer would get the final say on whether or not neural_network gets statically linked into image_recognizer's bundle
and how is that different from the module group system? my favorite feature of it was that all you had to do was give the interpreter a path to a module group and it would only use the modules in that group while running, thereby avoiding dependency issues
If a module says it depends on thing_doer version 2.1, and you have thing_doer version 1.8 for something else, it's not like the module would suddenly be given thing_doer 1.8 and error out
You don't need to restrict what modules can access because you know what they access
@Ginger Don't change things for the purpose of changing things, change them if there is a concrete problem with the existing system that you have a solution for
I've often tried to re-invent stuff only to come up with the exact same thing it was before again
Ooh...does an interpreted language that produces executables which dynamically link a library that is the interpreter, and just store the source code as a string in the actual executable?
also completly unrelated side note: ive been messing with css and divs and whatnot for 1.5 hours already and still cant make a nice canvas size + alignment
Well the main gimmick of the type system was that it wasn't algebraic...it had calculus You could take the derivative of a type, which would apply the sum/product/chain rules to sum/product types There were also integrals which reversed that
@mousetail Not really...they hang one tab, only if developer tools are open, and double-clicking the close tab button closes it. And if dev tools aren't open, the tab stops running and prompts you to either close it or keep running
The only thing it DoSes is the exact same page that ran the infinite loop
anyhow yeah i feel like some of rust's clutter is from using the generics syntax, not in and of itself so much as in conjunction with the kind of stuff you end up having to write in a rust type
though there's also good old turbofish
also some of the normal c-ish syntax itself can feel a bit awkward when other parts of the language feel more functional
Closures being separate types that implement Fn, FnOnce, etc
Having to wrap stuff (to send a Vec to an async function that needs a Read you need to send something like a Mutex holding a thing holding a Cursor holding a Vec)
Having to call iter() before you can do map, filter, etc
Having to convert between &[u8], str, String, Vec<u8> (less of an issue, but there was this one library that was very inconsistent with them)
in terms of specifically python's syntax for them i think the basic map case could afford to be less verbose but filtering with if is way better than just dropping conditions in there
@Seggan after reviewing Lua's import system it's probably possible for me to make this work with only minor changes to Rol
> This function is not supported by Standard C. As such, it is only available on some platforms (Windows, Linux, Mac OS X, Solaris, BSD, plus other Unix systems that support the dlfcn standard).
I'm not sure how the authors of the Lua reference define "some" :p
@Seggan If you can get Rol to add a bit of Lua code to the beginning of all files it generates I can make this work
all I have to do is add a custom package searcher
oh also, for imports can you make something like import foobar @ 1.0 turn into require("[email protected]")?
yeah this entire thing can be done in Lua pretty much
@RydwolfPrograms I think eeryone likes them, but the problem is that it's not general enough. You can make lists, tuples, dicts, and sets but not custom collections
Haskell's do and Scala's for...yield is more general
@Ginger Maybe there's a secret underground society of people all using their own OSes that don't have support for that function?
@user You can use a comprehension to make a generator, which you can then pass to a custom collection's constructor (unless I'm misunderstanding what you mean)
True, but that requires knowing the collection's type
If you have a function that could take a list, a tuple, or any custom collection, including ones not defined in your library, then you can't map and return the same type, you'd have to return a generator and the person calling your function would have to turn it into the appropriate type
Yeah, other languages use the word "tuple" to describe a hetero collection, but dynamic languages already have lists for that. Tuples are just immutable
@RydwolfPrograms yeah imo when ure reading code parens make the cond stand out, while without parens you see a brace and have to scan back to see the cond
@user if let syntax is a bit wonky, => instead of -> feels cluttered
@Ginger no. thats just makes a weird facade over luas import system
also, there is a lua file that all rol programs load (has intrinsic functions and stuff) so as long as the package manager doesnt care that its only loaded once per run i can stick the lua code in there
Is LYAL still a thing? hgl is getting to the point where it could be usable by people other than me, and I'd like to try and find some people who would be interested in learning it.
