eerolanguage / eero Goto Github PK

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.

Example:

myobject somemethod
*ptr = 0 // '*' is incorrectly associated with previous line

As of Mavericks, OS X builds default to using libc++ instead of GNU's libstdc++. However, eero's clang compiler currently only seems to work with libstdc++. Need to reconfigure how eero clang is built to properly recognize libc++. Both options should work.

The example code is no-where near Python-like in indentation, style, or readability. The indentation rules of Python clearly indicate scope nesting, whereas your front-page example clearly does not; the plus indicator with a space can easily be mistaken for an indentation level making the example's class method appear to be part of the previous scope.

The lack of clear scope designation (colon at the end of the local scope increment, e.g. if foo:) makes it very hard to read with two-space indentation (a level that no sane Python developer uses, we've standardized on four), unnecessarily verbose assignment operators (I'm assuming to differentiate from comparison), and what has to be the least obvious function declarations of any language I have ever seen. This snippet:

openFile: String path, withPermissions: String = 'readonly', return FileHandle

There is next to no visual distinction between arguments and return type, no clear designation as a function / method, and no scope operator. Standalone most people likely couldn't tell it apart from a one-line function what with the return keyword on the same line! It's unreadable and very, very un-Pythonic.

I'm pretty sure if Python were a person, it'd be ashamed to be associated with this syntax.

Quickly edited to add another jibe.

I'm using the code listed here: http://eerolanguage.org/index.html

I'm getting the following compile error:

test.eero:2:13: error: use of undeclared identifier 'FileHelper'
  helper := FileHelper new  // declare variable "helper" via type inference
            ^
test.eero:4:12: error: NSArray must be available to use Objective-C array literals
  files := []  // empty array literal implies mutable
           ^
test.eero:7:7: error: use of undeclared identifier 'FileHandle'
  for FileHandle handle in files  // all objects are pointers, so no '*' needed
      ^
test.eero:11:3: error: expected expression
  return 0  // semicolons are optional almost everywhere
  ^
test.eero:11:3: error: expected expression
5 errors generated.

When finding/reporting an error, sometimes the parser gets "lost" when trying to proceed to the next bit of code. This is due to the inadequate handling of skipping to the next statement after discarding everything after the error (since semicolons are typically not present).

A literal (numeric or string) outside a function or declaration makes the compiler discard the remainder of the file. Example:

#import <Cocoa/Cocoa.h>

20

// ignored from this point on

int main(void)
  ...

An enum declaration is not properly terminated without a semicolon. Example:

enum { first,
       second, 
       third } // produces a compilation error without an explicit semicolon here 

Casts of the form

    numberArray := (Number<TypedArray>)array

are currently returning compilation error "Parameter name omitted". This should be a pretty easy fix.

Currently, the compiler generates ugly default variable names in interfaces (not in implementations). For example:

interface MyClass
   setObject id, withObject id  // generates var names "objectA", "objectB"
end

This was done avoid compiler warnings in interfaces for multiple parameters with the same name. The problem with these names occurs when the compiler emits other errors or warnings and references these names. At the very least, the first occurrence should not have any suffix (e.g. "object", "objectA").

With the cause of reducing redundancy and the pain points of Objective-C I would like to request the following feature:

The interface section should be optional, and synthesized from the implementation — just like in Java, Ruby, Python, and most modern languages. The Implementation contains all the information needed to derive the Interface in all cases except when manifest constants (or the like) need to be declared.

The following is emitting a compiler error:

if string == ''
  do something

produces:

error: empty character constant

It needs to be accepted as valid.

Saw this tip in the recent NSHipster, which I think is good idea although it's crying out for a nicer syntax:

Passing strings as key paths is strictly worse than using properties directly, as any typo or misspelling won't be caught by the compiler, and will cause things to not work.
A clever workaround to this is to use NSStringFromSelector and a @selector literal value: NSStringFromSelector(@selector(isFinished))

I'm suggesting that the syntax @|isFinished| would fit nicely into eero. Forgive me if this is already in the language.

Also, even though there may be less call for using NSStringFromProtocol, why not use similar syntax on protocol literals, even if only for completeness?

I would love an optional dot notation syntax for calling methods, like Python and Ruby.

I've never enjoyed ObjC's [obj method:arg] syntax for method calling, particularly when method-chaining. Compare, using an example swiped from the internet:

[[NSOpenGLContext alloc] initWithFormat:[self pixelFormat]]

vs

OpenGLContext.alloc.initWithFormat(self.PixelFormat)

or even

OpenGLContext.alloc.initWithFormat self.PixelFormat

There is currently not a straightforward way to install. Brew support would be great.

The following is not parsed correctly and causes the compiler to get stuck in a loop:

implementation MyClass
  doSomething id, otherObject id
    ;
end

Code of the form:

id obj = String new
((RecordType*)ptr)->x = 0

Produces:

error: called object type 'id' is not a function or function pointer

Methods with redundant parameter variable names in an interface should not cause warnings (however, in implementation, they should).
Example:

interface MyClass : Object
  doSomething id, something id, return id
end

When compiling with the Eero LLVM compiler 3.0, this demo Xcode Project refuses to compile, claiming that it cannot find 'stdarg.h'

Additionally, it would be nice if this (or some other @eerolanguage repository) had a demo Xcode project for using eero in an actual app environment.

Installed XCode plugin. eero is in /usr/local/eerolanguage

Registered file type.

Added Test.ero file.

Compiled.

clang: error: language not recognized: 'eero'

Eero compiler is visible in Build Settings.

When using ARC, you need to provide annotations when casting in the form of __bridge, __bridge_transfer, or __bridge_retain for Core Foundation types.

I would expect this to work:

Array arr = (__bridge_transfer Array)my_cf_array 

Instead it requires the pointer to be specified instead of using implicit pointers like everywhere else.

Array arr = (__bridge_transfer Array *)my_cf_array 

One of the things in C++ that I miss in objective-c is std::vector. It would be nice if eero could have some sort of value type parameterized array.

Like LLVM/clang itself, Eero is cross-platform. It has been tested (in the past, but not recently) on Debian Linux using the GNUstep runtime.

if i may bring up one valid subpoint of @amcgregor's issue: the plus indicator should probably retain it's counterpart, -, for instance methods.

maybe it's just a personal preference, but i often use the two at quick glances for determining (obviously) whether or not the method is a class or instance method. not having it also throws the spacing off (-;

If all that eero had was
optional semicolon, indentation as scope, optional parentheses around condition, message passing without square brackets and type inference
I think it is a huge improvement over Objective-C because they are used all the time.

I want to use switch to eero, but after reading the documentation, the list is pretty long. i have to remember a bunch of new stuff.

I think just changing @selector(someMethod:) to |someMethod| isn't really worth it. Even though it is more concise, It just increases effort for adoption.

Here are things that I think are really useful and things that I rather not have changed from objective c (even if eero makes more sense).

Optional semicolons +100
Off-side rule (indentation indicates block scope) +100
Optional parentheses around conditions +30
Message passing without square brackets +100

Objective-C keywords without ’@’ -10
Logical and bitwise operators and, or, not, etc. +10
The goto statement is illegal -10

Built-in symbol search on names with the “NS” prefix -10
User-defined prefix namespaces -10
Variables and literals +0

Object declarations are assumed to be pointers +10
Local type inference +30

No variable shadowing +0
NSString literals using single quotes +0
No ’@’ needed for array and dictionary literals +0

Mutable array and dictionary literals -10
Variable definitions using type inference and nil or Nil -10

Selector and protocol literals -10
NSRange literals (and expressions) using ‘..’ or ’…’ -10
NSRange variables and literals in for in loops -10
Underscores permitted in numeric literals +0
Stricter enum type checking +0

Method parameter type names are not enclosed in parentheses -10
Method parameters have default variable names -10
Method return type specified by trailing return, void by default if omitted -10
Methods are instance methods by default +10

Optional parameters and default arguments -10
Default return expression -10
No curly braces needed around member-variable declarations +10
Declarations of properties of the same type can be grouped together +0

Built-in equality and inequality comparison operators -10
Built-in ’+’ (binary version) and ’«’ string operators -10
Binary operators (effectively, operator overloading) -10
Array and dictionary subscript operators with integer and object indexes -10
Object subscript operators with NSRange indexes -10

Converting primitive data types to objects (boxing) +10
Converting objects to primitive data types (unboxing) +10

Blocks enhancements
Compact blocks -10
Nested functions (const blocks) -10

The switch statements
No fall-through +20
Comma-separated lists of cases +10
Case-value ranges -10

I think decreasing the number of differences between objective c and eero makes sense and only adopting differences that make a big impact in everyday coding would make the transition to eero easier.

I know this would make eero not as pure and clean, but It would still be a lot better than objective c.

A ternary expression such as this:

id result = isReady ? object1 : object2

does not work because the colon is parsed as part of an unnamed message send to object1.

After Xcode is restarted, autocomplete seems to work fine (no issues with subsequent Xcode launches). I don't know why this is happening, but will investigate it.

The following generates an error:

implementation String ()
end

If a category name is provided, no error is produced.

Use of throw still requires semicolon at end of statement:

...
throw exception
...

resulting in

error: expected ';' after @throw

Is this possible?

A terminating semicolon is required after struct declarations. Example:

struct _mystruct { int a
                   int b } // semicolon needed here

Note: This is not the same error as the enum error. This one generates an "error: expected ';' after struct" compilation error instead of just continuing to parse the next line.

Currently, system headers are parsed in "compatibility" mode (interpreted as standard C/ObjC). Consider also recognizing @interface/@EnD blocks (with '@' in keywords) as well. It might also be desirable to support @implementation/@EnD.

Properties declarations should behave like other declarations and treat classes as pointers implicitly. For example,

property (readonly) String*  highlightColorDefaultsKeyName

should not requre the trailing "*" after "String".

Have you considered removing the need for [NSString stringWithFormat:...] by creating a way to interpolate strings?

I'm thinking similar to how Ruby/Coffeescript allows this with "My name is #{name}"

Considering how often the compiler complains about incorrect format specifiers (e.g %d instead of %ld), it would be great if you could just look at the type and perform the substitution with the default specifier for the type.

Compiler crashes after use of certain undeclared identifiers. Example:

AutoreleasePoolX pool := new
...

Yields

cast.ero:7:3: error: use of undeclared identifier 'AutoreleasePoolX'

followed by crash at token 'pool'

The following is allowed, and shouldn't be:

typedef { Red, Blue, Green } RGBType

int x = Red
char y = Blue

The biggest problem I encountered playing with EERO is compatibility with CPP macros. This prevents Sen, Kiwi, Reactive Cocoa, etc. from working properly.

I think the obvious solution is to add syntax to escape to standard Objective-C and insert code that would otherwise be invalid in EERO. Ideally EERO should also automatically escape for CPP macros from non-EERO source files so they just work. Parameters to the macros would need to be excluded. This may also be useful for embedding C++ code that would otherwise have problems.

Example: (using "begin_objc { … }" as example syntax)

implementation

eeroMethod, return String = 'eero side'

begin_objc {
- (NSString *)objcMethod {
    return @"objc side";   
}
}

eeroMethod2, return String
    begin_objc {
        return [self objcMethod];
    }

eeroMethod3, return String
    return MY_OBJC_MACRO('arg 1', 'arg 2')

end

This was a request/suggestion made by a user via email. Compact blocks (not normal blocks) would implicitly return the result of the expression. Also consider allowing "return" keyword to be optional. Example compact blocks from documentation page would change to:

xyblock := (int x, int y | x + y)

descriptions := mylist.mapWith: (id element | element.description)

In the current build, cases are no longer automatically breaking. The blog front page example fails:

    switch descriptor // no fall-through between cases (breaks not needed)
      case 0, 1, 2
        NSLog( 'stdin/out/err' )
      case 3 .. INT_MAX
        NSLog( 'regular file' )
      default
        NSLog( 'bad descriptor' )

for me:
var car = Car new
is more readable than
car := Car new

It seems cleaner with less symbols.

I tried to "automatically" insert outlet/action from the Interface Builder, but XCode can't find the implementation for given header (well, it's written in eero). Is there a workaround?

Also (maybe related) I was trying to follow https://github.com/eerolanguage/eero/tree/master/xcodesupport/Xcode4+ but there is no Register Eero File Types.app file and I can't run the Register Eero File Types project (no MainMenu).

it's rare that atomic is needed, so why not reduce the boilerplate?

Bracketed expression is erroneously parsed as part of the prototype. A semicolon after the prototype makes it parse correctly.

Example:

setName String, length unsigned int

  [System log 'Here']  // gets associated with prototype above and produces error

Feature request to circumvent (String stringWithFormat: 'Hello %@%s', 'World', "!"):

Declaring strings from formats should be as easy as:

formattedString := 'Hello %@%s': 'World', "!" // format, ... 
// or
formattedString := ('Hello %@%s': 'World', "!") // (format, ...)

This might be a silly idea, but I'll raise it anyway. I recently watched a WWDC video where Blaine Garst (WWDC 2010 Session 113 "Working Effectively with Objective-C on iPhone OS" at around 23:30) lamented the fact that because "@interface" is already used to declare a class, it is not available for declaring interfaces, which are therefore declared as "@protocol".

A new syntax for Objective-C might be the opportune place to let people declare a class with "class", and an interface with "interface". I'm not sure whether this would create less, or more confusion for existing Obj-C developers, but it would be very likely to be better for developers from any other language. Which audience is eero more targeted at?

Or there might be technical reasons that this is a bad idea.

The compiler is currently not accepting option "-x eero-header". This is necessary for PCH file generation.

I'm not exactly sure what I'm expecting here (i.e., int main() should implicitly include a call to autoreleasepool, or something else entirely), but having to manually "wrap" (read: "stick arbitrary header before") code just to handle autoreleasing feels... out of sync with the ethos of the project.

Totally a feature request, and a very unimportant one at that, but something about:

int main()
    autoreleasepool
        (myObject doStuff)

feels 1 level too deep.