In general, I find that compilers, transpilers, etc. are all just "interpreters", which conceptually just boil down to a given input being "re-interpreted" into a new representation. Thus, what we commonly call interpreters re-interpret programs into results, compilers just re-interpret into an executable, transpilers into a different language, etc.
Imho this is a non-issue. Python's max-function isn't limited to numerical values, but can consume iterables of anything with a defined order, i.e., things that implement the appropriate hooks in the Python data model. For such inputs, returning anything but an error (or the optionally provided default value) doesn't make much sense.
Sometimes this may be the case but not so much here. Firstly the mention the version they used and, secondly, OtterTune are a startup based around automatic DB steup/schema optimization founded by folks from CMUs DB group, they most certainly know what they are talking about here.
This is not strictly true. Python expressions are in fact Turing complete. For example, you can implement an entire Brainfuck interpreter [0] in a single expression.
It may be "close[r] to the data", but be ware Python UDFs usually still have context switches between the python interpreter and the query executor. If these pile up — as is the case if you fire off queries in, say, a loop — you will still see lousy performance. There is currently research under way, to optimize UDFs and other forms of computations over database resident data. For Python, for example, you can checkout the python to SQL compiler [0] and associated demo-paper [1] we produced for this years Sigmod. (Disclaimer: as you may have noticed thanks to that " we", I'm an author on that paper.) Though it may only support a limited subset of Python, one can already do alot with just that.
Not to nitpick, but do you mean the pattern matching statement when you are talking about "sum types"? Because as far as I'm aware Python doesn't have " proper" algebraic data types.
To be quite honest: I don't think there is anything along those lines. But if want to tackle it I recommend looking for PDF copy of Types and Programming Languages by Benjamin C. Pierce. It contains all necessary typing rules — barred the whole inference magic — be it System F, ADTs or Records.
EDIT: Oh and also contains the reduction rules ofcourse! Though the book assumes you now how to read inference rules. ;)
This looks cool. If you want to delve deeper intob symbolic computation you can have a look at sympy [0]. It seems to be the "defacto standard" when it comes to Python libraries for this.
This may seem like a minor nitpick but it's something that popped out at me: italisizing a font shouldn't add or remove serifs. There is a reason why Unicode defines both sans- and serif versions of italics.
I don't know when Portugal started this, but in Germany there is at least the concept of a "grüne Well" (literally a green wave). Simply put: if you drive at the speed limit you won't get any red lights. Sadly the german administration barely makes use of this as it doesn't make them any money...
Very cool!
I'd love to do some bytecode rewriting magic for some of my projects as well, but alas it only works for statements/expressions that are legal python syntax. :/
Sadly (or luckily?) I don't know anyone who has/uses/has to use a braille display. But I think that if the "reader"/viewer doesn't know from the get go that the following characters aren't text it'll for sure throw them through a loop... :'D
I also thought about adding color support via ANSI escape sequences, but for this project I decided against using them to keep things simple a widely accessible.