On Sun, 2016-09-04 at 22:11 +0000, Brad Chamberlain wrote: > Hi Russel -- > > > Depending on what filenames you use, an explicit 'module' declaration > may never be needed. Some cases where one might opt to use one > include: > > > * when implementing multiple versions of the same module using > distinct files and wanting all the versions to have a consistent name > in spite of potentially differing filenames.
I assume only one of the files is selected at any one time, which I
guess is implied by the "multiple versions" :-), otherwise there will
be compilation problems, name conflicts. I guess use of SCons, CMake,
Make allows this easily. Will Mason if it is a compilation manager as
well as dependency resolver?
>
> * when a filename, due to some other convention, contains symbols
> that are not part of a legal identity. E.g., if my file is called
> 'foo-brad.chpl', I can't type 'use foo-brad;' in my code because '-'
> means subtraction. So I could use a 'module foo { ... }' declaration
> within my code to give it a different name or avoid such filenames.
Those coming from a Java (and Kotlin, Ceylon, Groovy, Scala), D, and
Python background will be used to having file name restrictions
determined by the language syntax. So I suspect those people will have
no problems with the "file as module, module as file" and no module
statement approach.
I suspect the reaction of many to the above situations will be "just
change the filename, what's the problem". ;-)
I think I would emphasise the file as module, and treat the module
statement as a sophistication for those people who know they need it.
Ockham's Razor, KISS, and all that.
>
> -Brad
>
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
_______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
