This should help with #1, #6, and #16.

I've started working on this. "raise" kinda works, but I've discovered a bug that should probably be addressed.

Aaaaaand there's a bug with Parrot where we can't throw anything but parrot;Exception itself. Throwing subclasses causes an exception to be thrown. Yes, seriously.

Talked to Whiteknight about it. He says that allowing subclasses of Exception is a goal, but an indefinite one. It may be a while. I'll try to get as far as I can with this without needing subclasses.

I have a local branch where I've been working on this. I've got a new top-level Exception Handler that prints things more like Ruby, although some annotations are missing (notably 'file' for everything), so it looks kinda funny. Also have raise a little more done and aliased fail to it

My work so far is in the iss36 branch.

Tene mentioned the idea of decoupling cardinal;Exception and packing it into a parrot;Exception as the payload. May be workable.

The plan now is to go with Tene's suggestion.

#34 is waiting-on this.

I've merged iss34 into my local iss41 branch. This is starting to get nasty. I think I'll also need to do an object model here, too.

Yeah, I'm doing #33 with this.

Happening in iss41.

#35 is waiting on this.

Need to match this diagram:

                          +------------------+
                          |                  |
            Object---->(Object)              |
             ^  ^        ^  ^                |
             |  |        |  |                |
             |  |  +-----+  +---------+      |
             |  |  |                  |      |
             |  +-----------+         |      |
             |     |        |         |      |
      +------+     |     Module--->(Module)  |
      |            |        ^         ^      |
 OtherClass-->(OtherClass)  |         |      |
                            |         |      |
                          Class---->(Class)  |
                            ^                |
                            |                |
                            +----------------+

(Classes) are metaclasses.

#37 is waiting on this.

This is being taken care of along with #41 and #34.

Happening in iss41.

#24 is waiting on this.

This should be pretty simple after #41 is taken care of. (I may end up doing it along with #41, actually.)

The code in alias.t is wrong it should be:
alias :increment :inc
That wouldn't parse either, because we don't have symbols yet, but at least it is the code that should work in the end

I expect to hit symbols after this object model thing, and maybe after exceptions.

Probably contemporaneously with the MRO.

Waiting on #43 for symbols.

I don't know why I posted such a silly comment 5 days ago. alias_method requires symbols (or strings), alias however is special syntax and does not work with symbols but with identifiers

Freeze is supposed to make an object read-only. It's broken because the sub is empty.

Need to figure out how you do that with Parrot.

Also in test:file:stat.

Well, no class methods will work until after the object model redo.

This should hopefully be easier after #33 is done.

Test 01-stmts fails as a result of this (or rather, it should fail, it does not do that at the moment in master)

Range parsing is implemented as infix:.. and infix:...; the not working with parens is a general issue with any optable stuff. Unsure how to handle this, as optable stuff is still very much magic to me.

The comment in range/new.t was outdated other than references the paren issue.

This [was] waiting on #40 for the paren fix.

Well, the paren fix is in, but there's still something wacky going on:

crb(main):001:0>puts (1..3).class
[1, 2, 3]
Null PMC access in find_method()

I think that is parsed as (puts (1..3)).class instead of puts((1..3).class), which would also mean that the object returned by puts is not the nil from NilClass but an Undef or something like that

Unfortunately both of the expressions I gave fail to parse, so I can't really test that, but the output from target=parse seems to confirm my suspicions

Ruby's MRO can be understood thusly:

Probably best to do this after #33.

#3 and #10 are waiting on this.

This is done, but is blocking on a Parrot bug: https://trac.parrot.org/parrot/ticket/909

Another option is to do our own metaclass which could maybe tie in with #33.

My work on this has been pushed as the iss34 branch.

Now waiting-on #41 for ditching P6object.

And the iss34 branch has been merged into iss41, so that's where it's happening now.

Should be able to throw an IndexError. I declared the whole hierarchy of Ruby exceptions, except Errno::*.

(Catching is slightly more difficult if you want it to be fast.)

Nope, the problems as evident in #36 will also mess with this. Awesome.

Waiting on Parrot TT#909 now.

This is caused by the leftover Perlisms from when a lot of the originating code was taken from Rakudo. Namely: implicit conversion. Ruby doesn't do it by default. So in order to fix this, here are the steps that'll be taken:

Go through and add the implicit (to_str, to_int, etc.) and explicit (to_s, to_i, etc.) methods for all the stdlib classes that declare them. Then add stuff into Object so that anything that doesn't have an explicit implicit conversion method won't convert implicitly. This'll probably break a lot of things, but it'll at least let us know where things depend on implicit conversion. Then we go through and fix those.

The second step is to implement == as Ruby does, checking for the implicit methods before attempting equality. This should fix these failures.

Moving the implicit-explicit stuff to (and now waiting-on) #32. Second step can stay here.

It is, in fact, coming through as CardinalArray().

Waiting on #34 and #35.

This is also evident in range.t

Okay. I've done some research now. Took me some time because I had to fix a bug first to even try this. .class on a Proc is "Proc()", but only if you declare it as a proc. A bare proc (literal?) is a Sub, which has no .class.

A Range is coming across as CardinalRange, though. Unsure whether the better way to fix this is to simply rename the class, or get .class to lie.

1) hll_map Sub
2) Now that Cardinal is in its own .HLL, you should be able to get rid of all the crap CardinalFoo names, because no more namespace conflicts with core parrot types.

The last issue is that it'll be appending () to the names, which I think is solveable by adding to_s to the Metaclass that other metaclasses inherit from. Then having Object.class use that.

Okay, wow. hll_mapping Sub resulted in cardinal throwing sigbus for any attempt at execution. Did I do something particularly weird here?

diff --git a/src/classes/Proc.pir b/src/classes/Proc.pir
index 0073b1f..5034529 100644
--- a/src/classes/Proc.pir
+++ b/src/classes/Proc.pir
@@ -20,9 +20,14 @@ Perform initializations and create the Proc class
 .namespace ['Proc']

 .sub 'onload' :anon :init :load
-    .local pmc cardinalmeta
+    .local pmc cardinalmeta, core_type, hll_type, interp
     $P0 = get_hll_global ['CardinalObject'], '!CARDINALMETA'
     cardinalmeta = $P0.'new_class'('Proc', 'parent'=>'CardinalObject', 'attr'=>'!block')
+
+    core_type = get_class 'Sub'
+    hll_type = get_class 'Proc'
+    interp = getinterp
+    interp.'hll_map'(core_type, hll_type)
 .end

 .sub 'get_bool' :vtable

Could be that Proc doesn't actually subclass Sub, but it still shouldn't be crashing.

Issue #27 concerns a rewrite of Proc which should help with this.

Alright, so here's the updated status:

Waiting on #27 for the Proc rewrite.
Waiting on #34 for the s/CardinalFoo/Foo/
Waiting on #35 for the "Foo()" to "Foo" thing.

Once those are done, this issue can be closed.

[]= will be done with my big assignment cleanup #23 that'll hopefully add multiple assignment and the splat operator.

This is because multiple assignment is NYI. See #23.

Issue #27 should help with this.

Issue #27 should help with this.

Issue #27 should help with this.

Largely because splat syntax hasn't been added to the parser. I'm going to try to add this to the assignment fix (#23) I'm working on.