Peregrine Update - The Python-like programming language that's as fast as C++

#programming #cpp #python #showdev

"Blazing-Fast Language for the Blazing-Fast World" - Peregrine Motto

Introduction

Hey guys, it's been a long time! If you don't already know me, my name is Ethan and I'm one of a few Peregrine Programming Language developers. Over the past few months, we've managed to surpass the progress in the 1st write (code for the 1st write has been deleted) and add new features. This post will be discussing the progress that has been made.

About Peregrine

If you know Python, you know how easy it is. However, it also comes with a big downgrade. Python is slow, and I'm pretty sure every python developer knows this by now. This is kind of annoying. That's where Peregrine comes in. Me and 11 friends have been working on Peregrine for the past few months. Peregine's syntax is very similar to Python's, and it gets trans-compiled to C++, thus making it as fast as C++. Some of you may know Peregrine as the "Language that's as fast as C", however we've decided to trans-compile it to C++ instead of C.

New Language Features

Class

After a lot of work, classes have been added to Peregrine. They essentially act the same way you'd expect them to act in python. Here's a quick example:

class Vector3:
    x: int
    y: int
    z: int
    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

def main() -> int:
    v: Vector3 = Vector3(1, 2, 3)
    printf("x=%d, y=%d, z=%d", v.x, v.y, v.z)
    return 0

This is pretty self-explanatory. If you put this code into python, you'd just have to change printf to print and change the string formatting and then it works like a charm.

Classes also have magic methods that allow operator overloading, iterators, context managers etc.

Enum

Enums have also been added to Peregrine. They work like any other enum in any other language.

enum RGB:
    RED = 144,
    GREEN,
    BLUE = 200,
    OTHER = GREEN+9,

Here, RGB.GREEN = 155, because the value is defaulted to the previous value + 1. RGB.OTHER = 164, because 155+9=164.

Union

Unions, like in C, C++ etc... are data types that allows the storage of different data types in the same memory location.

union abc:
    a: int
    b: int
    c: int

def main() -> int:
    _x: abc
    x: *abc = &abc
    x->a = 1
    x->b = 2
    x->c = 3
    return 0

NOTE: you don't have to create a pointer to a variable of type abc in order to assign and access it's fields.

custom decorators

Peregrine supports user-defined decorators, just like Python. Here's an example that's taken from can_comp.pe, but slightly modified to improve readability (that file is hardcoded):

type a = def(int)->int
type g = def(int)
def decorator(func: a) -> g:
    h: int = 9
    def value(c:int):
        h = 8
        printf("%d\n", h)
        printf("Answer is %d\n", func(c))
    return value

variable: int = 9

@decorator
def dec_test(x:int) -> int:
    return x*x

def main() -> int:
    dec_test(10)
    return 0

As you can see here, you must define a type for the function being decorated and a type for the return type of the decorator (should return a function).

The program would output Answer is 100.

You can find some more code examples in can_comp.pe

Planned features

Here are some features that are planned to be implemented into peregrine before the first release:

Structs
Python ecosystem in Peregrine
- You will be able to use any python module in Peregrine
Imports
Standard Library

Conclusion

Peregrine is planned to release version 0.0.1 sometime between March and April, so make sure to show some support by starring the repo and make sure to press on the "Watch" button so you don't miss any updates.

We would greatly appreciate any contributions, so if you find something that you can improve, open a pull-request! You can also check out our open issues

Thanks so much for reading!

Top comments (5)

jacksonhead • Jan 18 '22

I checked the repository. I was curious about the code design/quality/overall feel.

The first file I opened was Peregrine/lexer/lexer.cpp. In this file (currently from line 92) there is a huge if-else structure. In case you have such a huge if-else most of the time there are nicer solutions to implement it such as creating a dictionary. Maybe I am wrong here and this is the most optimal solution so I decided to check other stuff here too.

Next thing I checked was the lexer function in this file (currently from line 219). The end of the function is at line 1129. How do you plan on testing this function? What about maintenance? Debugging?

I checked the test folder. To be specific I was interested in the automated tests so I only checked the ci folder. You automated test coverage is about 0%.

I did not continue with the code. At this stage I believe if you don't begin to think about code quality and testing you will have a huge maintenance burden at hand.