On 18/08/2012 05:10 AM, Darren New wrote:
> On 8/16/2012 4:13, Invisible wrote:
>> Does /any/ high-level language do this?
>
> Depends what you mean by "high level", but yes. Ada, C#, FORTH, a few
> others here and there.

I very much doubt that C# lets you trivially call arbitrary machine code.

>>> Can you write programs that notice your
>>> SQL schema has changed and modifies the running program to account for
>>> that?
>>
>> Since it's not possible to receive notifications for schema changes in
>> the first place, I don't see how this is feasible.
>
> You are allowed to poll. ;-)

In that case, yeah, it ought to be possible to build something that does 
this. Nobody has, but somebody could.

>> Haskell is usually distributed in source form. Partly that's because the
>> community is small, and nobody has the resources to compile their code
>> for
>> every target platform. Partly it's because most Haskell code is
>> open-source
>> anyway. But partly it's because the extant Haskell implementations
>> have very
>> poor object code compatibility.
>
> And that's the sort of thing I'm talking about. :-)

And, as I wrote in the part you snipped, this is a property of the one 
extant Haskell compiler. It's not necessarily intrinsic to the language 
itself. Somebody could write a compiler that /does/ have good object 
code compatibility. It's just that to date, it hasn't been a priority. 
There's nothing about the /language design/ that makes this impossible.

On the other hand, if you're coding in BASIC, with line numbers and all, 
then this pretty much /is/ impossible. Because BASIC is a very, very bad 
language.

>>> How elegantly does it interface to dynamic languages like javascript?
>>
>> What do you mean by "interface"?
>
> Can you invoke a javascript library as if it were written in Haskell?
> I.e., is it as easy to invoke something like javascript as it is to
> invoke something like C?

Don't you need a web browser to run JavaScript code?

Regardless, invoking JS is, in principle, similar to invoking any other 
foreign language. Once you work out how to call it, you'd need to write 
at least some trivial wrappers to get it to work, and after that it's 
pretty easy.

>> More to the point, most of the questions above aren't about the language
>> itself, they're about all the supporting infrastructure that goes with a
>> language to make it useful. While these are obviously important
>> things, they
>> aren't part of the core language.
>
> Well, if your language can't handle dynamic loading or can't handle
> object-code distribution, then these are inherent in the language. I.e.,
> if type inference is such that you have to do whole-program compilation
> for it to work, then you can't link in new code at runtime.

No.

If the /design/ of the language makes dynamic loading impossible, then 
that's a language limitation. If the current /implementation/ of the 
language does not support dynamic loading, then that's just an 
implementation limitation.

And that's what I'm saying. Most of the stuff you can't do with Haskell 
right now isn't because of poor language design. It's just that nobody 
has built the tools or libraries required to do it. Some day these 
things /could/ become possible, without changing the language.

> Not superior. Superior at various tasks.

 From what I can see, C# is superior at migrating C++ code and letting 
it integrate with old VB code...

Post a reply to this message