Re: [q-lang-users] Executables and modules

[Albert G. <Dr....@t-...>]

se...@ge... wrote:
> I agree.  Compiling to an intermediate language, such as Objective-C,
> would be the way to go.

Or use the gcc backend directly. That gives you more control about code 
generation and optimization, and having to go through a C compile stage 
slows things down quite a bit.

> I didn't mean "dependency" as "another bothersome thing to compile"; I
> meant "dependancy" as in "something else to break".

Ah ok, I see. You certainly have a point there.

> Yes; I hadn't seen qcwrap.  If the executables didn't link to libq or
> libqint -- now, there's a thought... I suppose I could just statically
> link to libq and libqint; then I'd only have to worry about peripheral
> libraries.  Is there a way to make qcwrap "pull in" all .q dependencies
> for an application?

qcwrap doesn't wrap the source script, it wraps the byte code, so you 
don't have to worry about .q dependencies when using it. Instead of 
statically linking to libq/libqint, you could also ship the shared libs 
with your application and rely on library versions. Hmm, that reminds me 
that I forgot to increment the libqint version in Q 6.1/6.2, I'll have 
to fix that in the next release... ;-)

> Ouch.  Yeah, I forgot that.  Hrm.  I've always liked type inferrence, and
> have often wondered why dynamically typed anguages couldn't implement type
> inferrence based on duck typing.  Especially in the case of Q, which does
> perform a compilation step.  But, this is Yet Another Feature.

Well, the amount of ad-hoc polymorphism in Q is essentially unlimited, 
and you can't decide statically whether a given expression is able to 
"respond" to a given "method" (function). That means that "duck typing" 
becomes undecidable.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag