Introducing context #74

Closed
prakashk opened this Issue Mar 22, 2013 · 16 comments

Comments

Projects
None yet
2 participants
Member

prakashk commented Mar 22, 2013

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?

Owner

stevan commented Mar 24, 2013

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.

Owner

stevan commented Mar 24, 2013

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
Member

prakashk commented Mar 24, 2013

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

Owner

stevan commented Mar 24, 2013

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

Owner

stevan commented Mar 24, 2013

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
Member

prakashk commented Mar 26, 2013

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

Owner

stevan commented Mar 26, 2013

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

Owner

stevan commented Mar 29, 2013

Prakash,

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

  • stevan
Member

prakashk commented Apr 1, 2013

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.

Owner

stevan commented Apr 3, 2013

@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
Member

prakashk commented Apr 3, 2013

@stevan: See pull request #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

Owner

stevan commented Apr 3, 2013

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

Owner

stevan commented Apr 3, 2013

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

Owner

stevan commented Apr 3, 2013

@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

Member

prakashk commented Apr 3, 2013

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

Owner

stevan commented May 2, 2013

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

stevan closed this May 2, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment