Show HN: Mys – an attempt to create a statically typed Python-like language | Hacker News Reader

Show HN: Mys – an attempt to create a statically typed Python-like language

github.com

50 pointseerimoq56 comments

I was once toying with the idea to create a statically-typed Python-like language, and I had the perfect name for it: Typhoon... ;)

Alternate idea: a language called Typon in which the compiler paves over typos of keywords and symbol names.

Like a whole language built on the fuckit principle.

I thought that was Perl... ;P

Given that the OP is the github project owner, are you aware of https://chocopy.org/ ?

You might want to also look at Shedskin, https://github.com/shedskin/shedskin which converts implicitly typed Python programs to C++

Previous discussion of ChocoPy is here, https://news.ycombinator.com/item?id=20957420

No, I am not aware of ChocoPy. Thanks for letting me know.

Shedskin uses the Python interpreter if I remember correctly. I aim not to.

It can make both standalone executables as well as extension modules that can be loaded into cpython2.7

And at mypyc https://github.com/python/mypy/tree/master/mypyc

This looks promising indeed. Thanks for sharing.

For the sake of completeness, might as well mention Nuitka [1] (another Python -> C compiler), Cython (Python-like language that compiles to C), and Numba (LLVM-based JIT compiler for a limited subset of Python).

[1]: http://nuitka.net/

[2]: https://cython.org/

[3]: https://numba.pydata.org/

In the special purpose for computation (like Numba) department, but more general: TorchScript from PyTorch https://pytorch.org/docs/stable/jit_language_reference.html#...

It doesn't compile to C but to an IR, but some ideas around typing might be similar.

Question for the OP seeing as this is a Show HN: how does this compare to Nim (https://nim-lang.org/)?

It's a wide question, and I don't have a good answer. One obvious difference is the syntax. I prefer Python's syntax over Nim's, but at the same time I find Python slow sometimes and hard to use in embedded systems. I'm aiming to create something similar to Nim's toolchain to address that.

P.S. Since you’re using C++ shared pointers, you might want a cycle detection. But like Nim’s new ARC you can let the programmer beware and ensure their programs don’t produce cycles. It seems handy to allow pure RC’ing for embedded devices.

I'll keep this in mind.

Not OP, but a big Nim fan. I think Nim has made a mistake by marketing itself as Python inspired. I know why it does so; Python is a very successful language and as a niche language, Nim wants to associate itself with an established one. But in my experience, Nim has a very small overlap with Python. It is whitespace significant, prefers short words to symbols for operators, and has a robust stdlib. But if you look at the actual language semantics, or even the keywords, Nim is not really related to Python. I'd go as far as saying Nim is more similar to a Lisp than it is Pythonic (which works fine for me, as I prefer Lisp to Python).

All of this to say, the OPs language seems much more Pythonic. The key words, the built in functions, the class system, all seems designed to match Python as closely as possible.

It took me a couple of weeks to realize Nim’s semantics are really different. Despite that Nim feels like an alternate reality of Python 2 -> 3 that went more lispy and a bit Pascal-ish. It gives me the old Python 2.7 vibe. Though I’d still prefer ‘def’ to ‘proc’ but that’s pretty minor to me.

It’s interesting to see how well the typed Python syntax maps to a static implementation of Python. The speed should probably be a lot faster than CPythin too for many cases.

The really nice thing about proc is that emphasizes that they are in fact procedures, rather than mathematical functions - a distinction that becomes more relevant as FP gains mindshare.

> We don’t need a GC because RC

    L = []
    L.append(L)

I am working on something similar, although with a different focus (mobile coding): https://github.com/stefanhaustein/tantilla

P.S.: Might make sense to try to get to a common type-safe language spec?

Nice job.

I don't understand the question. Can you rephrase it? =)

It might make sense to try to support the same subset of Python in both projects. On the other hand, this might make experimentation harder... And there seem to be many differences, for instance I am trying to move towards async/await... But there might also be areas that could be easy to get consistent, e.g. how local variables are declared...

p.s. And I wasn't aware of Cocopy either. Having a list of similarities and differences of all three might be useful...

I like the idea. If our languages are similar it could even make sense to stop developing one of them and focus on the other, but that's probably far fetched. I'll have a look at yours to get a better understanding of what it looks like and where it shines. Maybe we meet again =)

Do you have any objections against using google drive for an initial list of similarities / differences? I think the comment function could be useful....

Please do, but I won't promise I will contribute a lot, so don't be disappointed. =)

Cython is a great tool for this. It’s a superset of Python with full static compilation support for native CPython or for pure C or C++ extension modules.

https://cython.org/

There is also http://strlen.com/lobster/

Rust-like borrow checking with a Python-ish syntax, compiles to C++ or Wasm

Similar and relevant:

Crystal: https://crystal-lang.org/

Sorbet: https://sorbet.org/

I love this.

I have nothing else to say except that I want this to happen. Python is an amazing language which is missing two things - static types and speed. I starred your repo and am looking forward to seeing it progress.

This looks cool. Is there anything specific you're trying to do with Mys that another language didn't do? Nim comes to mind as being in a similar space.

Small nitpick about the title: Python is strongly typed.

I would call Python untyped

You would be wrong. Try adding a string and number together. That's a type error. Unlike in JS or C, where a lot of these conversions are implicit and only warn if anything.

Python determines the types at runtime, but it is very clear about what few operations you're allowed to do on any given set of types.

I wouldn't call C untyped because implicit conversions happen all the times. It's just that it assumes that since you declare your variables with a type, when you assign them, you know what is going to happen.

I'm not calling C untyped either. It's weakly (statically) typed.

Barely anything is truly untyped nowadays, I can think only of assembly.

I can import this with no errors, so Python is untyped:

    def foo():
      return 1 + "2"

Another example showing Python is untyped:

    x = 1
    x = "2"

x clearly has no type. No variables in python have types.

I'm not sure if you're being serious, but Im going to assume you are.

Your first example demonstrates that python does not have compile time type checking

Your second example demonstrates that python variables can dynamically change types.

  >>> 1 + "2"
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'int' and 'str'

https://dev.to/jiangh/type-systems-dynamic-versus-static-str...

What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research.

The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and untyped languages may overload the addition operator.

For those downvoting aidenn0's comments, I was surprised to find that "untyped" is indeed a common term that includes what many people (myself included) call dynamically typed. See the three top-voted answers to this Stack Overflow question, one of which includes a citation from TaPL, a standard text (emphasis added):

"A type system is a tractable syntactic method ... Terms like 'dynamically typed' are arguably misnomers."

https://stackoverflow.com/questions/9154388/does-untyped-als...

I still prefer the term dynamically typed, because there are useful distinctions about value types to be made among such languages, such as those described in striking's link.

I think this discussion is frustrating because your explanation seems to be based on well-defined terms of art, as opposed to the colloquial terms like "weak" and "dynamic".

It's like the discussion is untyped, and the downvotes are runtime errors that would have been caught if terms were agreed upon ahead of time.

Well, probably not. Nim is similar, but I prefer Mys' Python-like syntax. Mys' toolchain will probably be similar to Nim. That is, generating C/C++ code.

Sorry about the confusion. Mys is statically typed. I changed the HN post from strongly to statically to make it clear.

> Data races will occur when multiple threads uses a variable at the same time, which will likely make the program crash.

... or let the attacker execute arbitrary code.

Isn't Dotty basically statically typed Python? They added whitespace syntax recently and thanks to Scala native it should be possible to have a LLVM backend somewhere down the line.

Why not to just use Cython?

Strongly typed? You mean statically typed?

See "What to know before debating type systems":

http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...

Updated the GitHub repo and the HN post. Thanks.

> Type inference is generally a big win.

I see this claimed a lot, but haven’t seen any evidence.

Might depend on what "win" is supposed to mean in this context. If it's intended to mean "languages with type inference are more productive", then sure, evidence would be nice. If it's intended to mean "type inference helps cut down on the need for explicit type annotations", I don't think evidence is really necessary.

I think the claims might be the evidence you're looking for.

Not sure if this qualifies as evidence, but a quick search shows there are papers exploring the topic of whether type inference is a "big win" or not.

Benefits of Type Inference for an Object-Oriented Real-Time Language

https://www.researchgate.net/publication/220391749_Benefits_...

EDIT: Granted, this particular paper may be more claims without solid evidence.

Before making Yet Another Language, I'd like to see a good analysis of the options and trade-offs they offer: what does each design choice make easier and harder. There is probably no free lunch, but maybe we can find a better lunch by balancing things carefully.

For me it's pretty simple. I love Python. I like speed. I like embedded. This is an attempt to take advantage of Python's type hints to create fast and hopefully small binaries that can be executed on embedded devices limited amount of resources (both CPU and RAM).

There are probably other languages that would serve the same purpose, but oh well, I can't resist creating another. =)

Have you look at mypyc?

https://github.com/python/mypy

Its a compiler that support subset of python and mypy's team including Guido work on it. It would be great if this kind of efforts have been done on more realistic project.

It compiles statically typed Python modules to CPython C extension modules. I do not know the details, but it sounds like that's a major difference to Mys.

Reply on news.ycombinator.com