[Zero]

I have this draft. I'd love to hear your thoughts guys.

[Zero]

|Black<



// declaring variables

var(
    int x y
    str txt
    func(int) factorial(int)
    flt unit volume
    type cat
)

/*  the general schema is var( type type other type other other )
 *  one series of "other" identifier is typed by the preceding type or pipe-type
 *
 */



// assignment

x: 5
txt: "hello"
volume: 30.0 cm3

/*  programming languages all use = as assignment
 *  using : instead of = is simpler and natural (to me)
 *  there's no space between the left side element and colons
 *  it's easier to parse
 *
 */



// function declaration + definition

func(int) fib(int n)(

    ret ife < n 3
        1
        +   fib(- n 1)
            fib(- n 2)
)

/*  the type of a function is func()
 *  the type of the return value goes inside parentheses
 *  for example func(int) is a function that returns an int
 *
 *  everybody knows that variables must have explicit names
 *  x is a bad name, because it doesn't mean anything
 *  who would name a variable "ret"? nobody
 *  so we can use "ret" as keyword instead of "return"
 *
 *  it would be shorter to write "int fib(int n)"
 *  but it would be inaccurate: fib is a function, not an int
 *
 */



// variable declaration + definition

int x(7)
str txt("hello")

/*  writing the initial value between parentheses seems weird at first
 *  but it is consistent with the way we write initial value of functions
 *  the "value" of a function is its body
 *
 */



// source code types

int nacci(12)
$int result( fib(nacci) )

put "{$result} = {result}"

/*  This would print "fib(nacci) = 144"
 * 
 *  $int is the type "source code that yields an int"
 *  $result holds the real value of the variable (the source code "fib(nacci)")
 *  using "result" without dollar executes the source code, returning 144
 *
 */



// type definition

type dog(

    int size(40)
    int hunger(0)
   
    ctrl bark($str speech $int times)(
   
        ife >= times 5
            do(
                cls
                put "woof"
            )
            repeat
                fib(times)
                put .. "woof" speech
    )
   
    func() run(int distance)(
   
        hunger: + hunger distance
    )
)

/*  types are a bit like classes, but simpler
 *  all variables are private (size and hunger can't be accessed from outside)
 *  all methods are public
 *  if you need encapsulation, put functions inside functions
 *
 *  ctrl are half-procedures half-macros
 *  controls don't return values
 *  they don't receive the interpreted value from the caller
 *  instead, they receive the source code from the caller
 *  like arguments on the command-line
 *
 */



// instance

dog maxy(
    size: 50
)

/*  you can override things at initialization
 *  after that, you can only call methods
 *
 */



// accessing methods

maxy.bark "hello ruf" 3
maxy.run(4)

/*  you don't call a control (like "bark") with parentheses
 *  instead, the ctrl arity is used to pick the right number of arguments
 *  "bark" needs 2 arguments, the syntax is light
 *
 */



// type composition

type pitbull(

    type(dog)
    pct ugliness(80%)
    pct strength(99%)
)

/*  importing a type inside another is as simple as this
 *  a pitbull can do everything a dog can do
 *  a type could be composed exclusively of type imports
 *
 */



// interfaces

type Rectangle(
    flt width height
    func(flt) area( * width height )
)

type Circle(
    flt radius
    func(flt) area( * Pi sqr radius )
)

interface Shape(
    func(flt) area
)

enum ShapeSize(small medium big)

func(ShapeSize) classify(Shape shape)(
    ife < shape.area 10
        small
        ife < shape.area 20
            medium
            big
)

/*  classify can work on rectangles and circles because they both implement area
 *  as long as a type implements every method of an interface, it's usable
 *
 *  the area method is without parameters parentheses
 *  this is ok since it has zero parameter, and confusion is impossible
 *
 *  also, we can omit "ret" if the function is a single expression
 *  in an "ife", the then and the else must have the same type
 *
 */



// variable tagging

int maxy'bones(2)

/*  a tag is an additional value sticked to a variable
 *  the syntax is varname'tagname
 *  the tag behaves like a regular variable
 *
 */



// tag set and get

maxy'bones: + maxy'bones 1

txt: "bones"
put maxy'(txt)

/*  the varname-quote-tagname syntax is ok for constant tagname
 *  there's also a varname-quote-openparen-tagname-closeparen syntax
 *  the value of the expression in parentheses becomes the tagname
 *
 */


// pipe-type variables

flt unit weight(30.0 Kg)

/*  a variable can have several types organized in "pipeline"
 *  pipe-type values must be adjacent and space separated
 *
 */



 // clusters

clu stormies 20(

    obs(
        siths
        jedis
    )

    arr(int) foo( repeat 5 rnd(100) )
    spr foo

    on($int msg)(

        put "Node {my.id} Received {msg}"
        ret "ok"
        if > msg 90
            emit "some message to observing clusters"
    )
)

/*  stormies is a cluster of 20 nodes
 *  clusters are a program's macro-organization unit
 *
 *  spr spreads source code in the cluster
 *  ret, in a "on", sends a message back to the msg sender
 *
 *  spr takes
 *      the message, which is transfered as source code (like ctrl)
 *      if the message is a collection, it spreads items
 *
 *  obs / unobs takes
 *      the names of the clusters that should be observed / not observed
 *
 *  emit takes
 *      a value that observers will receive
 *
 *  on() is a node's message event listener
 *  its argument is used for type matching the message
 *  the body is activated only if message type = argument type
 *  there can be several on(), for different types
 *
 *  receivers are chosen randomly among those who aren't currently working
 *
 */



// common types

var(
    void                 // nothing
    enum(r g b) primCol  // enumeration
    int n                // integers
    flt f                // floats
    str t                // strings
    stk(str) s           // stacks
    arr(int) ar          // arrays
    bool b               // booleans
    asso(str int) a      // associative arrays
    pair pa              // augmented cons cells
    poly(int flt) po     // sum types
    pipe(flt unit) pi    // product types
    unit u               // units of measurement
    pct x                // percents
)

/*  short names to make it light
 *  all of this still in evolution
 *
 */

[ivan.moony]

I'd try to fuse vars and functions into a single expression. Variables should be zeroth order expressions. Plain functions should be first order expressions. Functions that take functions as parameters and/or return functions as a result are second order expressions, and so on.

[Zero]

Ok, am I understanding correctly?

var(

    //  contains a number
    float zerothOrder     
   
    //  contains a function that returns an integer
    func(int) firstOrder
   
    //  contains a function that returns a function that returns a string
    func(func(str)) secondOrder
)

zerothOrder: 5.0

firstOrder: func(float n)( ret int(* n n) )

secondOrder: func(func(int) f)(
    ret func(float n)(
        ret .. "result= " f(n)
    )
)

print secondOrder(firstOrder)(zerothOrder)


Honestly, I'm having trouble with an input types / output types confusion.
It's maybe a symptom of bad design?
I'm trying to be as consistent as I can, and I have a feeling that I'm somehow on a "good path". I hope I am!

[ivan.moony]

There is a whole science behind type systems dealing with input / output types, resulting with functional languages. Maybe you could simplify it and apply it to some other paradigm in a different form. It should be fun, but it takes time, I guess.

But maybe that's not what you are seeking for because it brings a certain amount of complexity into a language design.

In object oriented programming, there is a way to surpass object type declarations (like classes in Java) and build objects straight by assigning values (prototype based programming like in Javascript). I wonder if something similar is possible regarding to function definitions, so that strict typing becomes unnecessary.

[Edit]
Regarding to your previous post, variables could be seen as functions with zero parameters, but again, maybe that is not what you are looking for.

[Zero]

I realized I was entering something when I wrote "types themselves are values". I said wow, there be dragons.

Maybe you could simplify it and apply it to some other paradigm in a different form. It should be fun, but it takes time, I guess.

I'm not in a hurry, but do I have what it takes, that's another question. Every language I created was very permissive with types: autocast, no need to declare anything, ...etc. The idea was to throw paint on a wall, with a lot of freedom. I think I'm ready for something more structured now. But I'll still do it my way of course.

In object oriented programming, there is a way to surpass object type declarations (like classes in Java) and build objects straight by assigning values (prototype based programming like in Javascript).

This is how Seme (my previous lang) works. Objects have several protos, and if a slot cannot be found in the object, a lookup is done depth-first in all its protos. There's something similar here (the "pitbull is a dog" thing).
Strict typing and other techniques bring compile-time error feedback. That's the point, but the language still has to be easy to write. It's a balance.

Regarding to your previous post, variables could be seen as functions with zero parameters, but again, maybe that is not what you are looking for.

That's a very nice input, thank you. If a pure function has no parameter, then it's a simple variable indeed. It changes the syntax of the short syntax for variables definition. (I don't know whether my functions should be pure though, but that's another question.)

// declaration + assignment is still the same
var(int somevar): 36

// real (complete) short syntax of variable definition
int somevar()(36)

// syntactic sugar short syntax of variable definition
int somevar(36)

// compared to a short function definition
func() sleep()( print "rrr rrr" )

// syntactic sugar short syntax of function definition
func() sleep( print "rrr rrr" )

[Korrelan]

Exchanging assignment = to : makes it confusing.

Colons should be used for code concatenation, compression.  A small function spread / spaced vertically over many pages just makes the code harder to follow IMO.  Once a sub or Function has been tested compression for readability is important… too me anyway.

Code

Function Split(ByVal s As String, ByVal x As String, ByRef a() As String) As Long

    ee = 0: s = s & x
    
    For d = 1 To Len(s)
        i$ = Mid$(s, d, 1)
        If i$ = x Then ee = ee + 1: a(ee) = Trim(w$): w$ = "" Else w$ = w$ & i$
    Next
    
    Split = ee
    
End Function

 

[ivan.moony]

I knew it's something there creeping in my mind, I just remembered what! 

I saw a genial idea in Martin Löf Type Theory paper some twenty years ago, and I never saw it again, but I liked it very much. They even changed the notation in later papers, like the idea is meant to be hidden. Nevertheless, my work on defining a language took some other path, but maybe you could dig out something out of that idea.

An empty identifier is defined as a plain label:
var

If we want to assign a type to identifier, we have to abstract it from identifier, and we do it by left brace notation:
(int) var

To apply a value to previously typed var, we use right brace notation:
var (48)

We can also abstract multiple types, like:
((int) width, (int) height) box

We apply values in this case in the following way:
box (width (2), height (4))

I think that Löf used a colon for defining first and higher order constructs:
((int) a, (int) b)) aplusb : a + b

And we call the function in a following way:
aplusb (a (2), b (3))        // inserts 5

But in a meanwhile I didn't like this colon, so I imagined an alternative notation for abstraction:
((a + b) << (int << a, int << b)) << aplusb

With applying this way:
aplusb >> (a >> 2, b >> 3)

And now it's real little math, abstracting to the left, and applying to the right. Now I like it.

Don't keep me by every word, it was a long time ago, but the general idea was between these lines, with additional defining some set belonging relations, which I think now they overcomplicated. At the end, they were able to prove theorems and construct algorithms from specifications, so overall experience was very good.

I just thought the idea is worth of mentioning, as I never saw any specific implementation. I'm sorry if I spoiled a fun for you. Anyway, you can always seek for alternative notations if you are up to having fun in discovering things.

[Zero]

That's a real good piece of thought. 

((a + b) ((int) a, (int) b)) aplusb

Don't you think (a+b) is the value? I do think so. It could be on the right side, but we shouldn't have to use colons here. It's just a non-constant (dependent) value, like

((int) a, (int) b) aplusb (a + b)

Colons should be used for code concatenation, compression.

We don't even need a statement separator here, because
- everything is prefix notation,
- things that don"t use parentheses have constant arity.

Here is my version of the Split function, as compressed as I reasonnably can.

func(long) split(str s x *arr(str) a)(

    int ee(0) s: .. s x int d(1)
    loop(
        str i(mid(s d 1))
        ife = i x do( ee: + ee 1 *a(ee): trim(w) w: "" ) w: .. w i
        if = d: + 1 d len(s) exit
    )

Vertical spread is more readable IMO.

Ed: btw arrays will be heretically 1-indexed.    I am an antichrist, I am an anarchist, Don't know what I want, But I know how to get it...

Thank you for your valuable inputs.

[ivan.moony]

Beware of abstraction/application original distinction by relative braces positioning. It works when we abstract from and apply to a label, but which is which in `(...) (...)`? I used explicit `<<` and `>>` to tell it apart.

In my understanding, (a + b) is a type for (int << a, int << b), and altogether, it's a type for aplusb. Hence, ((a + b) << (int << a, int << b)) << aplusb

But, of course, any working setup is acceptable. Good luck

[Korrelan]

I
S
E
E
W
H
A
T
Y
O
U
A
R
E
T
R
Y
I
N
G
T
O
O
A
C
H
I
E
V
E
I
G
U
E
S
S
I
M
J
U
S
T
O
L
D
A
N
D
S
E
T
I
N
M
Y
W
A
Y
S
l
o
l

 

[Zero]

  so modern...

In my understanding, (a + b) is a type for (int << a, int << b)

Is it like saying "int a and int b, seen as (a + b)"?

I read somewhere that a type is a set of possible values. But here, it seems to be more than just that.

[ivan.moony]

In my understanding, (a + b) is a type for (int << a, int << b)

Is it like saying "int a and int b, seen as (a + b)"?

This is the whole type: `((a + b) << (int << a, int << b)) << aplusb`. It reads from right to left: under expression `aplusb`, when you apply int a and int b, what is returned is the rest to the left, and that is `(a + b)`. That generally means that left sides are types of right sides.

I read somewhere that a type is a set of possible values. But here, it seems to be more than just that.

`2 + 3` denotes a set containing only one element, `5`. Some function might also return a set with more elements suitable for further type narrowing (see sum type - it is also denoted by the same `+` sign, but here I'm using only classical mathematical addition. Check out product type also - abstracting multiple types forms a product type). Also, if `a` or `b` are sets (represented as sum types), then the result of `(a + b)` (addition) is a set (represented as a sum type) of all combinations of added each `a` to each `b`.

As you see, all of this introduces a complication to a language, but I don't believe there is official simpler way today if you want to cover the complete typing materia. Just in case, keep one eye on your current personal notes, as something simpler might always pop up.

[ranch vermin]

when you go 2+3,   in explicit form, its 5.

Either way of describing it,  your saying the same thing.  one in the form of the input (beginning, at the sensor),  one in the form of the output (explicit, when the motor turns).   

But I was wondering,  in this transformation of input to output,  is the output more than the sum of its parts in some way?

Its actually less in a way,  because it requires less bits to store,  But as the bits come together from the varying lot of pattern from the beginning, am I getting something that is more than the description of the beginning,  as in,  as its all combining into itself - its gaining extra combinations than what is in the input?

This post is rhetorical in a way, because im answering my own question once ive finished my work im doing at home, id just like to add to the thread, because all languages are doing the same thing.   they take input and then it "computes" into an output,  which is actually "the same thing" in a way.  

making it confusing.

So we are a reflection of the environment, and in a way, its the same thing as your arms moving.

[ivan.moony]

Basic fusion principle: one two protons molecule weights more then two one proton molecules. Energy used to bring them together turns into mass.