Pyth 5

[orlp]

I'm working on a clean-sheet rewrite of Pyth (calling it Pyth 5 for now). Things I'm working on are:

• A totally rewritten interpreter that uses a cleaner lexer/parser/codegen seperation. This should make maintaining easier.
• Proper binary and UTF-8 source support - regular strings are UTF-8, binary strings like ."az" get turned into arrays of bytes: [97, 122].
• The above should also make testing a lot cleaner, and open up the way for a more secure web interpreter, and a Pyth eval function within Pyth.
• A proper integrated comment and indenting system that requires no command line flag. I already have this working and it's unambiguous, and never hurts real code (comments start with whitespace followed by ;, indent is an even amount of spaces at the start of a line).
• Reworking all the functions from the ground up with a solid new type system. No more tuples, and also adding rationals. Sets will only be internal and convert to sorted lists whenever printed/indexed.
• The type system will be more strict and Pyth-controlled. I'm really looking to move away from a Python dictated type system, and work towards a better type system for golfing. Rationals will play a big role in this.
• Adding optional gmpy2 support to make math a lot faster simply by installing it.

If there are any features you think that are questionable about Pyth, speak now. If you have any ideas for radical new ideas/paradigms that would change the language, now's the time! These are the times for radical changes.

My personal candidates that require a good hard look to see if we really want to keep them, or maybe swap less favourable with more favourable names:

• $ is almost never used, and whenever you reach for it it really indicates something else is missing from Pyth. It is also unsafe for the web.
• ' is almost never used, should probably moved to a two-character constant in favor of something else.
• (, tuples will be removed, allowing this to be used for something else.
• /, IMO this shouldn't be flooring division. This should be real division, with something else being flooring division. This is especially obvious once you introduce rationals and reals.
• A, can't recall ever using it, and can probably be replaced by something more general.
• D, this needs some work, right now it's so bad that you're forced to rewrite an otherwise better imperative solution into something functional just so you can use lambdas.

Ideally we'd hold some sort of voting system where we reassign better mnenomics and revalue all functions. Some of the new . functions have shown to be incredibly useful, and some of the single-character functionality proves almost entirely useless.

Other ideas/problems to consider:

• In general imperative seems to be a second class citizen compared to functional for golfs. Can we improve on this?
• Seeing the great work on _F for folding, we can look to do similar things with other block-level characters.
• We need to improve our dictionary support, right now we only have H pretty much.
• As a follow up with the dictionary support, 2D challenges always seem to be a pain with Pyth, perhaps we can better tune our dictionary support for multidimensionality.

[Maltysen]

This this seems really cool. I just disagree in the A, its pretty useful and saved me a char quite a few times with expanding the input into two vars. Im also concerned about the tuples leaving only because of being able to splat the input into U. Everything else seems fine.

[refi64]

Can't , still be used be used for tuples? I just used it recently to save 2 chars.

[Maltysen]

@kirbyfan64 I think that will then be instead used to create a two element list instead.

[jakobkogler]

Pretty much agreeing with most of your points.

Just a few thoughts:

• A feature I really want is a shorter map notation. Currently a map is of the form mf(d)Q. I want to remove the m. The following syntax may be quite handy: @Y$Q (map each index $ in Q to their element in Y, currently m@YdQ), v$cz (evaluate each $ in z.split(), ^$2Q (square each $ in Q). Notice, this is not possible for all maps. We still need to keep the old map m. Otherwise the expressions S+3$Q would have two possible interpretations (Sm+3dQ or mS+3dQ). This mapping would only concern the first parent of $.
• D is really bad. The main reason is, that you need the specify the function name and the names of the parameters. Why not simply reuse L and M, if you need a function. Something like _L (_ can be replaced by something more appropriated) could mean def subsets(b):. Identically like L, but without an implicit return statement. The same for _M and _.N. This would save quite a few bytes.
• Reduce until Exception (???). Not really sure how to phrase that. Look at this snippet, I used a couple days (?) ago: =Y[\a\b[\c]\d\e;Y#=sY;Y. #=sY flattens the nested string. You can write such a thing only, in an iterative style. Doing something like, while being in a lambda function, would be terrible long. I can give a few more examples tomorrow. I exploited the # token for exception catching a few times. Something, that could be used inside a lambda, would be quite nice. Also something like [f(x) for x in Q if no exception], map only the elements, that don't throw exceptions.
• I don't think that gmpy2 would really give any speed. Pyth is slow, because it is often abused for doing lots of brute-force and not because we do a lot of big-number calculations.
• I'm also not really sure about the rational number thing. At least make it a 2-char token, since they can be used really rarely.
• Nobody ever uses dicts in Pyth. Get ride of them completely?

[orlp]

@Maltysen @kirbyfan64

The plan is to purge tuples entirely, so , would indeed be a two element list.

[orlp]

@jakobkogler

I definitely do not like removing dicts entirely. gmpy2 would strictly be an implementation optional detail optimization - if you don't have it installed you'll only lose some performance, nothing else.

My plans for rationals are a bit bigger. I'm actually thinking about having just one 'real' number type. It would be stored as a rational, and printed like a decimal number, with utility functions to get the numerator and denominator and to truncate. Functions taking for example an integer right now would truncate any real number passed in automatically.

[isaacg1]

This seems really awesome.

On the subject of removing all tuples, one (small) advantage that tuples currently have is that They can be easily appended/prepended to lists. e.g. +[1 2)(1 2 = [1, 2, (1, 2)], whereas +[1 2)[1 2) = [1, 2, 1, 2]. We should make sure there's a way to do prepend and append with lists.

[jakobkogler]

Appening with a, prepending with +. Does work already. On May 16, 2015 5:14 AM, "isaacg1" [email protected] wrote:

This seems really awesome.

On the subject of removing all tuples, one (small) advantage that tuples currently have is that They can be easily appended/prepended to lists. e.g. +[1 2)(1 2 = [1, 2, (1, 2)], whereas +[1 2)[1 2) = [1, 2, 1, 2]. We should make sure there's a way to do prepend and append with lists.

— Reply to this email directly or view it on GitHub https://github.com/isaacg1/pyth/issues/111#issuecomment-102567124.

[isaacg1]

@jakobkogler You can't prepend a list to a list, currently. +,1 2]1 = [(1, 2), 1], but +[1 2)]1 = [1, 2, 1].

[jakobkogler]

How about implicit for-loop variable? FYN instead of FNYN and FYFNb instead of FNYFbNb.

[isaacg1]

Actually, we could do that in Pyth as is. We'd just have to switch V<seq> to iterate over the sequence instead of its range.

[orlp]

@isaacg1 I have some design considerations I'd like to discuss. I also invited you (and others are welcome of course) to a Pyth 5 stackexchange chat room.

A couple of points:

• PEP8, do we really want to adhere to the 79 column width? It can get annoying.

• I'd prefer it if we'd turn Pyth into a proper module. A great writeup what that would involve can be found here. In short, we would be able to upload Pyth to pip, allowing people to just use sudo pip3 install pyth to get Pyth, or clone from github and run sudo pip3 install . to install Pyth and get a proper command (so just pyth test.pyth instead of python3 pyth.py test.pyth).

  The minute disadvantage is that for development you have to run either using a module (python3 -m pyth) or using sudo pip install -e ..

[refi64]

The minute disadvantage is that for development you have to run either using a module (python3 -m pyth) or using pip install -e ..

You could always use setuptools and run python3 setup.py develop. That's what I usually do.

[orlp]

@kirbyfan64 That's equivalent, but pip3 has the advantage that you can uninstall using sudo pip3 uninstall pyth.

[refi64]

@orlp But, if you're developing it, you probably don't want to uninstall it anyway!

[orlp]

I need everyone's opinion on these two issues:

• https://github.com/orlp/pyth5/issues/1
• https://github.com/orlp/pyth5/issues/2

If you're interested in Pyth 5 I suggest you follow the repository so I can get more rapid feedback :)