can we use direct ruby instaed of javascript ?

[Phillip Gawlowski]

This is incredibly cool but can you really translate any language into
machine code?

Of course. Otherwise, the code wouldn't be executed on a CPU, after all.

The question is if you can implement every feature a language has, but
that's more about how much work and workarounds you are willing to
invest (dynamic code is a touch harder, but since there's JRuby which
started before the JVM had any sort of dynamic capabilities at all..),
rather than pure ability.

See also: "Compiler" and "bytecode" or "intermediary language".

After all, a programming language is a construct, an abstraction, that
allows us to instruct computers to do Stuff(tm), without us having to
lower ourselves to the CPU's level.

The question is kind of like asking if computers can represent text,
or do substraction of irrational numbers, when all they do is binary
addition.

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

 

[Michal Suchanek]

Of course. Otherwise, the code wouldn't be executed on a CPU, after all.

And since it can execute on something as limited and poorly designed
as x86 assembly I see no reason it could not run on OMeta, whatever it
is.

Creating something worse than x86 assembly for running code might be a
sort of a challenge in itself.

Thanks

Michal

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

Accidentally went off list for a bit.

then

Presumably OMeta is as complete as x86 assembly. Quite likely it has
different set of primitives (or insctructions) but that does not mean
translating to it is any more challenging than to x86 assembly to
which all the named languages were translated already.

Ruby isn't translated to Assembly, you must interpret it.

I don't see the leak anywhere, nor do I see any reason to translate C to
JS.

The hypothesis was that you could implement *any* language. C falls within
that set. The leak is that JavaScript does not have the properties of
assembly. There is a reason you don't write systems level code with
interpreted languages, because they have very different properties. Wouldn't
implementing a systems level language in an interpreted language cause the
systems level language to lose the attributes that make it a viable choice
for such a domain?

Because some three emails back you sent the email only to me, not the list.

Hmm, seems to be because you CC'd me in your response to the ML, so when I
hit reply, gmail sent it to you instead of the list. I changed the recipient
of this one, hopefully we're back on list. You might change your client to
avoid that, it seems unlikely that I'll be the only one to do this.

 

[Phillip Gawlowski]

Ruby isn't translated to Assembly, you must interpret it.

YARV generates byte code. The byte code is interpreted by the Ruby VM.
The Ruby VM runs on an operating system. The Operating system runs on
machine code.

Ruby *can* run on machine code, or it wouldn't run at all. The
question is how many intermediary steps are needed to get it running,
and at what costs (it's generally easier, it appears, to run a dynamic
language on some sort of interpreter, if only to make an abstraction
only once).

The hypothesis was that you could implement *any* language. C falls within
that set. The leak is that JavaScript does not have the properties of
assembly.

It doesn't need them. The compiler takes care of that.

Since IE9 was just released to the general public, here's an MSDN
article on Chakra:
http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javascript-engine-in-internet-explorer-9.aspx

IE9 is a latecomer to the "compile JS" party, too. Google's V8 is one
of the first.

There is a reason you don't write systems level code with
interpreted languages, because they have very different properties. Wouldn't
implementing a systems level language in an interpreted language cause the
systems level language to lose the attributes that make it a viable choice
for such a domain?

That's a question of optimization.

Even GCC has several optimization switches; some more, some less
dangerous to apply to code.

C's whole reason of existence is that it is a higher level language
than assembly with the compiler taking care of translating the
constructs of the higher level language into something that a CPU
understands.

Hmm, seems to be because you CC'd me in your response to the ML, so when I
hit reply, gmail sent it to you instead of the list. I changed the recipient
of this one, hopefully we're back on list. You might change your client to
avoid that, it seems unlikely that I'll be the only one to do this.

Yup, back on list. Though, IME GMail doesn't change the reply-to
header (maybe it got borked somewhere).

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

 

[William Rutiser]

On 2011-04-11 5:45 AM, Michal Suchanek wrote

This is incredibly cool but can you really translate any language into
machine code?
What about languages that are completely different from machine code?
In Haskell, for example, everything happens lazily, data is immutable,
there is a complex type system. Can you really map this right to
machine code? (Or am I misunderstanding your question?)

Yes but some language features would depend on a run-time library.
The compiler-interpreter dichotomy is better thought of as a continuum.

Bill Rutiser

 

[Johnny Morrice]

Yes but some language features would depend on a run-time library.

That would be the STG machine I was talking about, which definitely
could be ported.

I'd it'd be easier to first compile Haskell into a bytecode
representation, which you make OMeta interpret. That means you could
use an existing compiler frontend. And just port the run-time library
in OMeta.

TBH for the effort if you wanted Haskell in the browser, it'd
probably be less convoluted to write a plugin. (In Haskell?)

Cheers
Johnny

 

[Johnny Morrice]

That would be the STG machine I was talking about, which definitely
could be ported.

Sorry, I'm an idiot. Had a brainfart... really you could write a naive
STG machine interpreter in OMeta, which would constitute run-time
support

Equally you could just compile it further.