 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2012 7:34, Warp wrote:
> Darren New<dne### [at] san rrcom> wrote:
>>> Even if it does, then the language could implicitly do with it what C++'s
>>> virtual inheritance does. You can still forbid all other types of diamond
>>> inheritance if you so wish.
>
>> You could, but then it's getting weird.
>
> What would be weird about it?
What about diamond inheritance from Number or Enum or something like that?
There would be a bunch of cases where you could reasonably expect diamond
inheritance to work, or where there's one class under Object which is
nothing but some extra routines you want all *your* classes to inherit.
I.e., it's a very ad hoc rule that tells the programmer that the language
designer didn't know how to solve the problem but recognized it needed
solving. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/08/2012 05:34 AM, Darren New wrote:
> On 8/16/2012 3:14, Invisible wrote:
>> According to Wikipedia, Mono /also/ does JIT compilation to native code.
>> (Although I agree it would be better if there were published benchmark
>> results for .NET itself.)
>
> You almost have to. But the GC and the JIT for Mono both suck compared
> to the ones optimized by MS.
You have an actual citation for that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/08/2012 05:14 AM, Darren New wrote:
> On 8/16/2012 4:13, Invisible wrote:
>> Similar remarks go for most of your points. There are languages like
>> Erlang
>> where support for distributed processing is built-in. Haskell is not
>> such a
>> language.
> But that's not all it takes to make it do what Erlang does. Erlang isn't
> just "distributed processing." It's "reliable processing." Which means
> you need to be able to (for example) start a new version of the code
> running while not actually throwing away the stack of call frames that
> got you there
> How would you write a Haskell library that says "once each call to X
> returns, replace that thread's version of X with new executable code,
> without otherwise disturbing the thread that's running there"?
You wouldn't be able to do this for arbitrary code. But if you insert a
suitable layer of indirection, it wouldn't be too hard. Haskell supports
first-class functions, after all. You can do crazy things with stuff
like continuation-passing and so on.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/18/2012 3:14, Orchid Win7 v1 wrote:
> I very much doubt that C# lets you trivially call arbitrary machine code.
You would be mistaken. It's no harder in C# to call COM or C code than it is
to do so from C++. Machine code? Well, you have to know the calling
convention, but sure, you can do that.
> In that case, yeah, it ought to be possible to build something that does
> this. Nobody has, but somebody could.
OK, so Haskell supports dynamic loading of code including declaring new
types? Funky.
> 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.
Sure. But some systems are designed to make this easy, and some aren't. For
example, it's a lot harder to write a C# compiler that does *not* have good
object code compatibility.
Of course any language can manage pretty much any function with enough
effort. Even BASIC can have good object-code compatibility if you work hard
enough at it. (I think they call it VB.NET, ;-) The question is how much
effort does it take, and how much does it look like part of the language
when you're done.
>>>> 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?
Why would you need a web browser?
> 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.
Except that JS is dynamically-typed. So you can't write a wrapper to a JS
function. Plus, of *course* you *can* manage it. It's turing complete and
runs on the same machine. The point is whether it's easy to take a lazy
functional declarative language and conveniently invoke a stateful
dynamically-typed collection of functions and objects. I can't even imagine
how you'd write a wrapper for something like that, in terms of declaring it
and invoking it. I.e., I don't even know how you'd be able to write a
Haskell declaration of a javascript object, even assuming such library was
already written.
> 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.
OK. It wasn't obvious to me that the design of the language was such that
you could have the things I was talking about.
>> 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...
You barely even know how it works, and you've not written any significant
programs in it, so you're judging from a position of ignorance. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/18/2012 3:17, Orchid Win7 v1 wrote:
> You wouldn't be able to do this for arbitrary code.
And that's what I'm talking about. If you want your program to run 15 years
without ever stopping, you pretty much need to be able to replace arbitrary
bits of code, including type signatures, while you're running.
> But if you insert a
> suitable layer of indirection, it wouldn't be too hard. Haskell supports
> first-class functions, after all. You can do crazy things with stuff like
> continuation-passing and so on.
Sure, and Erlang translates into machine code instructions at some point. Or
hell, implement an Erlang interpreter in Haskell. This isn't an argument. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/18/2012 3:03, Orchid Win7 v1 wrote:
> On 18/08/2012 05:34 AM, Darren New wrote:
>> On 8/16/2012 3:14, Invisible wrote:
>>> According to Wikipedia, Mono /also/ does JIT compilation to native code.
>>> (Although I agree it would be better if there were published benchmark
>>> results for .NET itself.)
>>
>> You almost have to. But the GC and the JIT for Mono both suck compared
>> to the ones optimized by MS.
>
> You have an actual citation for that?
First google hit on "mono gc sucks"
http://phoronix.com/forums/showthread.php?26300-Mono-2-8-Is-Out-With-C-4-0-Better-Performance/page15
Later versions of Mono are much better than the first few generations, which
sucked so bad they realized they actually needed to fix it to be even usable
let alone competitive.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You wouldn't be able to do this for arbitrary code.
>
> And that's what I'm talking about. If you want your program to run 15
> years without ever stopping, you pretty much need to be able to replace
> arbitrary bits of code, including type signatures, while you're running.
And if this was a problem for your application, you would write it in
such a way as to facilitate doing this.
Yes, it would be cooler if you could do it for /arbitrary/ code, but
with extant implementations, you'd have to do the next best thing.
(And, again, if somebody wanted this, you could probably come up with a
Haskell implementation that supports it natively. It's just that nobody
has. It would take some design work, but I think you could do it without
changing the language itself.)
>> But if you insert a
>> suitable layer of indirection, it wouldn't be too hard. Haskell supports
>> first-class functions, after all. You can do crazy things with stuff like
>> continuation-passing and so on.
>
> Sure, and Erlang translates into machine code instructions at some
> point. Or hell, implement an Erlang interpreter in Haskell. This isn't
> an argument. :-)
Implementing an Erlang interpreter in BBC BASIC would be hellishly
difficult. Doing it in Haskell wouldn't be all that hard. That's the
difference.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/08/2012 06:43 PM, Darren New wrote:
> On 8/18/2012 3:14, Orchid Win7 v1 wrote:
>> I very much doubt that C# lets you trivially call arbitrary machine code.
>
> You would be mistaken. It's no harder in C# to call COM or C code than
> it is to do so from C++. Machine code? Well, you have to know the
> calling convention, but sure, you can do that.
It's no harder to call C than to call Haskell, once you define where the
hell the function is and what arguments it's expecting. Your point?
>> In that case, yeah, it ought to be possible to build something that does
>> this. Nobody has, but somebody could.
>
> OK, so Haskell supports dynamic loading of code including declaring new
> types? Funky.
It's commonplace to write Haskell code which doesn't know exactly what
data types it's dealing with. Dynamically loading new types that didn't
exist at compile-time isn't really a problem, in principle. The only
real problem is that the current language implementation doesn't support
this well.
>> There's nothing about the /language design/ that makes this impossible.
>
> Sure. But some systems are designed to make this easy, and some aren't.
Fair enough.
> Of course any language can manage pretty much any function with enough
> effort. Even BASIC can have good object-code compatibility if you work
> hard enough at it. (I think they call it VB.NET, ;-)
VB isn't BASIC. VB is a language with a very slight resemblance to
BASIC, which has "basic" in its name. Really, it's an utterly separate
language.
And that's the point - any language can be made to support anything if
you TOTALLY CHANGE THE LANGUAGE. The question is whether you can do X, Y
or Z /without/ drastically changing the language.
> The question is how
> much effort does it take, and how much does it look like part of the
> language when you're done.
OK.
>> Don't you need a web browser to run JavaScript code?
>
> Why would you need a web browser?
JavaScript is a language invented for controlling web browsers. I don't
know of anything else that runs it.
> Except that JS is dynamically-typed.
And Haskell can't manage dynamically-typed code.
Oh, wait. Yes it can.
> The point is whether it's easy to take a
> lazy functional declarative language and conveniently invoke a stateful
> dynamically-typed collection of functions and objects. I can't even
> imagine how you'd write a wrapper for something like that, in terms of
> declaring it and invoking it.
"I can't imagine how this would be possible" isn't the same as "this is
not possible", as everyone is so fond of reminding me.
>> From what I can see, C# is superior at migrating C++ code and letting it
>> integrate with old VB code...
>
> You barely even know how it works, and you've not written any
> significant programs in it, so you're judging from a position of
> ignorance. :-)
I said that the design is overly complicated and cluttered. That it
lacked simplicity and elegance. Why would I need an encyclopaedic
knowledge of the language to say that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/19/2012 3:26, Orchid Win7 v1 wrote:
> On 18/08/2012 06:43 PM, Darren New wrote:
>> On 8/18/2012 3:14, Orchid Win7 v1 wrote:
>>> I very much doubt that C# lets you trivially call arbitrary machine code.
>>
>> You would be mistaken. It's no harder in C# to call COM or C code than
>> it is to do so from C++. Machine code? Well, you have to know the
>> calling convention, but sure, you can do that.
>
> It's no harder to call C than to call Haskell, once you define where the
> hell the function is and what arguments it's expecting. Your point?
I'm not following. You said C# doesn't let you call machine code. I said it did.
And if Haskell tends to use things like lists extensively, or options, or
something like that, then yeah, it can be hard to pass such things across
computation boundaries, let alone lazy expressions. And of course if the C
isn't actually a function in the functional sense, I'm not sure how Haskell
handles it. For example, it's really not obvious how easy it would be to
invoke a C function that takes as one of its arguments a pointer to a function.
Note I'm not bashing Haskell. I'm simply pointing out the assertion that
Haskell does everything as well as every other language doesn't sound right
to me.
> It's commonplace to write Haskell code which doesn't know exactly what data
> types it's dealing with. Dynamically loading new types that didn't exist at
> compile-time isn't really a problem, in principle. The only real problem is
> that the current language implementation doesn't support this well.
OK, cool.
> VB isn't BASIC. VB is a language with a very slight resemblance to BASIC,
> which has "basic" in its name. Really, it's an utterly separate language.
Well, it's not Dartmouth basic, no. :-) But I was mainly kidding there.
>>> Don't you need a web browser to run JavaScript code?
>>
>> Why would you need a web browser?
>
> JavaScript is a language invented for controlling web browsers. I don't know
> of anything else that runs it.
There are lots of other applications that have incorporated javascript. For
example, MongoDB interprets javascript to decide how to do queries and build
indexes.
http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions
And have you not heard of node.js?
>> Except that JS is dynamically-typed.
> And Haskell can't manage dynamically-typed code.
> Oh, wait. Yes it can.
OK. Again, I didn't know that. I thought Haskell is statically typed.
>> The point is whether it's easy to take a
>> lazy functional declarative language and conveniently invoke a stateful
>> dynamically-typed collection of functions and objects. I can't even
>> imagine how you'd write a wrapper for something like that, in terms of
>> declaring it and invoking it.
>
> "I can't imagine how this would be possible" isn't the same as "this is not
> possible", as everyone is so fond of reminding me.
I didn't say it's impossible. I said I can't imagine it. :-)
So how do you do it?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
