eerolanguage/eero

source translation

Closed this issue · 9 comments

if you could code in eero, and translate to objective-c, that would be a my last barrier to adopting eero.
what if eero no longer gets supported, i would just be able to use eero as a great source translation tool.

Hmm, actually, this almost works out-of-the-box, thanks to clang's -cc1/-ast-print. For example, using the front page example:

$ /usr/local/eerolanguage/bin/clang -cc1 -x eero example.eero -ast-print -o example.m

produces (but after manually stripping header translations):

@interface FileHelper : NSObject
@property ( readonly,atomic ) NSString * volumeName;
@property ( readonly,atomic ) NSString * volumeFormat;
+ (NSString *) pathStringWithComponents:(NSArray *)components;
- (NSFileHandle *) openFile:(NSString *)file withPermissions:(NSString *)permissions;
- (NSFileHandle *) openFile:(NSString *)file;
@end
@implementation FileHelper
+ (NSString *) pathStringWithComponents:(NSArray *)components {
    ;
    NSMutableString *fullPathName = [NSMutableString new];
    for (NSString *component in components) {
        [fullPathName appendString:[@"/" stringByAppendingString:component]];
    }
    return fullPathName;
}


- (NSFileHandle *) openFile:(NSString *)path withPermissions:(NSString *)permissions {
    ;
    NSFileHandle *handle = ((void *)0);
    if ([permissions isEqual:@"readonly"] || [permissions isEqual:@"r"]) {
        handle = [NSFileHandle fileHandleForReadingAtPath:path];
    } else if ([permissions isEqual:@"readwrite"] || [permissions isEqual:@"rw"]) {
        handle = [NSFileHandle fileHandleForUpdatingAtPath:path];
    }
    return handle;
}


- (NSFileHandle *) openFile:(NSString *)path return [self openFile:path withPermissions:@"readonly"];


@end
int main() {
    FileHelper *helper = [FileHelper new];
    NSMutableArray *files = @[  ];
    [files addObject:([helper openFile:@"readme.txt"])];
    for (NSFileHandle *handle in files) {
        NSLog(@"File descriptor is %@", [NSNumber numberWithInt:([handle fileDescriptor])]);
        [handle closeFile];
    }
    return 0;
}

More work is definitely needed, but it's an encouraging start.

That's awesome...

@andyarvanitis In reply to your tweet:

I think that this feature brings many more benefits that simply reducing the fear of adoption as it would allow to:

  • Use compilers provided by Apple to submit applications to the App stores (irrc it is required somewhere in their documentation).
  • Allow to create libraries that can be used by non eero projects.
  • Generate a quite readable objective-c trasnpilation that can be read by people not familiar with eero.

To sum up, I think that this feature is critical for a rapid adoption of eero and is one of the secret sauces of coffescript.

I completely agree. Another factor is this (and as you say, this is a
key part of Coffeescript's adoption to date): early adopters will
face bugs in Eero. With a native compiler they can diagnose them by
debugging the compiler or disassembling the output. With a source to
source compiler, they can simply diagnose the ObjC source (which they
almost certainly already know well).

On 11/07/2012, at 6:15 PM, Fabio Pelosin
reply@reply.github.com
wrote:

@andyarvanitis In reply to your tweet:

I think that this feature brings many more benefits that simply reducing the fear of adoption as it would allow to:

  • Use compilers provided by Apple to submit applications to the App stores (irrc it is required somewhere in their documentation).
  • Allow to create libraries that can be used by non eero projects.
  • Generate a quite readable objective-c trasnpilation that can be read by people not familiar with eero.

To sum up, I think that this feature is critical for a rapid adoption of eero and is one of the secret sauces of coffescript.


Reply to this email directly or view it on GitHub:
#24 (comment)

Excellent points. I agree that this will need to be a priority feature for eero.

As for Apple compilers required for the App stores, we'll definitely need to take a close look. I'm wondering about this since RubyMotion is out there and has apps in the store. Unfortunately, I personally haven't had a chance to take a close look at RubyMotion, and don't know much past the fact that it uses an LLVM-based compiler.

Very exciting!

Thanks! And thanks again for the support and feedback!

On Tue, Oct 9, 2012 at 11:57 AM, Jonathan Sterling <notifications@github.com

wrote:

Very exciting!


Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-9274456.