Mirah questions - Class Constants, Iterators

35 views
Skip to first unread message

J. Scott Kasten

unread,
Aug 16, 2014, 9:57:21 AM8/16/14
to mi...@googlegroups.com

Hi guys,

I've been working with Mirah in an android project for some weeks now.
I've run across two minor issues that I have not seen referenced online.

[1] I have noticed that the Ruby syntax for class constants does not work.

class Foo
LEFT=1
RIGHT=2

def bar
...
end
end

Basically, the compile chokes on LEFT and RIGHT. As a work around, I've
used these two forms for now:

def LEFT:fixnum ; return 1 ; end

or
def self.RIGHT:fixnum ; return 2 ; end

The choice of course depending on the desired scope. This works, but what
is the "correct" mirah form for such constants???

[2] I get a parser warning about a miss-matched kEnd on iterators. The
code compiles, and appears to execute correctly despite the warning.

dates = ArrayList.new [ "Su", "Mo", "Tu", "We", "Th", "Fr", "Sa" ]

dates.each do |day|
... something ...
end

Code like the above produces these warnings during type inference:


-compile:
compiling Mirah source in /Project/..../src/. to ./Project/..../bin/classes
Parsing...
./Project/..../MainActivity.mirah
Inferring types...
WARNING: Misaligned end at mirah.lang.ast.StringCodeSource@a7775a:5:1
NOTE: closes block at mirah.lang.ast.StringCodeSource@a7775a:1:1
Compiling...
./Project/..../MainActivity.mirah
Done!

-post-compile:

This seems to be a spurious warning. Has anyone else seen this? Should I
be concerned? Have I implemented the source syntax as intended?


Thanks for any opinions. The versions of tools are:

mirah 0.1.2
pindah 0.1.3
jruby 1.7.11 (1.9.3 p392)
jvm 1.7.0_p51-b13 for i386 (Oracle JDK)
ant 1.9.3

Regards,

J. Scott Kasten

Nick Howard

unread,
Aug 20, 2014, 3:01:20 AM8/20/14
to mi...@googlegroups.com
Hey,

I missed constants in my last round up of things to work on, but I think I have a fix for it.

The misaligned warnings are due to over aggressive indentation checking in the parser. It's removed in 0.1.3 I think.

I'm hoping to have the next couple releases be smaller, more incremental, so constant support should come faster than 0.1.2 to 0.1.3.




--
You received this message because you are subscribed to the Google Groups "The Mirah Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mirah+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
-Nick Howard
http://blog.baroquebobcat.com/

J. Scott Kasten

unread,
Aug 20, 2014, 1:20:10 PM8/20/14
to mi...@googlegroups.com


On Wed, 20 Aug 2014, Nick Howard wrote:

> Hey,
> I missed constants in my last round up of things to work on, but I think I
> have a fix for it.
>
> The misaligned warnings are due to over aggressive indentation checking in
> the parser. It's removed in 0.1.3 I think.
>
> I'm hoping to have the next couple releases be smaller, more incremental, so
> constant support should come faster than 0.1.2 to 0.1.3.
>

OK, thanks for the info. Will look forward to test driving the code
updates when they are ready. :-)

Cheers,

-S-

Justin Sowers

unread,
Oct 13, 2015, 12:45:09 PM10/13/15
to The Mirah Programming Language
I'm tagging onto this to ask for what I hope will be simple change to 0.1.4 to help with constants.  From what I can tell, constants in Mirah code are emitted as private static final [constant] declarations in the Java backend.  This means that trying to access an inherited constant does not work in the subclass, as well as externally accessing a constant in a deliberate [abstract] class defined only to hold constants.  Is it possible to change the compiler to emit public static final declarations for CONSTANTS?
I can provide example code if this was too hard to follow.
To unsubscribe from this group and stop receiving emails from it, send an email to mirah+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Justin Sowers

unread,
Oct 13, 2015, 2:32:42 PM10/13/15
to The Mirah Programming Language
I've implemented workaround [public] class methods that return the private constant to enable an abstract constant containing class, such as:
  def self.CATEGORY ; return(CATEGORY); end

it's a hack, but it's getting me by.
Reply all
Reply to author
Forward
0 new messages