Yeah, that is true.
proc test(foo: string) {
proc int.foo {
writeln(this);
}
writeln(foo);
}
test("bar");
This test will print out "{}" (I will file a future shortly).
The overall problem with our module system still remains though. I don't
know what the proper solution is, or even have a proposal at this point. I
did read over what some other languages are doing with their module
systems, others may find this worthwhile as well:
Python import/module system, much of this is very specific to how python
works and can be skipped:
https://docs.python.org/3/reference/import.html
Go packages spec:
http://golang.org/ref/spec#Packages
Upcoming C++ modules:
http://clang.llvm.org/docs/Modules.html#introduction
Rust module system:
http://static.rust-lang.org/doc/master/rust.html#modules
-Kyle
On 5/6/14, 8:49 AM, "Brad Chamberlain" <[email protected]> wrote:
>
>It seems to me that an additional problem with this test is that we
>consider a method named 'addr' to be at the global scope when it ought to
>be considered to be within the scope of the type on which it was defined.
>I suspect one could develop similar tests showing that this aspect of the
>implementation was a problem even without using modules and use's.
>
>-Brad
>
>
>On Mon, 5 May 2014, [email protected] wrote:
>
>> Revision: 23349
>> http://sourceforge.net/p/chapel/code/23349
>> Author: kyle-b
>> Date: 2014-05-06 00:52:15 +0000 (Tue, 06 May 2014)
>> Log Message:
>> -----------
>> Add feature request future: A more robust module system
>>
>> from use_shadows_formal.future:
>>
>> Currently the only way we have to reference another module outside of
>>the
>> current file is a 'use' statement. There are a few problems with this.
>>One of
>> the primary issues is shown in this test. We 'use' a module that
>>defines one
>> symbol (bar) inside of the procedure test. Now because we 'use' all of
>>the
>> standard modules inside of every other module, when we go to compile we
>>will
>> get an error since there is a function inside of Sys named addr that
>>will
>> shadow our formal.
>>
>> A method of allowing other modules to be used with out dumping a very
>>large
>> number of symbols into the local context should be provided. In
>>addition a
>> method to control which symbols are imported and exported is also
>>needed.
>>
>> Added Paths:
>> -----------
>> trunk/test/modules/kbrady/
>> trunk/test/modules/kbrady/use_shadows_formal.bad
>> trunk/test/modules/kbrady/use_shadows_formal.chpl
>> trunk/test/modules/kbrady/use_shadows_formal.future
>> trunk/test/modules/kbrady/use_shadows_formal.good
>>
>> This was sent by the SourceForge.net collaborative development
>>platform, the world's largest Open Source development site.
>>
>>
>>
>>-------------------------------------------------------------------------
>>-----
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find
>>out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Chapel-commits mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/chapel-commits
>>
>
>--------------------------------------------------------------------------
>----
>Is your legacy SCM system holding you back? Join Perforce May 7 to find
>out:
>• 3 signs your SCM is hindering your productivity
>• Requirements for releasing software faster
>• Expert tips and advice for migrating your SCM now
>http://p.sf.net/sfu/perforce
>_______________________________________________
>Chapel-commits mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/chapel-commits
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
