objectionary / eo

EOLANG, an Experimental Pure Object-Oriented Programming Language Based on 𝜑-calculus

This is our web site, it's here: objectionary.com

eo's Issues

How does the "cli" object work?

With regard to the Hello, World example:

import org.eolang.printed;
import org.eolang.string;
cli(
  printed(
    string("Hello, world!")
  )
)

I was sort of expecting to see a method call on the cli object and wondered whether, given that there isn't one, maybe some "work" happens in the constructor.

Yegor's answer was "The idea is that cli object is highest-level one in the script and it starts automatically."

Transferred from the comments on this commit.

Non-annotation 'annotations'

Annotations are one of the features that you don't want -- and I completely agree that the usual annotation-systems (ie specially-formatted comments) are totally unsuitable because of the ease to introduce mismatches between actual-code and annotation-code.

However, annotations do help with static analysis -- indeed Ada 2012 / SPARK 2014 can use their particular annotations in just such a manner, but the implementation of those is much different than the usual 'special' comment; instead they use something they term as "aspects". A small, trivial example:

Subtype Positive is Integer with Static_Predicate => Positive > 0;

The above indicates that the value of Positive is always greater than zero, something that was always doable in Ada with the range constraint, which is why it's trivial. -- The interesting point here is that via the use of aspects the annotation (which can be used by static provers [SPARK is a subset of Ada plus proving tools, including static analysis]) -- what this means is that the annotation, being actual code instead of a comment, can never be out-of-sync/"go stale" like a comment-based system.

Fake objects

@yegor256 do you want to bring the same concept of fake objects as it was in your blog with java?

type Book:
  String asText()
  object fake as Book:
    String @title
    ctor(title)
    String asText():
      title  

and later on use it like Book.fake("Elegant Objects")

in that scenario code from the read.me looks a bit confusing:

Ticket ticket(Person passenger):
  object x(passenger) as Ticket:
    Person @p
    ctor(Passenger p)
    String name():
      concat:
        "506-",
        @p.name()
    Money price():
      if:
        @p.vip(),
        money("$50"),
        object m() as Money
          Int value():
            25

Seems that you want to introduce static method to create Tickets, or the x(passenger) will be visible outside?

notation for object attributes

I offer to use dot-notation for object attributes.
For example:

Author author = Author.new("a", 1){
	String .name
	int .age
	new(String name, int age){
		.name = name
		.age = age
	}
	String name(){
		return .name
	}
	
	int age(){
		return .age
	}
}

The new constructor/method call syntax

Imagine that a method call doesn't consist of a method name and a list of its arguments. On the contrary, it looks more like a natural language sentence, is more agile and readable, but still well structured. Does it sound interesting?

In order to get closer to this idea, I like to use named arguments, i.e match(text='abcd', regex='\w+') instead of match('abcd', '\w+'). Particularly, it makes a lot of sense in case of deeply nested constructions, where an order of method arguments gets non-obvious and simply unshapely because of a cumbersome structure:

match(
  stripped_text(
    file(
      file_path(
        ['tmp', 'xxx.txt']
      ),
      'r'
    )
  ),
  '10$'
)

Here, one wouldn't so easily understand, what's going on. Really, what do these 'r' and '10$' mean? They are already out of context. Here, named arguments would come in very handy.

Let's get back to the first example: match(text='abcd', regex='\w+') vs match('abcd', '\w+'). The need to use named arguments here is much more controversial. They are still useful in case one mixes up an order of arguments, but make the code twice as verbose.

What would be the compromise?

I suggest to make argument naming required and eliminate the difference between a method name and argument names.

Simply put, I'd change match('w+', 'abcd') to match: '\w+' text: 'abcd'. Makes sense?

Take a look at our current code outline:

create fibonacci(1) as Number:
  Number n
  bytes asBytes():
    if:
      lessThan: @n, 2
      1,
      plus:
        @n
        fibonacci:
          minus: @n, 1

Indeed, as we got rid of the brackets, it isn't verbose at all. But the readability suffers just like in the example above. I believe, if the if had more code inside, it wouldn't be readable anymore.

What about something like this?

create fibonacci(1) as Number:
  Number n
  bytes asBytes():
    if:
      less: @n than: 2
    then:
      1
    else:  
      plus:
        @n
      and:
        fibonacci:
            minus: @n and: 1

Here, the if isn't a constructor with 3 unnamed arguments anymore. It has two named arguments: good old then and else are back in the game, but now in an object oriented way!

What do you think?

Perhaps extensible syntax?

All languages today provide a fixed set of tokens , keywords, and constructs. What about letting users define their own "little languages" and have them supported by the tools?

do we need brackets?

I don't think we need brackets. Look at this code:

String asText():
      copy sprintf(
          "ISBN is %s, title is '%s'",
          this.isbn,
          this.title
      )

And this one:

String asText():
      copy sprintf:
          "ISBN is %s, title is '%s'",
          this.isbn,
          this.title

Better, right?

do we need generics?

I don't know, that's why asking. Do we really need generics? What is the benefit of them? Can't we just declare the type at the time of its usage?

This is how it works now in Java:

List<String> list = new ArrayList<>();
for (String item : list) {
}

Can't we do this:

List list = new ArrayList();
for (String item : list) { // we just type cast here automatically
}

Exceptions: Single type verses rooted heirarchies?

Exceptions can be a funny beast: they can be considered their own entities/types, like in Ada where there's no commonality between Constraint_Error and Assertion_Error other than they're exceptions -- and this makes sense: it's rather senseless to allow exceptions to be treated like a family of types (Class) so that you could simply recast Constraint_Error as Assertion_Error (though similar-in-effect re-raising an exception is not the same thing). Another good point about exceptions not sharing a common ancestor is that you can make it impossible to catch the "root exception". -- On the other hand, am exception-hierarchy does allow handling exceptions by "this [exception-]type and everything derived from it". (IOW it's a design decision with pros and cons on both sides.)

As in Comment/Issue #42 this is another question that should be asked of exceptions about hierarchies, and it can be orthogonal to the answer given there about the object hierarchies. Of course they could be the same and unified, but as exceptions are for exceptional conditions perhaps they should be treated as special cases.

Contructors and Destructors

That issue is about:
https://github.com/yegor256/eo#constructors-and-destructors

The primary constructor must be the last one. The destructor, if it is present, goes right after the primary constructor.

Why the last one? The primary has to be the first, on top.

Another thing. See this code (copied from README):

object zero() as Money, Int:
  Int @amount
  String @currency
  zero(): # secondary constructor
    zero: 0
  zero(Int a): # secondary constructor
    zero: a, "USD"
  zero(Int amount, String currency) # primary constructor
  ~zero(): # destructor
    printed: "I'm dying..."

I think constructor shouldn't use the Object name. Maybe ctor or constructor.
The same for destructor, maybe dtor or destructor.
My vote is to use constructor and destructor.

And, please, throw away this ~zero(). I think nobody want to remember C++, right?

Types and "New" Objects

I'm confused about types and about creating objects and the "Hello, World" example.

import org.eolang.printed;
import org.eolang.string;
cli(
  printed(
    string("Hello, world!")
  )
)

If string is the name of the object (see comments here) how does the compiler know what type it is?
And the same question for cli and printed.

EDIT:

• string must be the name of an object, presumably of type String, that is created in org.eolang.
• The fact that we're passing in an argument means that we're actually constructing a new object by copying the existing one.
• In a similar way printed must already exist as an object. (I'm unsure what cli is exactly.)

Can we get rid of garbage collection?

Can we get rid of garbage collection? Is it technically possible? If all objects are immutable, I think it is...

I don't think we need "copy" keyword

Looks like copy keyword is redundant. I'm suggesting this:

type Point:
  Point moveTo(int x, int y)
object cursor(0, 0) as Point:
  Number @x
  Number @y
  Point moveTo(int x, int y):
    cursor: # here we COPY an object
      plus: @x, x
      plus: @y, y

No need to use copy at all. Just type and object are the keywords we need. What do you think?

Java compatibility: should we believe in it for now?

Hello :),

So, I'm checking that there are a lot of different Java compatibility concerns and efforts here, like using Java libraries, generating .java files, etc.

So, the whole question about it for me is: do we REALLY NEED to be Java compatible? I think that here we have a lot of Java devs that love it (like myself), but the whole problem with bringing all of those Java concerns is that maybe we are getting into a topic that will be really hard to manage with our focus of develop a completely new and full object oriented language. It seems that it absolutely not sustainable.

Ok, by one side there is a lot of Java stuff developed that would be awesome to bridge with EO, but by the other side, we are getting rid of our objective of develop a completely and whole new OO pure language.

We are a really small team for now, so I think that it would be better if we can focus on our biggest challenge here, that is cleanliness and validate our language. For me, bringing Java compatibility sounds completely strange as if for example you are building a bakery but want to sell someone else's bread because your village likes it, and your clients will come to you not to buy your breads, but your milk that is better than the other one (not really nice example, but I hope that you guys understood it).

What do you think?

objectionary.com

I own this domain: objectionary.com. The idea was introduced by David West in his book "Object Thinking" ten years ago. The idea is that objects will stay in some "repository" and applications will use them. Objects, not libraries, artifacts, binaries. Maybe it's time to use this paradigm in EO?

No test - no run

How about, mandatory testing? Objects have methods and every method must be tested. If at least one method has no test, compiler have a right throw a warning or even cancel compilation.
Good test - that test which cover all possible cases. We can extract these cases from expected exceptions of inner objects and from special cases of method's arguments.
Exceptions - the old song of OOP programming. But formal sign of special case for type - is something new.
What you think about this?

New language name proposal

Just idea to add 'L' to the end of the new language name to make it: Elegant Objects Language. This makes the language acronym to EOL.

This acronym, from the one side, is well known for all programmers already and, from the other side in Russian language Эол is a name of a demigod.

WDYT?

Shared vs distinct roots.

Delphi and Java have what is at times an excellent facility and other times not so helpful -- the single root-class "Object". One of the good things is that you have a standard basic and guaranteed interface for all your types... one of the bad things is that it forces the inclusion of things that otherwise might be senseless for the particular type you want to model. (For example, if you're modeling a memory-mapped I/O port you don't want a copy method, because there is [hopefully] only one such port.)

Syntax highlighting for Vim

I've created basic rules for Vim to highlight the syntax:
https://github.com/pchmielowski/EoVim

Please contribute ;)

[edit] It looks like that:

attribute number limitation?

An object may have up to five attributes.

What is the reason for limiting the number of attributes to 5?

Change return type of Book#asText in the example

Does String type suppose to be an elegant type?

I thought that java's Object#toString is often misused, perhaps it is the case.

I suggest we change it with Text type.

A better sintaxe

I would like to propose some sintaxe, as I've said here.

The sintaxe bellow have:

1. Types, instead Classes
2. The keyword constructor instead using the name of type, because now the Object was disconnected from Type, ie, don't have a Class!
3. I propose a new keyword implements that allow us to use an elegant delegation.

type Run { running() }

type Bark { barking() }

type Dog extends Run, Bark { 
  name(): String
  sit()
}

var r1 = object Run("fast!") {
  constructor (v: String) {
    var value = v
  }
  running() { print(value) }
}

var b1 = object Bark("AU AU") {
  constructor (v: String) {
    var value = v
  }
  barking() { print(value) }
}

var dog = object Dog("Rex") {
  constructor (n: String) { var name = n }
  name(): String { print (name) }
  sit() { print ("sat") }
  compose {  
    run from r1 implements Run,
    bark from b1 implements Bark
  }
}

dog.name() // "Rex"
dog.sit() // "sat"
dog.run.running() // "fast!"
dog.bark.barking() // "AU AU"

Object equality

How does equals object work?
Is every type equatable?
If yes, can I override default behaviour?

why do we need primary constructors

I think that in most all cases primary constructors will just save arguments into attributes. So, the question is, why do we need to declare them? I'm suggesting to prohibit them and use only secondary ones.

"@" instead of "this."

How about we use @ sign in front of attribute names instead of this. (like in Java)? Sounds practical to me. This is how Ruby works.

Meatier code example: Command line input

I've been trying to work out how a slightly more involved program might look.
I wanted to try and write a program that would ask for an integer from the user and then square it and print the result.
Should still be pretty simple, right? But I'm really struggling for some reason. :(

Any suggestions?

Edit: What I was trying to come up with was an executable example. Something that would be "complete", at least at the top level. I assume the "Hello, world" example is supposed to be complete in this sense. It just needs some explanation. Trying to come up with a "meatier" example was an attempt to provide that explanation, and go a bit further. (NB: I'm not suggesting the example would have to be perfect and never change, just that it would be our current best guess of an executable example that is a bit more real-world and interactive.)

OOP Messages

Dr. Alan Kay notes here and here how messages are the central point of Object Oriented Programming, even though it's been relegated to at least a second-class position because "Object Oriented" tends to make people think [only] about the objects.

Now, while he advocates an extreme late-binding, there are drawbacks that should be considered -- namely that (1) late-binding makes static analysis much harder [eg proving statically-typed languages vs proving dynamically-typed languages], (2) late binding makes certain optimizations impossible for the same reason that it makes static-analysis hard [increasing the types and number of unknowns]; (3) it makes debugging more difficult [the best debugging is the kind that never happens because it's "Correct by Construction"]. -- Because of this it may be worthwhile to consider messages themselves as a type/class/object/meta-type/however-you-want-to-say-it.

Learning From History

This initial comment is too long and has been edited too much. Apologies! I need to decide what to do about that.

Might there be some benefit in collecting together some resources relating to language development so that we can learn from history, so to speak. Maybe other people's war stories will be useful to us.

Obviously we will not all agree that these stories, or the opinions of the people telling them, are "right" or 100% relevant to what is being aimed at here. But maybe there could be some benefits:

• We can learn from the "good" bits.
• We can learn from others' mistakes.
• We can use the things that we don't agree with as fodder for deeper thought, for clarifying shared understanding, or for provoking discussions.

I'll start with the following two videos as suggestions:

• We're Doing It All Wrong - Paul Phillips
  • There is some good stuff here...
  • "I think that people that use a langauge end up unconsciously modelling the people that make it. So if you have issues at one level they're going to make themselves felt at the next level as well."
  • "The Scala compiler is so rediculously difficult to modify... The most trivial modification is a tremendous undertaking."
  • "Modification is undesirable, but modifiability is paramount."
  • Being able to do everything in a language makes doing anything at all more difficult. (Restrictions matter!)
  • "I don't need a programming language. I need a coherent set of tools for creating software. A language is incidental." (I think this is very much on point.)
  • (Just don't tell Yegor that this guy disses XML!) ;)
• Growing a Language - Guy Steele

(If anyone else has suggestions for videos or resources I'd certainly be interested to hear about them, and will add them here...)

• Object-based vs. Class-based Languages - Luca Cardelli (slides)
• Nothing is Something - Sandi Metz (video)
  • What if there were no if statements?
  • Be condition averse, message centric, abstraction seeking.
  • Nice example of how inheritance of implementation goes horribly wrong.

Java libraries

From Readme:

We want EO to be compilable to Java. We want to stay as close to Java and JVM as possible, mostly in order to re-use the eco-system and libraries already available.

How to import java libraries in EO?
What to do with restricted in EO things, like null, static, abstract classes, etc, imported from java libraries?
E.g. how to implement abstract class in EO to pass as parameter to java library. Or how to handle null, returned from library.

indentation parsing doesn't work

At the moment our ANTLR4 parser doesn't understand indentations. We have to fix it as explained here: http://stackoverflow.com/questions/8642154/antlr-what-is-simpliest-way-to-realize-python-like-indent-depending-grammar Anyone interested to contribute?

Git commit messages standard

Hello @yegor256.

I'm curious how far this language can evolve 👍

By the way, what's your opinion on git commit messages format?
I see that you don't follow any rules and simply name commits as short as possible:

There's a well known standard described in Chris's Beams blog and I bet you read it.
Is there a real reason to not to follow this best practices?

Syntactic sugar for decorating

Perhaps this syntax will be more comfortable for wrapping object in many decorators?
Doesn't matter, which type of brackets will be used for grouping decorators. Important only the idea - decorator is an object, which wraps other object of same type and we can simplify our life, when we make object + decorators hierarchy flatter.

// before
sliced(
    upperCased(
        reversed(
            string("hello world")
        )
    )
, 4)
// after
string("hello world")[
    reversed(),
    upperCased(),
    sliced(4)
]
// and decorator implementation
decorator sliced for string{
    int len;
    constructor(int len){
        this.len = len;
    }
    // string interface realization
    text(){
        // we can work with wrapped object via this.wrapped
    }
}

Inheritance for Types or Type composition

In this chat we are discussing about inheritance for Types and now I'm thinking about if we really need this.
According to this article, Interfaces must be small. I agree. But if we will have inheritance for Types (interfaces), how guarantee they will be small?
if A have 3 methods and B, that inherits from A, have more 3 methods, the Object will need to implements 6 methods. That is huge.

I'm thinking about Type composition instead of inheritance for Types.

Before you start to think in this idea, you need to understand how composition, supported by language, will work. In issue #6 I've proposed a syntax for object composition. But we can improve and extend that for Types too.

More laconic syntax?

Good code is both short and well readable. Good code doesn't repeat itself twice.

Essentially, when the code is consistently indented, the semicolons, curly braces, Ruby's end or any other block indentation techniques are tautological. Python is a good example of a laconic(and potentially object oriented!) language, where the whitespace indentation is the block indentation at the same time.

Compare

type Book {
  String asText();
}

create abc("The Alphabet") as Book {
  String isbn;
  String title;
  Book(ISBN i, String t):
    isbn(i),
    title(t);
  String asText() {
    copy sprintf(
      "ISBN is %s, title is '%s'",
      this.isbn,
      this.title
    )
  }
}

and something like this:

type Book:
    String asText()

abc("The Alphabet") as Book:
    String isbn
    String title
    
    constructor(ISBN i, String t):
        @(isbn=i, title=t)

    String asText():
        copy sprintf(
            "ISBN is %s, title is '%s'",
            isbn, title
        )

The constructor syntax is free to negotiate. There are a lot of ways it could be written the other way.
In my example the @ operator would require to initialize all fields of the object.

License for specification and examples?

What open source license should we use for this specification and its examples? It's beneficial for implementations to be able to use and modify the examples "as is", and similar for grammar rules.

Sugar for operators

Uniformity of syntax it's good, but constructing objects and calling their methods for every control flow statement and operator is not comfortable for people. Perhaps we need to use traditional syntax for it, which will translated into instantiating of object and method call?

if(1==2):
    11
else:
    12
// Will be translated to
(new If( new Equals(1,2) , 11 , 12)).value();
// Where
class If implements Computation{
    public Object value(){
        return this.test.value() ? this.first : this.second;
    }
}

Translation to java or compilation to bytecode?

Hello!
Quoting the README:

We want EO to be compilable to Java. We want to stay as close to Java and JVM as possible, mostly in order to re-use the eco-system and libraries already available.

This code will compile into a .java class that will compile into a .class byte code that will run and print "Hello, world!".
...

Why don't it compile directly to the bytecode as Scala, Groovy, etc?
It would still be anyway able to use all the benefits of java eco-system.
This would eliminate an extra translation step.
Also, I guess it could be more natural for building, e.g. for Maven.

Ambiguous copy syntax

if is a object with three args. Full expressions look like this: if: condition, then, else

Any arg contain object create expression (in most cases)
For example equals: p, 0

I can write this code:
if: equals: p, 0, 1, mul: x, power: x, minus: p, 1

Where is then arg?
Compiler can parse this.
Question about readability.

In readme - missing semicolon after equal expression and 1

Int power(? x, Int p):
  if:
    equals: p, 0
    1
    mul:
      x,
      power: x, minus: p, 1

Why ctor? and why not "constructor"?

How much does "onstruc" save you?

It seems like the code is based on an English-language base, why not keep it that way purely?

Developers should be adept with tools like vim, content assist, etc to complete tokens. This way you don't compromise the clarity of the language for the sake of convenience.

Kotlin style field initialization

In Java, to initialize a field with the value from ctor parameter, we have to write a lot of code.
Your proposal from Readme is slightly less verbose and better:

String isbn;
String title;
Book(ISBN i, String t):
  isbn(i),
  title(t);

..but in my opinion, we can do it even more elegant by being inspired with Kotlin. Take a look, here is how we are creating a class Person with one private field called firstName and one ctor, which takes a firstName argument and assigns its value to field:

class Person(firstName: String) {
}

More: https://kotlinlang.org/docs/reference/classes.html

simple compiler is missing

The compiler is missing and it looks like it's time to create one. I'll take care of it now.

Language support for collections

Presently there is a weird division in programming where you have to use Multiple of a type of object differently than a single object.

This leads to creating String and List and so forth. Collection objects are used extremely frequently in real application code. What if the langauge were to be able to create this collection behavior automatically?

What if using a plural form of a known class name would automatically compile to a collection by default.

Consider this code.

Color white = color("#ffffff")
Color black = color("000000")
Colors appColors = colors(white, black)

While the Color type or object would need to be declared, it would be nice if Colors behaved like a List or similar.

Do we really need create new language?

I think that no any reison for creating new language with the different syntax. Let me explain my point.
These are some facts:

• All problems in IT development described by @yegor256 are exists. We all are agree with most of them.
• If we are set analogy with knife(Java language) and our skills(java libraries, frameworks, paradigms, patterns, etc...) for use it. And when we are using this knife with our skills our hands fills by blood. That is bad and sadly.
  We are have 2 choices: change language or change our skills.

1. If we are want change language - we can do it. You can use Ceylon, Ruby, JRuby or other (Python, Scala, Groovy, etc...) On any taste. Also we can create new language and after some months or years one of us will be looked at it and will say: "Well... we are created a Ruby!". It is like a story about 15 standarts and we are try create another one...
2. Or we are can change our skills. We can show to all developers our point of view for OOP, objects and how should to use it . And prove it by practice and show them that it works well. Practice the criterion of truth, isn't it? We can show right way for use Java and "true code".

It is a short version of my reasons, so, if you have any questions, please, ask me.

Replacement for "if" operator

From the README:

These things we don't tolerate:
- operators (for, while, if, etc)

While it is not particularly hard to encapsulate conditional operations like the "if" operator, I do not know of a way to get around having it exist somewhere.

In C#, I am able to create objects like this:

public class ConditionalAction
{
    private readonly Func<bool> condition;
    private readonly Action action;

    public ConditionalAction(Func<bool> condition, Action action)
    {
        this.condition = condition;
        this.action = action;
    }

    public void Invoke()
    {
        if (condition.Invoke())
            action.Invoke();
    }
}

This makes it so that calling code no longer requires the "if" operator, but it does require the instantiation of an object for every conditional action. It moves the problem elsewhere, but doesn't entirely solve it.

That would transform this code:

if (!heater.IsRunning())
    heater.TurnOn();

Into this:

var turnOnIfNotRunning = new ConditionalAction(() => !heater.IsRunning(), () => heater.TurnOn());

turnOnIfNotRunning .Invoke();

The second one is slightly more object-oriented (it utilizes functional-style lambdas), but it seems more complex and more verbose.

What is a more elegant way to replace the "if" operator?

Type vs "Anything in the heiarchy rooted at this type"

One problem that many modern OOP languages have is a failure to discern between "exactly this type" and "this type or any of its decedents" in parameters. -- For convenience let us call the "hierarchy rooted at this type"a class.

("type types" just sound wrong,; and I'd rather not use "abstract type" or "interface" because they're further away from the idea than I'd like.)

One way to distinguish between the type and the class would be to co-opt something like Ada's class attribute. (Attributes being a property of the type rather than a method [e.g. an array-type has the attributes first and last which are always the first and last values of the index] and are indicated with the ' character.)

Thus, in Ada, it's possible to express something like:
Function Image( Object : Sometype ) return String;
and
Function Image( Object : Sometype'Class ) return String;
with the former meaning "a parameter of exactly this type" and the latter meaning "a parameter of this type or anything descended from it".

There are several advantages to this separation:

1. Dynamic-dispatch is slow compared to static calls.
2. It allows for a clear indication between dynamically-dispatched calls and static-calls in the source.
3. Only method calls with a class parameter need dynamic dispatching; calls without can be statically determined.
4. Inheritance-wise, a method with class means that it is written/implemented in the general manner and need not (and probably should not) be overridden... whereas an inheriting type should override a method with a parameter of the type.

Perhaps extensible syntax?

All languages today provide a fixed set of tokens , keywords, and constructs. What about letting users define their own "little languages" and have them supported by the compiler and

Interoperability

There have been other issues that sort of touch this topic.

However, I think that the issue of interoperability is crucial for any sort of adoption. Unless adoption is not a goal, there has to be an explicit focus on interoperability.

I am aware that as of now, the JVM is the only target platform, so that makes things a bit easier. It is true that most of the JVM libraries are garbage, especially the older ones. Yet, many of them save time and as a consequence, money and that matters.

Convert to multi languages

I wonder if it could be designed in way that allow it to be translated into several languages easily
like java , c++ ,python and swift
also if it support MVVP or MVC in it core design.

Anonymous objects

I think object name x is redundant here:
(readme example)

Ticket ticket(Person passenger):
  object x(passenger) as Ticket:
    Person @p
    ctor(Passenger p)
    String name():
      concat:
        "506-",
        @p.name()
    Money price():
      if:
        @p.vip(),
        money("$50"),
        object m() as Money
          Int value():
            25

It may be clearer with anonymous object:

Ticket ticket(Person passenger):
  object (passenger) as Ticket:
    Person @p
    ctor(Passenger p)
      ...

The If object is not a good object

According to http://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html, there are seven virtues for a good object. These include:

• He Exists in Real Life
• He Works by Contracts

As far as I can tell, the If object does not satisfy these 2 requirements. I don't see any "If"s in real life. What real life object does an If object represent? And what type/interface would an If object belong to?