BORK syntax

[kedaman]

The BORK functor (function object) is essential to BORK and will replace the need of classes, functions, template classes, template functions, and will also function as a range of other concept that you don't find in OOP and even in classic Generic Programming. Anyways, here's some basic comparation of syntax between C++ and BORK on OOP concepts.

Classes, functions
[C++ Syntax]

class vector{
    int x;
    int y;
    int z;
}
class stuff{
    static int x;
    static const int y;
}
const int stuff::y=5;

[BORK Syntax]

vector{x y z}    //alternatively vector* x+y+z
stuff{x y*5}    //alternatively stuff*  x *y*5

***********************************************
Entry point
[C++ Syntax]

void main(void){}


[BORK Syntax]

main{}

***********************************************
Object Orientation
[C++ Syntax]

class A{
    int x;
    A(int px){
        x=px;
    }
    int function(int a,int b){
        return a+b*x;
    }
}
main{
    A a(1);
    cout<<a.function(2,3);
}


[BORK Syntax]

A{
    x=,
    ,
    functor{
        ,/pa+,/pb*./x
    }
}
main{
    a{1 A}
    cout*a*functor{2*pa+3*pb}
} 

[Zaei]

You are, indeed, quite mad =).

Z.

[kedaman]

It might look weird but that's only because BORK isn't particularily object oriented, neither function based, rather functor oriented.

[Zaei]

You could have made it a bit more readable =). Though, with better variable and class names, im sure it would be much better.

Z.

[CornedBee]

Yeah, from readers point of view, it seems like a big step back.
But if you invented a new great programming paradigm, that would be cool.
Is this your new language? Do you need an extra compiler to convert it to C++ or is it entirely made of templates?

[kedaman]

I need a compiler in between, and yes, this is enterily new paradigm, since it's definitely not favouring neither object or functional style, rather functoral style.

All objects in C++ are functors in BORK
All classes are functors
All functions are functors
All members both static and normal are functors
Inheritance and Polymorphism is done trough nesting functors
Delegation and containment as above
All functors are templates functions and template classes by default

New in BORK is

Template code, any functor can be instantiated as anything representable in code, by it's name, so generic programming isn't only restricted to template classes, and template functions

Functor nesting(or type nesting) - something that looks like inheritance, but works like template specification, all datatypes and functor calls are essentially nested functors, relating information with the multiplication operator * or the nesting operator {} unnessting is done with division operator /

Functor addition(or type concentration) - data, operations and references can quickly be concentrated into groups, and put together into parent functors, this is done with either + or - operator, substraction and addition, where as information in the latter operand of the latter operator is negated a+(-B)

And lastly, for anything to be compiled, BORK needs physical function calls and data. This is where C++ objects and classes are needed.

[kedaman]

Readability:

BORK is very difficult to understand if you've programmed OOP style.

Basically, to make code readable, the only thing you need to do is be creative with names. In C++ you need couples of names for many things, Class-Object like: int x;
in BORK everything is a functor, so there's only one name per concept, which makes BORK efficient in name using, C++ allows you to name your variables freely and forces you to object oriented programming. In BORK you don't need two names for the same thing, you don't need an object and a class of everything, although you can do it using functor nesting.

Anyways, there are only 5 essential operators operators in BORK, + - * / and {} and only one concept, the functor that does everything, instead of tons of concepts in OOP that does almost similar things.
There are of course the large set of C++ operators for operations on integrated datatypes, and they really imply a physical interface.

I'll try to come up with some more code examples.

[kedaman]

Real World problems:

I've concluded that all information can be represented in a mathematical expression, in a disjunction as a vector, or mixed form as a functor tree as in BORK. (The compiler would straighten out them to vectors for ex. assigment operations)

Further on, BORK is not only for instructional purposes, you can have a set of statements (information in form of a functor tree or a vector but no other programming language has been able to solve real world problems. Mathematically this is possible trough gauss elimination of a matrix of information vectors.

It would work like this:
The compiler is backed up with a library of information axioms (in form of vectors) then the programmer opens a new workspace and start to make statements like "my car is blue and my girlfriend doesn't like it" or "I've got $31 to spend tomorrow on the festival" or "The collector voltage over the transistor is 2.5V" or "Wake me up 8 in the morning each tuesday except 24.5" and the compiler will format the information, sort out instructions and plain data, and then set up an equation system, solve it and produce an application. If there's no instructions it would just generate a solution for the system, if ithe programmer just was asking for such.

Anyways, this is pretty much a theoretical idea. It could be usefull for solving simple linear problems, maybe not complex every day problems. Maybe BORK will be the engineer of the future.

[parksie]

Wasn't prolog designed to do things like that?

[Pix]

bork

[kedaman]

´might just be, I never did any prolog, the sound of function based repelled me in the first place I might have a look at it

[parksie]

Originally posted by kedaman
´might just be, I never did any prolog, the sound of function based repelled me in the first place I might have a look at it

It's rule-based, and it's quite old now

You do things like (this is definitely not the right syntax!):

can_have_car(uk, 17)
can_have_car(usa, 16)
can_have_car(passed_test)

location(bob, uk)
age(bob, 17)

? can_have_car(bob)

...or something like that. I have only the vaguest recollection of how the hell it works

[kedaman]

yeah, that kind of stuff

bob{
	age*17
	location*uk
}
can_have_car{
	,/age==17&&,/location==uk
}
can_have_car{
	,/age==16&&,/location==usa
}
main{
	cout*can_have_car*bob
}

[CornedBee]

can_have_car{
	,/age==18&&,/location==austria
}

[kedaman]

same here

can_have_car{
	,/age==18&&,/location==finland
}

[kedaman]

Ok, I decided to write a game in BORK just for demonstration purposes as well as further developement on syntax:

//Mastermind by Kedaman
//BORK example

namespace mastermind{

    include{ iterator iostream list dipslaystring randomise}

    config{
        colors=8
        set=5
        maxboardset=24
        mode=hard
    }

    main{                                    //Entrypoint functor
        startscreen
        computer/choose
        try{
            gameloop user/turn*iterator  *iterate
        }
        catch gameover{
            
            endscreen*,/gameover
        }
    }

    color{ Red Green Blue Brown Orange White Black Yellow Puce Marigold Turquoise Aquamarine Ochre }
    IndicatorColor{ Null Black White }

    clist alias    list*config/set
    blist alias    list*config/maxboardset

    peg{        color*map* dipslaystring+int}
    pegs{        clist*peg}
    pegboard{    blist*pegs}

    indicator{    IndicatorColor*map* dipslaystring+int bool*map*IndicatorColor{false==Null true==White} }
    indicators{    clist*peg}
    indicatorboard{    blist*indicator}

    gameboard{ pegboard indicatorboard }    

    user{ pegs turn=0    }
    computer{ 
        pegs
        choose{.*randomise}
    }


    gameloop{
        if (turns==config/maxboardset)throw gameover*!success
    
        cout* "Enter "*{config/set}*" numbers"*endl
        cin * user/pegs / iterate
    
        pegboard/list * user/turn = user/pegs                //put the pegs on the gameboard
        result alias gameboard/indicatorboard/list*user/turn        //shortcut to this turn's results
        (tempcopy=computer)/pegs/iterate                //make a copy of the computer's pegs
        (if(result=user==tempcopy) {user/pop tempcopy/pop}         //search for syncronous pegs,
        )/pegs/iterate                            //assign white indicators and pop off those pegs
        if (tempcopy/pegs/isempty) throw gameover*success
        (
            if (!result)if(user/find*tempcopy/pop){            //search for asyncronous pegs
                user/pop indicator==Black}            //assign black indicators and pop the pegs
        )/pegs/iterate
        if(config/mode==hard)gameboard/indicatorboard/sort        //flush them in hard mode
        
        (cout*{gameboard/indicatorboard}{gameboard/pegboard} )/iterate    //display all of the gameboard
    }
    StartScreen{
        cout*"This is master mind, try to figure out what colour are choosen for each peg"*endl
    }
    EndScreen{
        if (success)
            cout*"Congratulations, you made it in"*{user/turn}*"turns"*endl
        else
            cout*"Congratulations, you're damn stupid, didn't make it in "*{config/maxboardset}*" turns"*endl
    }
} 

[parksie]

When it gets written

[kedaman]

There's no hurry with the compiler, I'm actually going to think about a fitting IDE, that would show the expression simplification as you type (with autocomplete listbox) and a maybe treeview explorer for expanding the functors.

The compiler itself can't be a hard issue. Essentially everything will inline unless you explicitely point out which functions should not, within either the caller or callee. Note between caller and callee, you can share code and variables. So each call is a compromise, and so is each instantiation of a functor, a compromise between the obect and the class.

For instance looking at the randomise functor, it operates on it's parental object, sort of a member function you add into a class when you need to randomise it. iterate operates on a loop expression and so on..