[chuck-users] imports/includes

Wed Aug 19 21:26:37 EDT 2020

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 <heuermh at gmail.com> wrote:

> On Aug 19, 2020, at 12:25 PM, Jack Atherton <lja at 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 <curtullerich at 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 <lja at 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 <curtullerich at 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 <heuermh at 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 <curtullerich at 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 at lists.cs.princeton.edu
>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> chuck-users mailing list
>>>>> chuck-users at lists.cs.princeton.edu
>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>>
>>>> _______________________________________________
>>>> chuck-users mailing list
>>>> chuck-users at lists.cs.princeton.edu
>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20200819/5f8ff5ef/attachment.html>