haasn / -g-pl Goto Github PK

Should we allow top-level expressions other than >implying or should we restrict it to those? The practical effect of this is, do we force everybody to create an OP function, or do we allow direct code execution?

The pros and cons of both:

Allow only top level implications, force OP functions:

Pros:

• Functions can be declared in any order, the OP function can be at the top and helper functions at the bottom
• The user can name the args variable to whatever he wants

Cons:

• The user is always required to define an OP function, which is generally considered bad for interpreted languages

Allow top level execution

Pros:

• No declaration overhead needed, simple scripts will be simple

Cons:

• Functions must be defined before they are used, so all code must effectively be at the bottom of the file

I just realized that I followed a course about formal languages last year. They didn't teach us about individual implementations though, so I've been reading up on EBNF a bit.
I came across a little tool to make a diagram out of a EBNF grammar, so I ran it on parsing.txt.
However, the script used a slightly different syntax than normal EBNF (no ?'s, white space instead of commas for separation) so I had to rewrite it a bit.
Could someone check if /parsing.png is right?

Recursion is currently not possible due to the way the system works - creating a function will not assign any name to that function, and even if we do so later on via >implying, it's not inside the closure at the time of the function's creation. Plus, it doesn't work with anonymous lambda functions.

So to resolve this, I propose a special form of function call, in which you reference “this”. Eg:

>this [parameters];

For example, a factorial function could look like this:

>implying factorial isn't >function(n)
    >is n 0; TIER: 1
    SHIT TIER: >mul n >this >sub n 1;;;
100% accurate

We're in dire need of some sort of loop expression.

Do you think we should just add labels and goto, for the trolling factor?

It just occurred to me that we have no array, list or vector structure in the draft, and that it is currently impossible to create such a structure by combining elements of the language.
Does anyone have a suggestion?

Still not sure if this is the place to post this, but whatever.

Why not use something other than true/false for boolean? Like OP is a ___ for true.

At the moment, “gb2” works like a “break” statement in other languages does - it breaks out of the current block (eg. conditionals, loops, evaluation blocks, functions etc.). This, however, means that there's no equivalent to a “return” statement.

We will effectively have to create a second alternative to gb2 and have one serve as a “break” and the other as a “return”. Ideas for what this “return” (or “break”) statement could look like?

Writing a full blown TIER list for a simple comparison is often a bit tedious, especially due to the 100% accurate terminator needed all over the place.

Should we introduce an alternate, shorter form of conditionals, eg. for one-liners?

>implying it isn't >function(x) >... looks like a clusterfuck, and I though of a different way to define functions, based on:

Install a program on Windows:
>...
>...
OS X, Linux:
>...
>...
100% accurate

Assuming this is code, this is the function "Install a program" - one form with a parameter as "Windows" and the other form with two parameter named "OS X" and "Linux"

factorial on n:
    >is n 0; TIER: 1
    SHIT TIER: >mul n >this >sub n 1;;;    inane The >this ; form calls itself
    100% accurate
n, p:
    >is p 1; TIER: n
    SHIT TIER: >mul n >this >sub n 1; >sub p 1;;;
    100% accurate
100% accurate

Hey,

OP from the original thread here. Once the language has been defined I'll be glad to start making a finite state machine and start on the lexical analyzer.

Things we'll need for the lexer
-list of reserved words
-type definitions (looks like we have most in the draft.txt)
-identifier definition (most likely C style, can't start with digit)
-comment definitions (check)

And what language will the compiler be written in. I know java best, but any C-like language I could manage. C would be my language of choice only because I want to get to know it better. Thoughts?

As per the current draft, this would look something like

>implying OP isn't >function (
    >implying x isn't 5
    >implying y isn't 3

    >mfw >add x y
    gb2

    inane This will never execute:
    >mfw "foobar"
)

How does that look?

I'm not sure how to commit code to a public github repository without forking it, so I'll post this in the issues section (if someone want to explain how I should do it that would be great).

I read the draft, it looks great.
Since we got rid of the ;'s to terminate a line, I'd like to introduce the (1/?) statement (Used when a post is to long for the text field and is continued later) to continue on the next line:

implying foo isn't "This is a string (1/?)
the string continues here (2/?)
and ends here"

The (n/?) statement would be removed by the compiler and the following new line would be inserted into the string instead of interpreted as the end of the statement.

I'm not sure if we should force the ? to actually mean something or have (n/n) on the last line.

I loved your addition of GNU/Linux to escape Linux on the code block by the way.

(No indentation in blockquotes, github parses > as a multiline quote)

= Switch =

A switch statement starts when the first case is encountered and does not require a separate 'begin' statement. Cases are TIERS and a case ends when the next one starts, the entire block is closed with '100% accurate'.

implying foo isn't 5
foo is 5 TIER: inane I'm not sure on 'is' versus '=', but I'll use 'is' in this example
>mfw right
foo is 2 TIER:
>mfw you're wrong
100% accurate

Nested switch statements can be made by starting the new switch block with 'furthermore,' (a more memed-out version of this would be better) and are again ended with '100% accurate' like this:

implying foo isn't 5
foo is 5 TIER:
>mfw right
furthermore,
foo < 4 TIER:
>mfw but that's where you're wrong
foor > 4 TIER:
>mfw OP is a reasonable person
100% accurate
foo is 2 TIER:
>mfw you're wrong
100% accurate

Should we implement an operator table (eg. fixivity and associativity), or should we just leave everything as functions?

The advantage of functions: Very easy to implement, very easy to parse with existing rules
The advantage of operators: Easier to understand for non-lispers and newcomers

Functions could look like:

>mfw >mul 3 >add 2 5

Infix could look like:

>mfw 3 * (2 + 5)

Thinking about adding this. Example:

>implying addfive isn't >add 5;

Basically, what would happen when you call a function with less parameters than it requires is that it returns a new function, which takes whichever arguments are left. Basically, it would sort of be like writing:

>implying addfive isn't >function(y) >add 5 y;

The only difference is that with partial application, the already known parameters would be determined immediately. So it would be more like:

>implying addfive
{
    >implying x isn't 5
    >implying addfive wasn't >function(y) >add x y
}

But either way, the only downside this would have is it makes some errors harder to catch (eg. you forget a parameter, and get a ton of subsequent errors because you'd be passing around uncomplete functions instead of values)

It still has a few merits though, mostly for the sake of brevity.

Do you think it's worth it?

On second thought, I'm adding a delimiter to function calls, for which I'll use ‘;’ for now.

The problem is, if the number of parameters for a function determines the way it's parsed, then we need to know the value of a function during the parsing step, which means we can't build a complete AST before execution, so we'd have to parse stuff in realtime.

This causes two drawbacks: 1. We can't use a standard EBNF or Parsec-based parser library, 2. We can't JIT or compile the language at all.

If we introduce a ; as proposed, this gives us several advantages:

1. We can build ASTs, JIT or even compile the language - speeding up execution noticeably in all three cases
2. We can introduce variadic functions or optional parameters very easily

And two cosmetic drawbacks:

1. The syntax is a bit uglier, >mfw "foo"; instead of just >mfw foo
2. We can no longer use ; inside variable names

What do you think? I'm going to add it to the spec for now, since my current implementation breaks / is not really possible otherwise, unless I constantly re-run the parser and move expressions between blocks at runtime, but this would be very hard to do and also very slow.

I just created a thread.
http://boards.4chan.org/g/res/20962666