moeorganization/moe

An -OFun prototype of an Ultra Modern Perl 5

moe's Issues

Don't include jars in project

It would be better to include the scalatest jar via a dependency in build.sbt.

For example, something like:

name := "moe"

version := "0.0.1"

scalaVersion := "2.9.2"

libraryDependencies += "org.scalatest" %% "scalatest" % "1.9.1" % "test"

Hope this helps!

Make MoeClass.getFullyQualifiedName work properly

This should actually be able to find the enclosing package and produce the fully qualified name.

Add support for $?SUB and $?METHOD

These should point to the appropriate runtime objects inside the executing body of the sub or method.

request: a PLAN doc containing more specifics about project goals

I think it would be useful if the project had a PLAN.md file containing sections something like:

• primary general project goals with some details (AST, MOP, etc.)
• Perl 5 features/functions/isms most likely to be dropped/not-implemented
• planned incompatible syntax/semantics changes from Perl 5
• new language features/additions planned for Moe

Add support for &?ROUTINE

See also Sub::Current and the Perl 6 spec.

Add support for topic variable ($_) in some Array operations

The topic ($_) should automatically be available in certain Array operations. That way we can do this:

@a.map(-> { $_ + 2 });

rather than having to do this

@a.map(-> ($x) { $x + 2 });

convert the tests to use ShouldMatchers

The org.scalatest.matchers.ShouldMatchers trait adds some really useful methods to make testing easier and nicer to look at. There are a number of vanilla assert tests which could be improved by this.

Add support for __DATA__

This means also having file-handle like objects that are not backed by java.io.File

Improve "unless" support

We had a nice refactor done of the If statement, but the Unless statement still could use some work.

Add support for __END__

Basically just tell the parser to stop

More Interpreter tests

When adding interpreter features I am testing the bare minimum to make sure it works so I can move on to the next interpreter feature. We could use way more tests for edge cases and things like that to ensure robustness.

Add editline support to the REPL

Currently there is no line editing or history support in the REPL. There are a number of libraries out there, JLine looked to be the simplest and most featureful, however it wasn't so simple to just use it because sbt also uses JLine and so the two collide when used together.

Add regular expression support

We do not have any notion of regular expressions in Moe yet, we need to add support for that.

Add support for "return" keyword

Exactly what it says on the tin, currently we only support the last evaluated statement, but would be nice if we had a proper return keyword as well.

Get rid of the class "sigil"

I added the class sigil (^) because I could not get the parser to parse bare words successfully, it is fine for now, but it should ultimately be removed

Convert examples in spec/ to test in t/

There are a bunch of examples in the spec/ directory, many of which are outdated and wrong. Ideally we can go through them and convert them into tests in t/ (correcting them along the way of course).

create nativeObject for IO

Need look to see what Scala has that we can use for this, I suspect this will be a little more complex then the other native objects though

Parser support for "for" and "foreach" statements

Currently the parser doesn't know how to do for and foreach statements, we should fix this.

Bind MoeExceptions with NativeObject exceptions

Once Issue #35 is done, we need a way to bind the MoeException hierarchy to a NativeObject exception. This can likely be done by making the MoeErrors object into a factory (using the apply method).

Introducing context

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?

Improve handling of ranges in the parser and interpreter

The way ranges are handled in the parser is not ideal, currently it only supports Integers and can only parse literals and variables.

Here is the parser code:

https://github.com/MoeOrganization/moe/blob/master/src/main/scala/org/moe/parser/Expressions.scala#L43

And here is the interpreter code:

https://github.com/MoeOrganization/moe/blob/master/src/main/scala/org/moe/interpreter/Interpreter.scala#L139

Improve separation of compile and evaluate phases

It would be nice to be able to completely evaluate the AST, perform all compile time actions (class declaration, sub declaration, etc) and then return a smaller tree with just the items needed to be evaluated.

Take a first stab at some parser bits

See here for a good implementation example.

add eval_lives_ok and eval_throws_ok to Test::More

We need a way to eval code in a test to make sure it works. Refer to the Perl 6 test suite to see how this is done.

Review and tighten up Error handling in the Interpreter

In the runtime-improvements branch we have removed all error throwing out of the org.moe.runtime namespace in favor of using the Option. This means that the interpreter needs to watch out for missing data (in the form of None) and throw the appropriate error.

Track file and line information in AST

Need to track the file and line information in the AST nodes. Need to figure out how to extract that from the Parsers.

Fix how default values are handled in MoeAttribute

This is not even really doing anything. The default value really needs to be cloned for each instance.

Bootstrap the MetaModel

We need to provide a runtime layer over the MetaModel (MoeClass, MoeAttribute, etc).

Allow for default values on parameters

A parameter can have a default value, which is in the form of:

sub foo ( bar = 10 ) { ... }

This is related to Issue #45, #46 and #47

Add support for statement modifiers

Would be great to have the Perl style statement modifiers like

return $x if $y;

also, foreach and while would be good too.

Namespace squatting

moe.org is already a registered domain name (which does not belong to stevan).

I wish I could recommend registering moe.pl in Poland, but that's taken too.

MoeMethod needs to handle parameters

This should try and follow the p5-mop method spec.

Remove the need for semicolons on assignment statements

Assignment statements require semicolons, even if they aren't actually needed (last statement in a block, etc.). This is mostly just cause the parser needs a lot of help, but if we could at least fix this it would be helpful.

org.moe.interpreter.guts.Utils.walkAST is not complete

The walkAST sub has not been kept up to date, it needs a number of nodes added to it.

Rename "Null" to "Undef"

This better matches with Perl 5's nomenclature

Interpreter should not be a singleton

Ideally we only have one singleton, and that would be org.moe.Moe and it should hold an instance od MoeInterpreter and MoeRuntime.

Convert assignment AST nodes to BinaryOp nodes for "="

We have all sorts of nodes for assignment, we need to turn these into BinaryOp nodes for the = operator.

add support for exiting the REPL

The REPL should support some kind of exiting other then just ctrl-c

Make Str, Int and Num all immutable

This falls under the "what would Perl 6 do" umbrella. This means removing the increment operators (people can use regular old addition instead), and making Str.chop and Str.chomp return new strings rather then alter in place. This will remove all usage of MoeNativeObject.setNativeValue except for Array.bind_pos, which uses it to autogrow the array size (should look in the docs and see if this can be done another way).

Learn scaladoc-ing and do more docs in src/

Read:

https://github.com/MoeOrganization/moe/blob/master/src/main/scala/org/moe/runtime/MoeClass.scala

https://github.com/MoeOrganization/moe/blob/master/src/main/scala/org/moe/runtime/MoeAttribute.scala

See scaladoc:

https://wiki.scala-lang.org/display/SW/Scaladoc

Is this project really Ultra Modern Perl 5?

Is this project really Ultra Modern Perl 5?

It looks like sister language like perl 6.
I don't deny your project, but some people think moe is perl5 reimplementation + α.

If you don't use perl5 syntax, i think this project isn't Ultra Modern Perl 5 because this don't has backkword compatible to perl5 at all.

For example, $obj.length is not perl5, sub foo is bar { ... } is not perl5.

I don't deny your project,
but if this project is called Ultra Modern Perl 5, this caption maybe give a false impression to many people.

Build support for creating a 'moe' executable

This gets a little tricky since we have some jars we depend on, but there seem to be a number of solutions out there to bundle things up.

Add support for __FILE__

We should refactor the way we handle parsing of files so that we can keep track of the filename in the CompilationUnit AST node, this can then set FILE when it is evaluated.

MoeSubroutine needs to handle parameters

Ideally we keep this simple, we don't want to get too deep in the weeds on this feature, the Fun module should be used for reference.

Add support for &?METHOD

Similar to &?ROUTINE but only for methods and pointing to the MoeMethod meta object

Add support for __PACKAGE__, __SUB__, __METHOD__ and __CLASS__

These should all return the names of the current package, subroutine, method or class. The $? prefixed variables will be the actual runtime objects.

Capture stack frames in interpreter

We need to be able to print stack traces with exceptions, which means we need to capture stack frames in the interpreter.

Try/Catch/Finally in the interpreter

Try/Catch/Finally are just noops in the interpreter, this should be fixed. FWIW, I am pretty sure they are being parsed correctly.

create NativeObject for Exceptions

We need to be able to write the native Scala exceptions in a runtime accessible MoeNativeObject subclass.

Allow for optional parameters

A parameter postfixed with a ? should be treated as optional. Optional parameters can only be specified after all the required parameters have been specified.

This relates to Issue #45 and #46.