Javascript port about lala-lang

[neko-para]

I've support both now. I have to say nearley is a good tool.

binder -> null
    | _ symbol _ binder_equ _ value _ ";" binder
    | _ symbol_s _ binder_equ _ block _ ";" binder
    | _ "<" _ symbol_f _ ">" _ binder_equ _ block _ ";" binder 
    | _ "<" _ symbol_f _ ">" _ binder_equ _ csymbol _ ";" binder

Now I only need to write things like those above. It really saves my time😄

[neko-para]

Everything about nana comes from the proposal.
I have to say that quite a lot of details aren't mentioned. e.g. Does string literal support more complex escaping? In nanajs, I support single-char-escape (\n) and 4-hex (\u0001). Hope you could make it clear later.

[neko-para]

There's a new problem. About the gate, will there be a token between symbols?

aba = |param1 param2| (
    param1, param2, param1
);
aba 1 2

Is there any token between param1 and param2 inside ||?

[neko-para]

Another problem. Does it support parentheses inside expression?

(
    1, (2+3)*4
)

Will (2+3) be parsed as an tuple and caused an error? Otherwise how to distinguish it?

[LighghtEeloo]

Hi neko-para!

First I want to appreciate you for your interest on this project. Happy to see you!

I'm sorry that the doc is missing right now. The current proposal you're relying on is more of a cheat sheet than a descent language spec. I'll formalize the concepts in a few days, and you can expect a workable one tomorrow night.

As for the details,

Does string literal support more complex escaping?

Somehow yes. It supports anything the target language (like json) supports. In fact all my lexer does is it contains anything between " and [^\\]", and directly passes it down to the target language.

About the gate, will there be a token between symbols?

Yes. The current gated block syntax is

|x, y| ( x + y )

, which is similar to Rust's closure syntax. The , is added because space would lead to the intuition of a function application.

Does it support parentheses inside expression?

Yes. Tuple exists because it binds multiple values into one. So any depth of tuple with single expression inside will be treated as the expression itself.

(((((x+y))))) // equals
x+y

In fact, nana doesn't directly distinguish "an expression wrapped by a pair of parentheses" because unary tuple takes care of it.

Of course, all above are just suggestions. You may give your opinion, and I'll be happy to discuss.

Nice day. (❁´◡`❁)

[LighghtEeloo]

Also, I think a spec might be hard to read. Maybe a blog style description may serve as a better option?

[neko-para]

(a+b)*c
This () don't create a block, does it?
Then how to know whether it should be an () for expr or for tuple? near to a sign(e.g. * / + -)?

[neko-para]

At first, I fold the recursive ()
(((a))) every () have only one block child, so I can just fold that. But is there any way to distinguish whether the () is a part of an expression or not?

[neko-para]

I've had a solution.
The () for expression is a standalone expression, so it is a value instead of tuple, and we can just perform calculation on it. This may provide a good explaination.

[neko-para]

Another problem.

{
    fun = |x, y| (x + 1);
    fun 2 -1
}

There are two types to understand:

• fun (2-1)
• fun 2 (-1)
  How to distinguish this?

[neko-para]

I suggest to use certain parenthese to restrict the param of gate
e.g.

{
    fun = |x, y| (x + 1, y - 1);
    fun<1, 2>
}

As currently <> is only used in multi var expose, there won't be ambiguity.

[LighghtEeloo]

I've had a solution.
The () for expression is a standalone expression, so it is a value instead of tuple, and we can just perform calculation on it. This may provide a good explaination.

Yes, I agree. Tuple is designed to combine multiple values and pass them around, like in python. It makes no sense in making a "tuple" containing only one element. I think your reasoning is correct.

Also I'd like to mention that I plan to use () as unit type. You can treat it as null.

[LighghtEeloo]

I suggest to use certain parenthese to restrict the param of gate
e.g.

{
    fun = |x, y| (x + 1, y - 1);
    fun<1, 2>
}

As currently <> is only used in multi var expose, there won't be ambiguity.

Well, I don't think that's necessary. One can always write

{
    fun = |(x, y)| (x + 1, y - 1);
    fun (1, 2)
}

This might be confusing if one hasn't touched any functional programming style. Here fun only takes one parameter, which is a tuple, and breaks it apart to (x, y) where x and y are just separate binders.

[LighghtEeloo]

Another problem.

{
    fun = |x, y| (x + 1);
    fun 2 -1
}

There are two types to understand:

• fun (2-1)
• fun 2 (-1)
  How to distinguish this?

Ouch. Integers are always such a headache, aren't they.

My current plan is to treat -1 as an negative integer, and ...- 1 as an operator. So

fun 2 -1 // ((fun 2) (-1))
fun 2- 1 // (fun 2) - 1
fun 2 - 1 // (fun 2) -1

Note that the function application has higher priority than any binary operator. (!)

In fact, my impression is that most languages' lexers do this -1 thing, but I'm not 100% sure.

[LighghtEeloo]

Hi.

Just updated perhaps one third of the proposal. The link is here.

I hope that may help.

[neko-para]

After reading the new proposal, I'm quite confuse.

(
    factorial x := (
        ? x                         // what is x?
        | 0 -> 1                    // if x is 0
        | _ -> x * factorial (x-1)  // else
    );
    factorial 10
)

As mentioned in it, this is the function. Then what's the difference between gate and function?
In the past, I think that nana only support gate, and the codes above will be things below.

(
    factorial := |x| (
        ? x
        | 0 ->1
        | _ -> x * factorial (x - 1)
    );
)

P.S. As I think the condition is a part of lala, I treat all | as parenthese in nanajs.

[LighghtEeloo]

The code pieces above are equivalent. Since writing gated blocks all the time could be tiring, the traditional function way of writing it could be easier for new comers to use.

In fact, just in introduction:

2. You may write functions in a more confortable way, which will also be translated to the gated block form:

(
    add x y := (x + y);
    add 18 24
)

---

As I think the condition is a part of lala, I treat all | as parenthese in nanajs.

Feel free to do so. We can always write a minimum viable product and scale up based on that.

When I was trying to write the sample code it turns out that it's too hard to do anything "meaningful" if condition is deprived. But it's indeed a bit too much if we just want a small language that can deal with variables (binders).

Strictly speaking, of course I can use lambda calculus, since I've already introduced gated blocks, but that would be hard to use 2333. So I borrowed this grammar. But it's not a necessary part. So you can do whatever you think is reasonable.

[neko-para]

I rewrite the parser using nearley. Now the grammar won't affect lot.
But here's another question: what syntaxs do condition choice support?
I've seen things like | [x] + xs to pick up the first item inside a vector. But there isn't any explaination about it.
Can I use | xs + [x] to pick the last item? Can I use this to pick tuple? (or use | (x) + xs?) How about | x1 + x2 + x3 + [x] + xn?

[neko-para]

Currently the parser works fine with most of grammar(except condition, as mentioned above, I have some question about it).

[LighghtEeloo]

LOL what a coincidence. We've just commented at the same time.

I'm writing the pattern language part, and it will soon be done. But I think must of you intuition will fit mine, so nothing special.

I think a QQ group could be better at unofficial discussions: 760133331. Feel free to come :-)

[neko-para]

I have to say that I cannot find that group.