search

PyHP-pph / PyHP_pph

This repository serves as a centre for collaboration on the PyHP++# language. It will also include a functioning interpreter and compiler for PyHP++# once the standard is finalised.
https://www.reddit.com/r/PyHP_pph/
GNU Affero General Public License v3.0
23 stars 3 forks source link

Parser implementation #7

Closed as-com closed 7 years ago

as-com commented 7 years ago

Although the standard is yet to be finalized, ratified, and certified by the Committee, given the suggestions and ideas floating around, I expect that this language is going to be horrendously difficult to parse.

It appears that nearley would be a good fit for parsing such a language, so our first PyHP++# interpreter would be referred to as "PyHP_pph.js". Any thoughts?

ghost commented 7 years ago

Horrifyingly, we've already made the decision that the compiler-interpreter-compiler has to be written in PHP.

ghost commented 7 years ago

It's not finalized, so we could drop it in favor of having PyHP_pph.js

Boscillator commented 7 years ago

If we do decide to force people to write the cic in PHP, I found this library for parsing grammar in php. However, I agree, we should remove the php requirement. No actual language spec specifies and implementation language, and we want to make this look as serous and official as possible.

PumpkinSeed commented 7 years ago

Maybe in Golang?

ghost commented 7 years ago

I think nearley would be a good idea, it will make things easier for us (even though JS is just as stupid an idea for a CIC as PHP). I also agree with @Boscillator that no actual language spec specifies implementation language, however there's nothing wrong with being first :)

prydt commented 7 years ago

I would prefer Golang or JS for the interpreter, just so we will be able to make it faster, and with more libraries / support.

Kampfkarren commented 7 years ago

I just got a lot of work done on my CIC written in Python 3, here. It hasn't fully implemented the spec and has a lot of warnings for things not yet implemented in the spec, but it's the first working CIC so far.

ghost commented 7 years ago

We should allow multiple. The CIC developers should be able to choose the language that they work in. This means:

a) Everyone is happy with the language they're in, and b) There are multiple CICs in varying stages of completion - this makes things much harder for the programmer, especially if the CICs themselves don't have documented support for each part of the specs.

ghost commented 7 years ago

As long as they are run in a WinXP VM on WinXP everything should be fine.