It has no theoretical significance per se, but only serves the purpose to support a personal belief that Java IS Objective-C.
Java classes and APIs were replaced with Cocoa's.
All classes were derived from
Strings were replaced with
List<>s were replaced with
Map<>s were replaced with
Set<>s were replaced with
nulls were replaced with
toString()s were replaced with
C funtions and (singleton) class methods were used to emulate the public static member variables and methods.
In some APIs, orders of parameters were changed to fit in the naming convetion of Cocoa, more or less.
NSURL was used to replace
file parameters internally, as
NSURLs are the recommended representation of paths for Mac OS X. The first and only supported command-line parameter of interpreter should be either a raw path or a path prepended with 'file://' before any path.
https protocols were not tested but are likely to work.
Constants in Constants.java were replaced directly with string literals just in place.
In Xcode, to debug using a test script, add parameters in Edit schemes-> Run ObjYin -> Arguments -> Arguments Passed On Launch, e.g.:
file://$SRCROOT/Tests/expr.yin (where $SRCROOT would be resolved to the path of the source code folder by Xcode)
What's working so far
It seems that ObjYin has successfully interpreted
recursion-direct.yin. Bugs may exist for others.
An experimental REPL has been added as a building target
Try it in Terminal.app or Xcode debug console by simply running it in Xcode!
BigInteger support is missing, however, the upstream has not fully supported it either.
Due to the nature of ObjC's dynamic typing, it is impossible to reinforce many compile-time type checking, especially for the containers.
More targets (typechecker, parser, etc.) are missing for now.
GNU AGPLv3 license: I do not personally favor GNU licenses and am too lazy to add one, feel free to add if you need to.
This is a weekend-project, do not expect too much, after all.
Perhaps a Swift port?