search

haasn / -g-pl

/g/ programming language
13 stars 2 forks source link

Function call delimiter #14

Closed haasn closed 13 years ago

haasn commented 13 years ago

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.

yate commented 13 years ago

I'm having trouble understanding why the number of arguments affect how it's parsed. I've only studied one way of parsing, and that's top down LL(1). It seemed to me as long as the grammar of the language didn't have any ambiguity, was context free, not left recursive, then the parser would be able to handle it. Also what do you mean by the value of the function, it's name, memory location?

I think I'm thinking about it differently because I'm imagining it being compiled and not interpreted, which my implementation might be.

haasn commented 13 years ago

It seemed to me as long as the grammar of the language didn't have any ambiguity

The problem here is that the grammar of the language HAD ambiguity.

Previously,

>foo >bar bat baz

was ambiguous between the following:

And the actual result would be determined based on how many parameters foo and bar take, respectively.

Now, with the addition of semicolons, it would be

>foo >bar bat; baz;

Which makes it clear that foo(bar(bat), baz) is meant, and nothing else.

yate commented 13 years ago

ah i see, so how the hell does perl do it lol? there is always the option of adding parens, which I'm not entirely against.

haasn commented 13 years ago

perl is interpreted and slow as shit for a reason :)

Edit: Doesn't perl force parentheses where it would be ambiguous otherwise?

haasn commented 13 years ago

For the reference, my implementation is basically working. The hello world compiles except for three parts:

  1. I don't have a comparison function yet so >is name "nand" fails
  2. I don't remove comments yet so those fail
  3. I don't have any “gb2” yet so that fails

Otherwise, the rest is working fully.

haasn commented 13 years ago

Update: I added a comparison function now, so now the only issue I still need to solve is comments and gb2. :)

yate commented 13 years ago

damn you work fast

haasn commented 13 years ago

I'm closing this. If we get any better ideas later on, open a new issue.