>>Ideally, ATS package manager should be written in ATS :D (as in the worst case, it will require just a C compiler to be built)
For ATS3, the design I have is to support some form of internet-based code search. This would make package management in ATS3 quite different. We could use tools like npm and Connan after template resolution is completed. However, we do need a "native" package management system for handling template resolution. Speaking of template resolution, I'd like to mention a surprise I got not too long ago. I wrote some ATS3 code and compiled it to JS and tested it successfully. Later l noticed that I had not implemented the string comparison used in the ATS3 code. Why did my code work? I realized that the compiler actually generated a function in JS for comparing strings by treating a string as a sequence of characters and using the generic comparison function for sequences to compare strings. In short, the sheer complexity of template resolution in ATS3 would make it very difficult for you to know what kind of code is generated by the compiler even if you yourself wrote the source code. On Sunday, May 30, 2021 at 9:42:43 PM UTC-4 [email protected] wrote: > I can confirm, that having ghc (1 GB+) just to build ats package is > overkill. > I am not speaking of cross compiling ghc to another architecture/libc is > pain as well, as it requires big amounts of RAM and 2+ hours of building > for stage1/stage2 compilers.... Then, you need to build cabal and only then > you will be able to build atspkg... > > Having to have/build python is not a pleasure as well, but at least, it is > not required to bootstrap itself :) > > Ideally, ATS package manager should be written in ATS :D (as in the worst > case, it will require just a C compiler to be built) > > For now I am using git with libraries being a git modules in $REPO/libs > directory, like this: https://github.com/dambaev/text/tree/master/libs > and staloading appropriate modules like this: > ``` > #define LIBS_targetloc "../libs" (* search path for external libs *) > > #include "./../HATS/text.hats" > #include "{$LIBS}/ats-bytestring/HATS/bytestring.hats" > staload "{$LIBS}/result/src/SATS/result.sats" > staload "{$LIBS}/foldable/src/SATS/foldable.sats" > ``` > > it can be not ideal for the case when "library A depends on C 1.0 and on B > 1.0 and at the same time B depends on C 1.1", as $REPO/libs will contain 1 > version. At the same time, for handling such case you need to at least > properly handle symbol prefixes with ATS_PACKAGE and ATS_EXTERN_PREFIX, so > I am not thinking about such case yet.... > > Ah yes, I am using NixOS and nix package manager to handle C/C++ libraries > dependencies, so what I usually need to build a project: > ``` > $ nix-shell shell.nix > nix-shell $ make > ``` > > I should try to use Conan, though, to check how it handles the > dependencies and such... > > -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/bcf9b81f-e199-4609-86af-a75b0fac8b19n%40googlegroups.com.
