This is what I was thinking as well. I don't think the dependencies of the import statements should be exposed transitively, but they need to be added to the vm. I think it's reasonable to only have public classes be exposed by an import, and leave bare functions and non-public classes private.
Jack, no worries about review speed, I just wanted to make sure I was following the preferred procedure. On Wed, Aug 19, 2020 at 3:41 PM Michael Heuer <heue...@gmail.com> wrote: > On Aug 19, 2020, at 12:25 PM, Jack Atherton <l...@ccrma.stanford.edu> > wrote: > > > The most straightforward version of an import statement would just add the > public class in that file to the VM if it hasn't been added already. Do you > think an import statement should also add the ability to splice in > functions and other classes too? > > > In LiCK many public classes depend on non-public classes local to the > file. A quick count shows 437 public classes of approximately 939 total > classes: > > $ chuck import.ck > ... > [chuck](VM): sporking incoming shred: 437 (RubberBand.ck)... > LiCK imported at path ~/working/lick/ > > $ find lick -name "*.ck" | xargs grep class | wc -l > 939 > > Imports should also be recursive, e.g. the public class in the imported > file may import other classes. > > Finally, as described in the linked issue below, having namespaces via a > namespace or package statement would also be quite useful. > > Cheers, > > michael > > > > I get an email when new pull requests are made, but I don't get the chance > to look through them very often. > > ~Jack > > On Sat, Aug 15, 2020 at 9:31 PM Curtis Ullerich <curtuller...@gmail.com> > wrote: > >> Makes sense; thank you for the details. A more restricted sense of >> importing than normal sporking might be good, like only allowing importing >> of class and method definitions. Pre-constructor class code makes that a >> little messier. >> >> By the way, does anyone get notified when new pull requests are made on >> the ChucK repo, or should I be tagging someone? >> >> On Fri, Aug 14, 2020 at 9:01 AM Jack Atherton <l...@ccrma.stanford.edu> >> wrote: >> >>> I think this is an artifact of the type checker. It will run on a single >>> file before any of the lines in the file are run. So, if you're trying to >>> use a class that's only being imported with a Machine.add declaration, that >>> declaration is not going to run before the type checker gets to the line >>> where you use it. But, if a file has two Machine.add declarations, then the >>> type isn't used in that file, so the type checker doesn't complain, then at >>> runtime the first .add is run, followed by the second. >>> >>> I guess a Machine.import would need to compile and run the file during >>> compile time, which might be non-trivial because I'm not sure that the >>> compiler can be gracefully interrupted. Maybe the "import" keyword is the >>> way to go. This might be straightforward to do by adding a few rules to the >>> grammar and making import be a reserved word, and allow a number of import >>> statements (only?) at the top of of a program. >>> >>> I have definitely faced the same issue when I was working on utility >>> classes. >>> >>> ~Jack >>> >>> On Sat, Aug 8, 2020 at 11:46 AM Curtis Ullerich <curtuller...@gmail.com> >>> wrote: >>> >>>> Thanks for confirming. I subscribed to the issue in case it gains >>>> traction. >>>> >>>> I found it curious that Machine.add used in the header of control.ck >>>> doesn't work, but it works if the libs and control.ck are >>>> Machine.added in the same file. Why is that? >>>> >>>> >>>> On Sat, Aug 8, 2020, 11:35 Michael Heuer <heue...@gmail.com> wrote: >>>> >>>>> Hello Curtis, >>>>> >>>>> In LiCK there is one big import.ck file (your second method) >>>>> >>>>> https://github.com/heuermh/lick/blob/master/import.ck >>>>> >>>>> I typically use it with two terminal windows, in one >>>>> >>>>> $ chuck --loop >>>>> >>>>> and in the other >>>>> >>>>> $ chuck + import.ck >>>>> $ chuck + other-stuff.ck >>>>> >>>>> See also >>>>> >>>>> Add namespaces and import statements >>>>> https://github.com/ccrma/chuck/issues/109 >>>>> >>>>> Cheers, >>>>> >>>>> michael >>>>> >>>>> >>>>> On Aug 8, 2020, at 12:56 PM, Curtis Ullerich <curtuller...@gmail.com> >>>>> wrote: >>>>> >>>>> What's the state of the art for imports/includes? >>>>> >>>>> If I have files lib0.ck and lib1.ck that declare public classes both >>>>> used in control.ck, I understand these to be the two options for >>>>> running them: >>>>> >>>>> chuck lib0.ck lib1.ck control.ck >>>>> >>>>> or, make another file control-main.ck: >>>>> Machine.add("lib0.ck"); >>>>> Machine.add("lib1.ck"); >>>>> Machine.add("control.ck"); >>>>> >>>>> and run it as: >>>>> chuck control-main.ck >>>>> >>>>> I thought it would work to use Machine.add("lib0.ck"); Machine.add(" >>>>> lib1.ck"); as the first line of control.ck and then just run chuck >>>>> control.ck, but the included classes are not found. >>>>> >>>>> Are these the two options, or is there another way that can support >>>>> transitive inclusion (not having to list each util file for every program >>>>> that uses them)? >>>>> >>>>> Thanks, >>>>> Curtis >>>>> _______________________________________________ >>>>> chuck-users mailing list >>>>> chuck-users@lists.cs.princeton.edu >>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> chuck-users mailing list >>>>> chuck-users@lists.cs.princeton.edu >>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>>> >>>> _______________________________________________ >>>> chuck-users mailing list >>>> chuck-users@lists.cs.princeton.edu >>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>>> >>> _______________________________________________ >>> chuck-users mailing list >>> chuck-users@lists.cs.princeton.edu >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >>> >> _______________________________________________ >> chuck-users mailing list >> chuck-users@lists.cs.princeton.edu >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >> > _______________________________________________ > chuck-users mailing list > chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > _______________________________________________ > chuck-users mailing list > chuck-users@lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
