Can we use direct ruby instaed of javascript?

Ruby
21

On Apr 8, 2:02pm, Ryan D. [email protected] wrote:

On Apr 8, 2011, at 01:34 , Julian L. wrote:

Just wondering if this is a possibility? :slight_smile:

No. You want python or (gulp) applescript.

AppleScript was my first thought, and this “of” stuff is quite
possibly what I hate the most about trying to do anything in that
language.

22

On Mon, Apr 11, 2011 at 11:45 AM, Michal S. [email protected]
wrote:

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”. :wink:

After all, a programming language is a construct, an abstraction, that
allows us to instruct computers to do Stuff™, without us having to
lower ourselves to the CPU’s level. :wink:

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. :wink:

–
Phillip G.

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.

23

On 8 April 2011 15:03, Josh C. [email protected] wrote:

language for a VM in Ruby, while incredibly technically challenging, is that
Just my two cents.
for example, everything happens lazily, data is immutable, there is a
complex type system. Can you really map this right to javascript? (or am I
misunderstanding OMeta?)

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?)

Thanks

Michal

24

Accidentally went off list for a bit.

On Mon, Apr 11, 2011 at 7:55 AM, Michal S.
[email protected]wrote:

wrote:

complex type system. Can you really map this right to javascript?
In Haskell, for example, everything happens lazily, data is
question. In the video, he didn’t translate to machine code, he

assembly
these

inherently. You could construct a framework that mimics a computer, and
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.

linker, after the code is translated. (I’m not clear on the difference
but is actually JS, and your final code is actually a whole series of
indirect JS commands) So if this is the case, you have a leaky
abstraction
(The Law of Leaky Abstractions – Joel on Software)

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?

Also, why are we off list?

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.

25

On 11 April 2011 12:34, Phillip G. [email protected]
wrote:

On Mon, Apr 11, 2011 at 11:45 AM, Michal S. [email protected] wrote:

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.

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

26

On Mon, Apr 11, 2011 at 3:17 PM, Josh C. [email protected]
wrote:

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 G.

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.

27

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

28

On Tue, 12 Apr 2011 01:53:26 +0900
Johnny M. [email protected] wrote:

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.

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.

29

On 2011-04-11 5:45 AM, Michal S. 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