They compose. And can be passed around and be completely oblivious to how they will be reduced. With conj or sum or whatever they want. And you can extend them at any point at any end.
They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.
As I said, it is a protocol for iteration or data access. You cant take an iterator and hand it as a filter to a file reader. If I make a rot13 transducer I can hand it to a transduce function that transforms a collection. I can give it to a file reader as a transformer on any char.
I made srfi-171 [0], transducers for scheme. If you have any questions about them in general I can probably answer them. My version is pretty similar to the clojure version judging by the talks Rich Hickey gave on them.
Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because people forgot to divide by time, where they write something like "(31l/m2)/1min in mm" when they should have have written something like "(31l/m2)/1min in mm/h". Anyway, check it out here:
I am about 6 days away from publishing and open beta (currently in mandatory closed testing). If you want to join the closed test, you can do so by mailing me at the email at the top of the readme.
I think your interface is a bit inconsistent, this is why people ask that question.
If you have
65mi in 12mi/h -> 19500s
then instead of
12h in s -> 43200s
you should have
12h in s -> 43200
Then a unit at the end should mean that not all dimensions have been reduced.
In the same vein, in the README, the "weird results" section should come after the "dimension removal" section. The way it is now, the apparent "bug" comes before the feature.
You are right about this being confusing. I have thought about whether to adopt in as strict division or whether to be strict about in UNIT to have to produce UNIT. The first one will not resolve the issue of Umits selecting becquerel or Hz to represent N/s, but the second is not as much fun.
Yes. But treating in a strict division isn't really what people expect. Then 12mi/h in km/h becomes "19.3xyz" not "19.3xyz km/h".
The least surprising thing would be to enforce unit output. If I say I want "in km/h" the output should be in km/h or show an error. It is however less fun. Getting becquerel when you forget a unit along the way is the kind of spice that makes life fun.
Treating "in" as strict division also doesnt solve the surprise of getting Bq or Hz when you accidentally end up with something that is N/s
And, in some ways, PyPy. I still think it is the sanest way to implement Python.
It makes me sad that I have to write C to make any meaningful changes to Python. Same goes for ruby. Rubinius was such a nice project.
Hacking on schemes and lisps made me realize how much more fun it is when the language is implemented in the language itself. It also makes sure you have the right abstractions for solving a bunch of real problems.
It is restricted in a way that you would restrict yourself to write high speed software in most languages, and I found it is not that restrictive compared to C that you would have to use if you were to write a fast Python library.
oh for sure, but I still feel like telling people pypy is written in python is misleading. it's written in something significantly like python, but it's not python.
The fact that it's written in python is often brought up in order to explain its name. But really, it's much less interesting than the fact that it has a tracing JIT. If it were called PyJIT I'd bet it would be clearer and more obvious that it's fast. And people would prob get less hung up on the distinction between python/rpython.
And Hickey himself said he adapted ideas from Bagwell's HAMTs. And tries are 60 years old.
I have always thought Hickeys main contribution was making it default in a coherent way, and proved it could be done. Before clojure most peoplle still thought immutable data structures were too I practical.
I think the Clojure version does have some actual improvements over the Bagwell version, and some implementation tricks improvements as well. But I don't remember all the details.
Well, sure. But it is not like Hickey invented the 5bit partitioned trie (there is work in sml and Haskell before that), nor did he invent functional tries.
He took what was a research topic and made it standard. There were no other 5bit partitioned tries in (wide) use. I think he did that in a way that signals a fantastic sense of taste, and if you are implementing a programming language you need taste.
I know people using ref counting to support using allocation arenas for immutable structures. For some workloads that gives a pretty crazy performance boost.
Just pre-allocating leaf nodes can reduce iteration overhead by 40%.
It is faster than clojures vectors (running on the JVM, so apples and cucumbers) in all cases, and mostly beats scala's vectors except for splitting which is crazy fast in scala's vectors).
AEPD are well known, even in the rest of the world. They have a different strategy compared to other countries. Ireland's DPC are also heavy handed, but focus on large companies mostly.
France's CNIL is also not bad. They are particularly hard against things like "you accidentally sign up for x y z services when only wanting to sign up to service A".
Gdpr in the EU is also miles ahead of what the US has, or at least what it has been enforcing for a long time.
They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.
reply