Introducing context

[prakashk]

I have made a small attempt at introducing context while evaluating expressions. This makes it possible to evaluate expressions like "2" + 4 which are not possible currently (since StrClass does not have an infix:<+> method).

As an experiment, I have only made changes to implement this in a binary addition/subtraction case for StringLiterals. I am not sure if this is the right approach/right implementation.

Can someone please review the change in the prakashk/context-attempt branch?

[stevan]

Prakash,

I will review this tonight.

Thanks,

• Stevan

On Mar 22, 2013, at 5:41 PM, Prakash Kailasa notifications@github.com wrote:

I have made a small attempt at introducing context while evaluating expressions. This makes it possible to evaluate expressions like "2" + 4 which are not possible currently (since StrClass does not have an infix:<+> method).

As an experiment, I have only made changes to implement this in a binary addition/subtraction case for StringLiterals. I am not sure if this is the right approach/right implementation.

Can someone please review the change in the prakashk/context-attempt branch?

— Reply to this email directly or view it on GitHub.

[stevan]

Prakash,

Actually had a moment to review it, I commented on one of your commits, I would be interested to know why you felt that was needed.

As for the contexts, I think you have something here but I am not 100% sure I like the way in which you approached it. I will ponder it today and get back to you later.

• Stevan

[prakashk]

Stevan,

I changed the implementation slightly using Scala's Option[] type (now I don't have the ugly MoeNoContext case as the default), but I will wait until your further comments, before I push it.

Re: the other refactoring change, it was not needed for contexts at all. That change just happened to be in the same branch and got pushed along with the other changes. I thought it made it cleaner by eliminating repeated code.

Thanks, Prakash

[stevan]

Prakash,

Re: the other refactoring change.

I am fine with removing the duplicated code, but I would prefer to put that code into a utility function inside Interpreter rather then move it into MoeObject. You will forgive my misleading comment on the commit itself, I have not been able to work on Moe for a little because of my work $work. The reason why I backed out of this change originally was because I was trying very hard to not throw exceptions in the runtime objects and therefore centralize all error generation and handling inside the interpreter.

Stevan

[stevan]

Prakash,

So regarding the coercions that you are doing via the contexts, a couple of thoughts.

First, I was hoping to make Moe stricter then regular Perl 5 and not have all the implicit conversions that Perl 5 has. This is part of the whole "subset" philosophy.

Second, because I know that can be tedious and somewhat unperlish, I was planing to (again) borrow from Perl 6 here and use the coercion operators. You can read about them here. Under the hood they basically just call the .Typename method (they discuss it in the first answer on this page).

This is all still theory of course, right now my primary focus (once work $work is out of the way and I have some time) is fleshing out the MoeSignature, MoeArgument and MoeParameter objects (which are in need of some work). That said if you wanted to do some reading on the Perl 6 stuff I linked to above, I would be happy to discuss things with you.

Thanks again for all the work you've been putting into Moe, I very much appreciate it.

• Stevan

[prakashk]

Stevan,

I read the linked articles and the relevant Perl6 synopsis: Summary of Perl 6 Operators.

Couple of issues:

• Perl6 does implicit conversion from Str to Int in case of most operators (+ - * / ** +& +< +> gcd lcm .., and may be others) and does not convert in case of two operators (div and mod). Asking in #perl6 why these two operators were designed so didn't get me more than "to give more options". Do we want to the same thing in Moe?
• Perl6 offers several explicit coercion operators. We should have at least three of those in Moe to begin with: ? (boolean context), + (numeric context) and ~ (string context). The only issue here is the symbol used for string coercion. Perl6 uses ~ here, because that is also the string concatenation operator, instead of the . used by Perl5. Using ~ in Moe would mean not supporting the bitwise negation operator. Using . would result in ambiguity (.2 could mean "2" or 0.2). How do we resolve this?

Thanks, Prakash

[stevan]

Prakash,

Just FYI, I have just pushed code to handle optional and slurpy parameters, this caused some tests in SimpleExpressionStrTestSuite to fail so I commented them out, however they are tests which could be solved by the context stuff you are working on.

I want to also fixup the MoeArrayObject tests to use the slurpy params, at which point I will be ready to dive into this context stuff.

Stevan

[stevan]

Prakash,

Okay, I am convinced of your contexts approach, I will start hacking it in tonight.

• stevan

[prakashk]

Stevan: Check out the branch prakashk/explicit-coercion-with-dot-moe which is based on the dot-moe branch.

The branch prakashk/explicit-coercion has the same functionality, but is based on master and uses . for stringification.

[stevan]

@prakashk looks great, please submit a pull request (keep in mind that I just pushed a bunch of basic changes to master and dot-moe (none of which should affect this patch, but you never know))

As always, thanks.

• Stevan

[prakashk]

@stevan: See pull request https://github.com/MoeOrganization/moe/pull/75 for changes in prakashk/explicit-coercion branch.

Do you want me to submit another pull request for the dot-moe branch as well? What is the status of that branch?

Thanks, Prakash

[stevan]

@prakashk I am merging in #75 right now. As for the dot-moe branch, I haven't decided what to do about that yet.

[stevan]

@prakashk I merged this into the dot-moe branch and changed the string operator to ~

[stevan]

@prakashk I just replaced master with the dot-moe branch based on some conversations we had in the #moe IRC channel. I did it as a forced update, so it might have messed up your history, sorry

[prakashk]

@stevan: I noticed. BTW, I am sahadev on #moe.

[stevan]

I think this is complete enough that we can close the issue.