wording

content/news/2023/10/06/deref.adoc

@@ -17,7 +17,7 @@ At a meta level, there are a bunch of options here and we have still not decided
 
 We've spent a ton of time over the last week looking at the internals of LazySeq and options for avoiding synchronization. The general guidance from Java is to replace synchronized with ReentrantLock (which has virtual thread coordination), but this advice leaves out the inherent tradeoffs in that change. synchronized relies on object monitors which are built into every Java object at the JVM level, whereas ReentrantLocks are additional Java objects (which hold a reference to an internal Sync object). Clojure makes a lot of lazy seqs and allocating two objects (plus adding an additional field to LazySeq) for every lazy seq is a real cost in allocation, heap size, and GC. Additionally, while ReentrantLock seems to be a bit faster than synchronized in Java 21, LazySeq makes one reentrant call, and reentrant calls seems to be noticeably slower than synchronized. There are lots of options though. We think it's relatively easy to make lazy seq walking faster, but a lot harder to keep realization costs under control (as making locks takes non-zero time). One interesting branch we have explored is making one lock per seq and passing it through the seq as we go - lots of tradeoffs in that.
 
-Additionally, we continue to work on functional interface adapters and method thunks. With FI adapters, we continue to refine when implicit coercion and conversion occur and I think that continues to draw asymptotically closer to completion. With method thunks, we have taken a bit of a detour to examine array class representation.
+Additionally, we continue to work on functional interface adapters and method thunks. With FI adapters, we continue to refine when implicit coercion and conversion occur and I think that draws asymptotically closer to completion. With method thunks, we have taken a bit of a detour to examine array class representation.
 
 Generally, classes are represented by symbols that name the class, but this does not work for array classes as they cannot be represented as a valid symbol. The fallback right now is using a String that holds the internal class name, like `^"[Ljava.lang.String;"` which I think we can all agree is no fun. Our plan going forward is to support a new array class syntax which is a symbol of the class with a `pass:[*]` suffix. Imported classes can use their short name, so `pass:[String*]` will represent a Java `String[]` (or a `String...` vararg). Multiple `pass:[**]` will represent multidimensional arrays. This will work with both classes and with primitives, so `pass:[long*]` will be a synonym for the existing `longs`. Rich also wishes you to notice the C pointer punnery. :)