Quick 2 cents:
- I like the 'require' idea for behaving as if the argument were added to
the command line (for some file types - I'm not saying you should be able
to require "--fast" but maybe that would be fun for some people)
- I'd like to see 'require' also support .chpl files, and in that case,
work as a non-importing use. That is, it would cause the .chpl file to be
read in and compiled - and the functions etc available through the
ModuleName.symbol syntax but not imported directly
- require'ing a C header file seems to me to be doing something a bit
different - since it makes the header file symbol names available to the C
compiler later... so it's importing it into a scope in the C compilation
but not into the Chapel compiler's scope. Should you 'use' a C header file
and 'require' a C source or object file?
-michael
On Tue, Feb 17, 2015 at 4:40 PM, Brad Chamberlain <[email protected]> wrote:
>
> >> Are there cases other than Microsoft's .lib/.dll that you're thinking
> of?
> >
> > Yup, OSX uses .dylib for shared libraries and .a for static. Building our
> > GMP gives me libgmp.dylib for example.
>
> OK, thanks.
>
>
> > I guess this is more what I meant. I think it could be unfortunate to
> > require this capability in the the language. I see compiling extra
> > C/whatever as the job of a Makefile, not Chapel. Users could still create
> > a static lib that they then use in a require statement.
>
> What if we think of it less as a language change and more as an extension
> that's supported by our compiler in support of libraries. I worry about
> the level of pain of using external libraries without some sort of feature
> along these lines (again, FFTW being the example that's motivating me at
> present, but it feels reminiscent of things we've wrestled with when
> supporting re2, gmp, etc.).
>
>
> > Actually... thinking about it, it may not be too bad
> > - we already need the extern declarations in the Chapel source. What
> would
> > stop us from just putting those as extern declarations in the C code?
>
> I think there are a few problems with this approach...
>
> One is merely philosophical -- it seems unwise/unsafe to think we know
> what C prototype to generate better than the C library writer. If we get
> something wrong (say, use 'int' rather than 'c_int'), we end up lying
> about the interface in a way that's likely to break in ugly ways.
>
> Another is technological -- we would presumably need a way in Chapel to
> express every possible prototype in C, which we can't do today. There is
> a mode in which one can ask the Chapel compiler to emit prototypes for
> external routines, and in practice it generates lots of warnings because
> of minor differences like const-ness, etc.
>
> The third is a convenience factor. I think it's really nice that one can
> interoperate with C in ways that are very productive in Chapel, like:
>
> extern proc printf(x....);
>
> rather than having to specify exactly what the signature of printf() is.
> It seems a shame to throw away this capability to me -- it's very useful.
>
> -Brad
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
