Opal - Ruby to Javascript compiler • Hacker News Board

Re: Opal - Ruby to Javascript compiler

#41

Post by vjeux » Sat, Oct 20, 2012, 5:54 AM UTC

Unfortunately their hash table uses Javascript objects. Therefore it does not behave exactly like Ruby.

Eg:

  # Opal
  h = Hash.new
  h['0'] = 1 
  h[0] = 2
  print h
  # {"0"=>2}

  # Ruby
  h = Hash.new
  h['0'] = 1 
  h[0] = 2
  print h
  # {"0"=>1, 0=>2}

It is very hard to reproduce those low level specifications without rebuilding everything from scratch sadly :(

Re: Opal - Ruby to Javascript compiler

#42

Post by [deleted] » Sat, Oct 20, 2012, 6:16 AM UTC

scott_s wrote: post #26

Scriptor wrote: post #18

Earlier quoted context omitted.

It's really not terribly complicated to figure out what it does, here's the formatted version for adding two numbers (function() { var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice; var __a, __b; return self.$puts((__a = 1, __b = 2, typeof(__a) === 'number' ? __a + __b : __a['$+'](__b))) })(); The first line just declares some Opal-specific va…

I agree that it's reasonable. Consider this C program: int main() { return 4 + 2 + 5 + (19 + 3 * 4) - 8 / 10; } Becomes the following assembly: .section __TEXT,__text,regular,pure_instructions .globl _main .align 4, 0x90 _main: Leh_func_begin1: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: movl $42, -8(%rbp) movl -8(%rbp), %eax movl %eax, -4(%rbp) movl -4(%rbp), %eax popq %rbp ret Leh_func_end1: Yes, that's going from "hi…

[deleted]

Re: Opal - Ruby to Javascript compiler

#43

Post by goggles99 » Sat, Oct 20, 2012, 11:09 AM UTC

Can't those standards committees just do something right for once and create a standard for a vm that will run in the browser (a la Dartium)? Stop this monopoly and oppression of innovation!!!

Re: Opal - Ruby to Javascript compiler

#44

Post by denysonique » Sat, Oct 20, 2012, 11:29 AM UTC

jonny_eh wrote: post #2

While very impressive it makes me nervous. The JS it outputs just in the basic tutorial looks extremely complex, I'd hate to debug that code! Compare with CoffeeScript, where the output is quite easy to follow, and therefore debug.

OpalScript is going to solve this problem

Re: Opal - Ruby to Javascript compiler

#45

Post by lucian1900 » Sat, Oct 20, 2012, 11:31 AM UTC

dyscrete wrote: post #16

It's a great idea, but it seems ridiculous how even simple arithmetic gets translated to an unreadable mess of javascript. puts 4 + 2 + 5 + (19 + 3 * 4) - 8 / 10 translates to: (function() { var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice; var __a, __b, __c, __d, __e, __f, __g, __h; return self.$puts((__a = (__c = (__e = (__g = 4, __h = 2, t…

It makes sense, considering JS's silly coercion rules and overflow, which don't match Ruby's.

Re: Opal - Ruby to Javascript compiler

#46

Post by lucian1900 » Sat, Oct 20, 2012, 11:32 AM UTC

vjeux wrote: post #41

Unfortunately their hash table uses Javascript objects. Therefore it does not behave exactly like Ruby. Eg: # Opal h = Hash.new h['0'] = 1 h[0] = 2 print h # {"0"=>2} # Ruby h = Hash.new h['0'] = 1 h[0] = 2 print h # {"0"=>1, 0=>2} It is very hard to reproduce those low level specifications without rebuilding everything from scratch sadly :(

ECMA5 has real maps, which Opal could use. Some browsers support them already.

Re: Opal - Ruby to Javascript compiler

#47

Post by jhrobert » Sat, Oct 20, 2012, 12:34 PM UTC

They lost me at the "nil" section.

RubyScript is what we need => efficient code, à la coffeescript, with a Ruby syntax.

There is some impedance mismatch between ruby & javascript semantics. Trying to hide this fact has a cost in terms of performance.

I would love to have some ruby syntax as long as it does not compromize the speed of my code.

There is a trend these days where syntax and semantics are becoming orthogonal, that's nice.

Hence GoScript, PascalScript, PrologScript, CppScript, SmallScript...

Thanks to sourcemaps the issue of the generated code readability has disappeared. Only the performance matters from now on.

Re: Opal - Ruby to Javascript compiler

#48

Post by dbaupp » Sat, Oct 20, 2012, 12:36 PM UTC

btilly wrote: post #40

omaranto wrote: post #38

Earlier quoted context omitted.

I think IEEE doubles can represent up to 53 bit integers exactly. (Someone here will know if that's true.)

Gah, the website ruined what I was typing. I meant 2 to the power of 100. Which is a 100 bit integer, and certainly not correctly calculated in JavaScript.

While your general point is correct, the details aren't. Powers of 2 are represented exactly in floating point (for any number, only the 53 most significant bits can be stored). So 2^100 + 1 is an example of something that's non-representable in JS.

Re: Opal - Ruby to Javascript compiler

#49

Post by mossity » Sat, Oct 20, 2012, 3:45 PM UTC

doktrin wrote: post #35

Being relatively new to cross-language compilation, how are one language's class APIs typically translated into another? For example : [1,2,3].shuffle [turns into] => (function() { var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice; return [1, 2, 3].$shuffle() })(); Of course, since JS arrays do not have a "shuffle" method, the output reads : T…

Could probably also include something like Sugar.js or Underscore.js that tries to bring a lot of the missing syntactic sugar to JS.

Re: Opal - Ruby to Javascript compiler

#50

Post by SilasX » Sat, Oct 20, 2012, 4:02 PM UTC

jhrobert wrote: post #47

They lost me at the "nil" section. RubyScript is what we need => efficient code, à la coffeescript, with a Ruby syntax. There is some impedance mismatch between ruby & javascript semantics. Trying to hide this fact has a cost in terms of performance. I would love to have some ruby syntax as long as it does not compromize the speed of my code. There is a trend these days where syntax and semantics are becoming orthogo…

>RubyScript is what we need => efficient code, à la coffeescript, with a Ruby syntax.

Why not make a Ruby -> Coffeescript compiler, since they're a lot closer in the first place?