I had the same thought. There was surprisingly little discussion of how this new language relates to Python - the only mention on the whole page is that need Python installed to use it. At pyflang.com it says that "PyFL = Python based Functional Language".
I'd be curious to know: Does PyFL benefit from Python's libraries, in the way that Scala and Clojure can use Java libraries? Are there any syntactic similarities? Or does it just happen to be built on Python as an implementation detail?
My bad, it's implemented in Python. But it uses one Python library, mathplotlib,although I commented out the code cause mathplotlib is a pain to install.
Right, but it’s still the root of the functional branch of the PL family tree. ISWIM to ML is mostly a matter of removing the few imperative features from ISWIM. Once you do that, lazy execution comes naturally.
I so wish Python had valof/where already. And it’s the one feature I was surprised not to find in OCaml after seeing it in Haskell – why isn’t it more common?
Heh; better to use a non-empty list (AKA a tuple) I suppose. It's also wildly inefficient compared to:
average (x, xs) = total / count
where (total, count) = Data.List.foldl' go (x, 1) xs
go (total, count) x = (total + x, count + 1)
In a naive interpreter, this will do one pass rather than two. A smart compiler like GHC can probably optimise away the entire list, getting a tight numeric loop (e.g. https://dl.acm.org/doi/10.1145/1291220.1291199 )
It's not very natural in langages with strict evaluation. Haskell is a good fit because, with lazyness, the order matters less. Same thing goes with purity : what if some side effects hide in "where"?
This "mandatory" currying is an useful and elegant simplification compared to other languages, but in practical terms if we write
f a b
f has to work as a function of two arguments; that it is also formally interpretable, but not necessarily useful, as a function of one argument is only a nice bonus.
Awesome to hear of a new language from Bill Wadge but I’m a bit disappointed. Bill Wadge is of Lucid fame, one of the first dataflow languages. I was hoping for dataflow Python, not functional Python. Although I notice an appearance of the fby (followed by) operator so maybe there is some dataflowyness in here. Will definitely pay close attention to this.
I'm surprised at choosing not to fix the lack of multiple statements in Python's lambda. That grinds my gears, i'm so often denied using lambda in python in places i'd like to because of this limitation.
That said, i do prefer PyFl's lambda syntax.
This is definitely a cool project, i could see myself using this.
50 comments
[ 5.3 ms ] story [ 115 ms ] threadWadge was a co-designer of Lucid, an influential dataflow language.
https://en.wikipedia.org/wiki/Lucid_(programming_language)
Doesn't Python already de-structure?
Repackaged: does PyFL lose touch with the regular language?
I'd be curious to know: Does PyFL benefit from Python's libraries, in the way that Scala and Clojure can use Java libraries? Are there any syntactic similarities? Or does it just happen to be built on Python as an implementation detail?
https://github.com/fable-compiler/Fable.Python
https://en.wikipedia.org/wiki/SASL_(programming_language)
ISWIM also inspired Lucid, so I guess PyFL would be a nephew of SASL in that case.
I so wish Python had valof/where already. And it’s the one feature I was surprised not to find in OCaml after seeing it in Haskell – why isn’t it more common?
Thank you for that.
I do not understand the "instead of" in the cited part and it makes me somewhat skeptical (so does the "Py" in the name).
https://en.wikipedia.org/wiki/Argument_of_a_function
"For example, the binary function f(x, y) = x + y has two arguments, x and y, in an ordered pair (x, y)."
So, function application to an ordered pair, i.e., a tuple, does not use double parentheses. Also, of course, currying in Python is atrocious.
That said, i do prefer PyFl's lambda syntax.
This is definitely a cool project, i could see myself using this.
I like his syntactic sugar for what would be list comprehensions in Python:
rather than Python's but I wonder if the Python/Haskell approach offers more composability.