These are chat archives for evhub/coconut

20th
Jun 2016
Pascal van Kooten
@kootenpv
Jun 20 2016 08:08
Great job, good luck :)
datnamer
@datnamer
Jun 20 2016 10:02
Does coconut have macros pr some way pf extending semantics at compile time?
Evan Hubinger
@evhub
Jun 20 2016 15:48
@kootenpv Thanks!
@datnamer No, not currently. The closest to a macro that exists is infix notation, which allows you to use any function as an "is" or "in" style operator. I could certainly add support for macros, however--any specific ideas?
datnamer
@datnamer
Jun 20 2016 17:50
So, there is huge desire in pydata community for ways to write DSLs that can make data analysis more fluid. This would be in the style of R's lazy eval, but more disciplined. This along with the pipe operator, better lambda syntax etc would fill pretty much all of the drawbacks of using python for data science
I mean being able to use python to do stuff like this: http://patsy.readthedocs.io/en/latest/formulas.html#the-formula-language Without string programming
and this: https://github.com/dodger487/dplython without the brittleness of rewriting an expression tree system.
More info on the R vs python comparision here:" http://multithreaded.stitchfix.com/blog/2015/03/17/grammar-of-data-science/ "The equivalent Python code does not read like English and is super annoying to write"
datnamer
@datnamer
Jun 20 2016 17:55
also here useful here: blei-lab/edward#27
If coconut can help solve this DSL issue, I think it would get coconut huge exposure, contributions and be a boon to the pydata community
Evan Hubinger
@evhub
Jun 20 2016 21:11
@datnamer I think Coconut fills a lot of those holes! It has pipe operators galore (|>, <|, |*>, <*|), better lambdas (->), and operators and functions for working with iterators as lazily evaluated lists (:: for chaining, $[] for slicing, map, filter, reduce, consume, etc.) that are all lazily-evaluated unlike the corresponding Python versions.
Boscillator
@Boscillator
Jun 20 2016 21:48
I love the project! I have a question about implementation, why does executor.run return the result of run_func? I've been implementing printing of the result of an expression and I would like executor.run to return the result of the expression or None if it is not an expedition. I have gotten ride of returning the result of run_func and it seams to work. Can you tell if this is Ok?
Ah, I figured it out. I'll just leave the return from the run_func in.
Boscillator
@Boscillator
Jun 20 2016 22:01
OK, now I need some file cocotest/py35_test.coc because Travis is falling, and I have no idea what this file is supposed to be.
Evan Hubinger
@evhub
Jun 20 2016 23:56
@Boscillator Thanks! Don't worry about Travis—it's because of a change I just recently made. It should be fixed on develop tonight. Just have to change the .travis.yml files. As for changing Coconut to print the result of an expression—run_func is exactly the place to do that. If you look in coconut/icoconut/root.pyat _execute you'll see an example of how to run Coconut code as an expression (the case where evaluate = True). One thing to keep in mind: expressions vs. statements have two places where they are handled differently, both in which parser handles them (parse_eval for expressions and parse_block for statements) and in which function executes them (eval for expressions and exec for statements).