See also https://github.com/cgrand/xforms for a transducer version of
reductions. The argument f must have a nullary arity. (You could probably
create your own variant if you want an explicit init value.) I think something
like this should work:
(require '[net.cgrand.xforms :as x])
(defn xs
gt;
> I've found myself needing a function that I am sure cannot be an original
> but I'm not aware of it existing anywhere...
>
> It is a cross between 'map', 'reduce' and 'iterate'...
>
> Given a function 'f' and a sequence '
uys,
>
> I've found myself needing a function that I am sure cannot be an original but
> I'm not aware of it existing anywhere...
>
> It is a cross between 'map', 'reduce' and 'iterate'...
>
> Given a function 'f' and a seq
step...
Jules
On Sunday, 27 November 2022 at 19:00:48 UTC Jules wrote:
> Guys,
>
> I've found myself needing a function that I am sure cannot be an original
> but I'm not aware of it existing anywhere...
>
> It is a cross between 'map', 'reduce&
Guys,
I've found myself needing a function that I am sure cannot be an original
but I'm not aware of it existing anywhere...
It is a cross between 'map', 'reduce' and 'iterate'...
Given a function 'f' and a sequence 's' it would retur
In a private chat (I will not expose their names, but they may feel free to
identify themselves in this thread) someone posed a question:
Anyone know why the multi-arity version of `defn` takes an extra optional
`attr-map?` argument?
https://github.com/clojure/clojure/blob/clojure-1.10.1/src/clj
farta
> 20. des. 2020 kl. 16:26 skrev Ganesh Neelekani :
>
>
> Hello Team,
>
> I am new to clojure and I wanted to write a function where input from map
> keys are passed as parameter as input to the sql query.
>
> (def query-body1 "
> select first_name, las
gt; input.
>
> In more general terms, you want to think about taking an input (a map),
> applying some transformation (a function) and producing an output (a string
> describing a sql query).
>
> You will first want to think about where the dynamic input is coming from
> and what
The most straight forward approach is to simply define a different function
for each use case you have using the same approach.
At some point you will have to decide which function to call with what
input.
In more general terms, you want to think about taking an input (a map),
applying some
Neelekani
On Sun, Dec 20, 2020 at 9:12 PM alpeware llc wrote:
> Welcome to Clojure!
>
> You could just define a function taking a map as an argument and return
> the query as a string using destructering [0]
>
> (defn people [{:keys [table person id]}]
> (str "SEL
Welcome to Clojure!
You could just define a function taking a map as an argument and return the
query as a string using destructering [0]
(defn people [{:keys [table person id]}]
(str "SELECT * FROM " table " WHERE person_id = " person " ORDER BY " id))
You m
Hello Team,
I am new to clojure and I wanted to write a function where input from map
keys are passed as parameter as input to the sql query.
(def query-body1 "
select first_name, last_name
from ${table_name}
where
person_id=${person_id}
order by ${id}
")
(def query-body
We have been busy here working with our little dataset library and I wanted
to talk about some of the upgrades that I think are important/interesting.
We have first class support of Apache Arrow now which means I took the time
to actually understand, byte-by-byte, the binary on-disk format. I also
Thanks very much for your responses. :) 'subseq' looks like it will do
what's needed.
-- Harmon
On Monday, May 25, 2020 at 4:47:58 PM UTC-5, Harmon Nine wrote:
>
> Is there an optimization for sorted-maps that, when you have a given key
> in the map, you can get the n
ation for sorted-maps that, when you have a given key
> in the map, you can get the next key in O(log n) time?
>
> Given "compare" is the boolean function on which the sorted-map is based,
> the following code will get the next-key given a current-key:
>
> (defn get-next
Hey Harmon,
On Tue, May 26 2020, Harmon Nine wrote:
> Does such an optimization exist? If not, is there an means of getting the
> next-key in a sorted-map given a current-key that is better than O(n)?
I just had a look at clojure.core and found that subseq operates on a
sorted coll
Hi, there is no such optimization and that's not really feasible in the
sorted-map impl. However there are other sorted map data structures like
https://github.com/clojure/data.avl which have facilities in this area.
On Monday, May 25, 2020 at 4:47:58 PM UTC-5, Harmon Nine wrote:
>
&g
Is there an optimization for sorted-maps that, when you have a given key in
the map, you can get the next key in O(log n) time?
Given "compare" is the boolean function on which the sorted-map is based,
the following code will get the next-key given a current-key:
(defn get-next-k
"A language that doesn't affect the way you think about programming is
not worth knowing." - Alan Perlis
A lot clojure's culture and philosophy is centered around Rich's talks.
I resisted this for a very long time. I'd rather spend 10 hours
reading a book than 1 hour watching someone speak. I wa
In my humble opinion, main benefits of Clojure:
- Development cycle: modifying and experimenting on a running program.
- Treating data as maps. Direct and efficient immutability.
- Macros: Though used very scarcely, it's good to know that you'll be able
to extend the language from within if you
I think someone else here could give a more detailed answer, and I will
just give it from my point of view. What I really like about Clojure,
coming from C# and JavaScript (and toying with other languages), is the
immutability, the concurrency features, the state management features, and
the concis
Thanks, I'm currently reading the book you mentioned (Joy of Clojure). Just
started on 'Types, protocols and records'...
Still doubting if I should continue learning clojure. From my point of
view, the only major advantages of the language so far, are 'clojurescript'
and the idea that I can eval
; {:x [x]
> :MYMETHOD (fn [] (MYCLASS ...))})
>
> (let [lol (MYCLASS ...)])
>
> I know its not valid code, but I hope you see what I'm aiming at: isn't
> using a map with functions in it just the same as a class?
> Or is only the user interface of the languag
A few years ago I built some kind of internal DSL using Clojure macros
which allowed to create objects and classes like in conventional OOP
languages as Smalltalk and Java.
The macro obj creates a classless, immutable object, for example:
(obj {:x 1, :y 2} {:f (fn [] (+ (self :x) (self :y)))})
o
It might be worth mentioning that, ultimately, python class instances are
syntactical sugar built around an internal __dict__. It gets twistier,
since classes are also instances of the base class object.
It would be tricky (though I've seen an example...maybe in Joy of Clojure?
I think the auth
Witty and instructive:
http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
I think it's also important here that Clojure methods are actual Java
methods - Clojure likes to stay close to the host functionality. A map
with a function isn't a class with a method because the JVM bytecode
doesn't let you invoke it that way directly. A Clojure function is not
a
A subtle difference between a map of functions and a Python class is that
the class has implicit "self" or "this". Otherwise, these are semantically
the same. Well, ignoring that Clojure maps are immutable.
In fact, C++ compilers compile methods by inserting a first "th
CTION():
lol = MYCLASS()
Clojure:
(defn MYCLASS [x]
{:x [x]
:MYMETHOD (fn [] (MYCLASS ...))})
(let [lol (MYCLASS ...)])
I know its not valid code, but I hope you see what I'm aiming at: isn't
using a map with functions in it just the same as a class?
Or is only the user i
Thanks for the reply. I do need to convert to java hashmaps and arraylists
because I'm trying to duplicate the testing of a clojure workflow being run
on a server thats pushing pure java context through it. So in my tests I
define a clojure map but want to javafy it to force errors to h
so with a clojure.walk/postwalk-replace.
On Friday, January 31, 2020 at 3:07:24 PM UTC-6, Jason Ross wrote:
>
> Hey I know this is super old post but what would the reverse look like,
> eg. recursively convert Clojure to java map
>
> On Saturday, October 15, 2011 at 4:10:32 AM
Hey I know this is super old post but what would the reverse look like, eg.
recursively convert Clojure to java map
On Saturday, October 15, 2011 at 4:10:32 AM UTC-5, Baishampayan Ghose wrote:
>
> > I have a Java Map contains Map of Maps/List (JSON like map) and have
> > to con
Clarity is important. Considering the conundrum of sorting namespace
aliases, vs using the fully-qualified name as the implicit sort key despite
the apparent alias; and the burden of shuffling everything after a
refactoring; any sorted order will sooner or later be "broken", so you
might as we
d as `db,
host, password, port, user`.
Do you try to maintain the same order of map keys (including keys in specs)
across the files? If yes, what rules do you follow?
Thank you.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post t
On Wed, 1 May 2019 at 06:09, Henning Sato von Rosen <
henning.von.ro...@gmail.com> wrote:
>
> Thanks again for interesting background/links!
>
> On Fri, Apr 26, 2019 at 12:58 AM Rick Moynihan
> wrote:
>
>>
>> I believe another non RDF influence for spec is this paper:
>>
>> http://matt.might.net/
Thanks again for interesting background/links!
On Fri, Apr 26, 2019 at 12:58 AM Rick Moynihan
wrote:
>
> I believe another non RDF influence for spec is this paper:
>
> http://matt.might.net/papers/might2011derivatives.pdf
>
>
The paper on derivatives is both beautiful and mind-bending, but I fa
adding a new spec to some existing
data. And it's also like adding a new property (keyword) to a map in spec,
and only handling what you know.
> I might have gotten it backwards here, but isn't the natural thing to
> think of our *map* as the relation (predicate) and our *properties* as
Thanks a lot for the background on RDF and links, very interesting indeed!
About FOL, you equal the properties that we are talking about to predicates
in FOL. I might have gotten it backwards here, but isn't the natural thing
to think of our *map* as the relation (predicate) and our *prope
Having used both Clojure and RDF extensively I can say that there are many
similarities between these two worlds, and the influence of RDF on Clojure
isn't just something Rich say's, it's very apparant.
I may be mistaken in some of the details here, but as I understand it in
the world of GOFAI (Go
...
>
>>1. *Non-existence expressed by omisson of keyword.* Non-existence of
>>a value in a key/value-pair must be expressed by omission of the whole
>>key/value pair, not by `null` as a value.
>>...
>>
>> Just to add that I understand null should be interpreted as "I don't know
>
Thanks again for your comments! They are absolutely very helpful!
I feel I'm trying to free-my-mind here; still working on losing the idea
that type-checking is magic done by the system/language, and instead
something the programmer can use at will, and creatively, and in unexpected
ways. Not only
On Thu, Apr 25, 2019 at 2:32 AM wrote:
> A lot of the attribute-centric thinking is inspired by RDF and linked-data
>
Yes! Rich mentions that as well. So I tried to look into RDF, but it is
huge! If anybody has a good link to material relevant to this discussion,
I'm thankful, but at the time be
Henning Sato von Rosen writes:
> Sorry if I'm wrong here, but I'm not sure we are talking about the same
> data-type; I'm not referring to the Rich's examples with Maybe, but his
> examples with records/maps, where some fields may or may not be present.
Right, and in most other type systems, th
A lot of the attribute-centric thinking is inspired by RDF and linked-data
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
El vie., 19 abr. 2019 a las 13:25, Henning Sato von Rosen (<
henning.von.ro...@gmail.com>) escribió:
> ...
>
>1. *Non-existence expressed by omisson of keyword.* Non-existence of a
>value in a key/value-pair must be expressed by omission of the whole
>key/value pair, not by `null` as a
manipulate the same datatype, e.g. a map
containing name and address etc, and a given function might need only the
street address and postal code, and this is usage/context dependent, so you
shouldn't have to *hide optionality* by declaring that attributes need to
be present but might c
en a more precise description than given in "Maybe Not"?
> 2) Does it have an established name, that can be search for on the web? The
> combination of the two principles above seems very appropriate for
> modelling certain domains, so it certainly deserves a name, don't yo
/talk-transcripts/blob/master/Hickey_Rich/MaybeNot.md
The idea is to represent data by maps while observing the following two
principles:
1. *Keywords have type declarations for their values, not maps*:
The types of the values of the keys are defined *per keyword*, no per
map type
Maybe we can do a little more:
(defmacro limit-keys
[& {:keys [req req-un opt opt-un only] :as args}]
(if only
`(s/merge (s/keys ~@(apply concat (vec args)))
(s/map-of ~(set (concat req
(map (comp keyword name) re
Also remember that `mapv` is not lazy and will force the map to run right
away, which helps if side-effecty things like `println` are a part of the
function.
On Thu, Feb 7, 2019 at 10:54 AM Justin Smith wrote:
> also do note that clojure.core/run! is designed for two-arg map when
> it&
also do note that clojure.core/run! is designed for two-arg map when
it's only run for side effects, and clojure.core/doseq is designed for
nested side-effecting iteration
On Thu, Feb 7, 2019 at 3:33 AM Pierpaolo Tofani
wrote:
>
> Thanks ! Your diagnosis is correct. With two dorun
Just as a note, you should probably use `doseq` when you want to produce side
effects.
Erik.
> On 7 Feb 2019, at 12:04, Pierpaolo Tofani wrote:
>
> Hi
> i am new in clojure sorry.
> In the snippet of code i used two map functions only to produce side effects
> on two
Thanks ! Your diagnosis is correct. With two dorun works fine.
Il giorno giovedì 7 febbraio 2019 12:19:40 UTC+1, Orestis Markou ha scritto:
>
> Without having ran your code, it seems that the inner map is not wrapped
> in a doall, so while the outer lazy-seq is forced, the inner is not.
Without having ran your code, it seems that the inner map is not wrapped in a
doall, so while the outer lazy-seq is forced, the inner is not.
This might be of interest to you:
http://clojure-doc.org/articles/language/laziness.html
<http://clojure-doc.org/articles/language/laziness.html&g
Hi
i am new in clojure sorry.
In the snippet of code i used two map functions only to produce side
effects on two ref.
Even using doall no affect is produced on ref aaa and zzz, seems that the
sequence is still lazy.
But if i remove the final :done , and the repl show me the sequence
produced
*Update*
Version 0.2.0 simplified the implementation even more (shaved another 10
more lines from 100 LOC), introduce flexible *fw* macro, function wrapped
in a fun-map can cache and update the cache when its dependencies updated.
*Background*
A fun-map is a map can automatically unwrap any
clojure.data.priority-map is a data structure that maintains a map that is
sorted by its values, rather than its keys. This allows it to be used as a
versatile priority queue.
The latest version contains two changes:
1. Aligned the hash value of priority maps to match the way that the hash
value
Cool.
On Thursday, May 10, 2018 at 4:46:31 PM UTC-6, Robert Luo wrote:
>
> Yes. Fun-map can be used like a `graph` in plumbing. It actually has a
> macro named `fnk` just like plumbing. Both of fun-map and plumbing can link
> functions toghether by the name of arguments, hence can
Yes. Fun-map can be used like a `graph` in plumbing. It actually has a macro
named `fnk` just like plumbing. Both of fun-map and plumbing can link functions
toghether by the name of arguments, hence can be used as a dependency injection
tool.
However, the implementation of fun-map is very
This looks a lot like Prismatic's Plumbing
library: https://github.com/plumatic/plumbing
On Tuesday, May 8, 2018 at 8:36:23 PM UTC-6, Robert Luo wrote:
>
> *Github Link: https://github.com/robertluo/fun-map
> <https://github.com/robertluo/fun-map>*
>
> It is a lazy ma
*Github Link: https://github.com/robertluo/fun-map*
It is a lazy map:
(def m (fun-map {:a 4 :b (delay (println "accessing :b") 10)}))
and can also be a future map:
(def m (fun-map {:a (future (do (Thread/sleep 1000) 10))
:b (future (do (Thread/sleep 1000) 20))}))
*- Github link: https://github.com/robertluo/fun-map*
>From the project's README:
In clojure, code is data, the fun-map turns value fetching function call into
map value accessing.
For example, when we store a delay as a value inside a map, we may want to
retrieve the value wrappe
Don't think so.
But the conversion back and forth is O(1). So it shouldn't affect performance.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderate
I can iterate through a transient vector, as count and nth can be used
directly on the transient.
Is there any way to iterate through the keys (or key/value pairs) of a
transient hash, other than just making a persistent version of it?
I guess the meta-question is, any advice on finding which f
I just deployed version 0.0.9, which adds a more efficient implementation
of reduce-kv.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - plea
https://github.com/clojure/data.priority-map
clojure.data.priority-map is a map-like data structure that sorts by
value. It is useful in many situations where you might ordinarily use a
priority queue.
NEW for version 0.0.8 is support for subseq and rsubseq.
I had always intended to support
Hum, could you show me an example use of it, I'm having a hard time
understanding how.
I also stumbled upon a use case where we have a multi-spec of keys spec. And
each one needs to have a key with same name, yet a different spec to it, only
for some of their keys. Could keys* be used for that
Check out s/keys*
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, s
If I have a function that takes a destructured map, what's the best way to
spec that function, so that the values of the keys in my map are also
specced? The best I've got right now is
(s/keys :req-un [::a ::b ::c])
given
(defn foo [{:keys [a b c]})
But, I'd kind of want t
ure and ClojureScript something like:
>
> (defn multi-spec-sub-specs
> "Given a multi-spec form, call its multi method methods to retrieve
> its subspecs in the form of [multi-method-key sub-spec-form]."
> [multi-spec-form]
> (let [[_ multi-method-symbol &am
-symbol & _] multi-spec-form]
(->> (resolve multi-method-symbol)
deref
methods
(map (fn [[spec-k method]]
[spec-k (s/form (method nil))])
to go down inside multi-specs.
Juan
--
You received this message because you are subscribed to the Goo
and understands the semantics of the above macros, but I was
> hoping I could write one using the data contained in the spec registry
> instead)
>
>
> Ben
>
>
> On Thursday, November 23, 2017 at 7:09:15 AM UTC-7, Nico Schneider wrote:
>>
>> Hello everyone,
>>
>&
sday, 16 November 2017 23:29:56 UTC+1, John Newman wrote:
>>
>> [...] when we constrain maps in that closed way, aren't we creating some
>> new subtype of a map, with fundamentally different semantics? If you are
>> going to fully close a map, you might as well use a
I know they aren't "official" Clojure documentation, but the examples and
comments at clojuredocs.org are often correct, and even sometimes
illuminating.
http://clojuredocs.org/clojure.core/assoc!
All of the clojuredocs.org pages for transient operations refer to that one
for a more full discussi
Thanks, that is useful advice.
I do think that the docstring for assoc! could be more explicit about the
dangers of not using the return value.
Given the value placed in experimenting in the REPL it's easy to see how
one could be fooled into using assoc! incorrectly.
On Friday, 24 November 2
A docstring need not be a rope ladder that leads to all truth. (That would
be a project for the IDE documentation access improvement brigade.) But
the docstring of "assoc!" feints in a direction that makes this a
frequently-asked question.
--
You received this message because you are subscri
Hello.
The reader of any particular docstring cannot be expected to magically
know that there is another, better, piece of documentation.
Regards, Mikhail
On Sat, 25 Nov 2017, at 02:10, Timothy Baldridge wrote:
> But this behavior is already documented in the official transients
> overview at htt
But this behavior is already documented in the official transients overview
at http://clojure.org/transients
On Fri, Nov 24, 2017 at 5:46 PM Matching Socks wrote:
> I would go so far as to (light-heartedly) call the "assoc!" docstring
> booby-trapped.
>
> There is an open issue in Jira for it.
I would go so far as to (light-heartedly) call the "assoc!" docstring
booby-trapped.
There is an open issue in Jira for it. Go vote:
https://dev.clojure.org/jira/browse/CLJ-1385
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
The way I like to think of it, if it helps: Transients are still *immutable*,
but they are not *persistent*. Each new value *invalidates* the previous
value.
–S
On Friday, November 24, 2017 at 11:01:48 AM UTC-5, Alex Miller wrote:
>
> Transients must still be used in the same calling pattern a
Transients must still be used in the same calling pattern as persistent data
structures. That is, you must use the value returned from the ! call to make
the next call.
What you’re seeing is a side effect of the way transients are implemented, but
if used correctly you won’t have this issue.
assoc! trans :i "i")
(assoc! trans :j "j")
Then as expected
(:a trans)
=> "a"
and the same for everything up to :h, but I didn't expect
(:i trans)
=> nil
(:j trans)
=> nil
If I do
(dissoc! trans :a)
(assoc! trans :i "i")
(:i trans)
=&g
Hello everyone,
On Thursday, 16 November 2017 23:29:56 UTC+1, John Newman wrote:
>
> [...] when we constrain maps in that closed way, aren't we creating some
> new subtype of a map, with fundamentally different semantics? If you are
> going to fully close a map, you might as w
multiple elements of the same vector,
> it's worth thinking about doing some work upfront so that each look-up is
> faster:
>
> (defn indices [vect]
> (->> vect
>(map-indexed vector)
>(reduce (fn [acc [idx el]]
>
Practically speaking, Java numbers cannot be extended with the IFn
interface to make this possible.
On Mon, Nov 13, 2017 at 9:15 AM, Alex Miller wrote:
> Regarding the title, this is incorrect. Map keys are not functions;
> keywords are functions that take an associative data structure an
chial maps
that don't play nice with others. And when we constrain maps in that closed
way, aren't we creating some new subtype of a map, with fundamentally
different semantics? If you are going to fully close a map, you might as
well use a deftype and make a custom object and not call
jure@googlegroups.com on behalf of Didier
Sent: Tuesday, November 14, 2017 11:21:04 AM
To: Clojure
Subject: Re: [core.spec] Stricter map validations?
Eric does raise an interesting question tho
I think so too. I'm still finding it hard to come up with a single example of
why allowing ext
ble.
But the more I look at the behavior of s/keys, the more I'm starting to
appreciate it. It's not trying to be strict to educate clients. It's for
asking "does this have the minimum I need to handle this map?" And this is
very much how idiomatic Clojure is written.
Saw this thread on the REPL, interesting discussion.
On Tuesday, October 3, 2017 at 10:57:34 AM UTC-7, Alex Miller wrote:
>
>
> It's not about easier, it's about possible. Open grows, closed breaks.
>
>
I agree with the broad brush, but it's important to listen to this
usability feedback befo
tened to everyone, I see that there might be many things
needed by different people, and its not clear if all should be provided by spec
directly.
Mostly I can see wanting:
A. To spec a map in which you expect the keys to have a registered spec.
B. To spec a map in which you don't
to continually run
into. I've hit it myself already in projects where I spec'ed a map, but
didn't have some of the keys spec'ed. I discovered later my mistake, but
like Didier, I can't see any time that I would actually want this feature.
Because spec's informatio
e.
Are there any resources that document these best practices? It seems like
Clojure is trying to push us down this road but there's no map yet at the
moment.
>
>
> tirsdag 14. november 2017 19.43.55 UTC+1 skrev Sean Corfield følgende:
>>
>> Eric does raise an interesting
string and it broke that client)
>>>
>>>
>>>
>>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>>> An Architect's View -- http://corfield.org/
>>>
>>> "If you're not annoying somebody, you're not really alive."
&
ng and it broke that client)
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margar
rgaret Atwood
>
>
> --
> *From:* clo...@googlegroups.com > on behalf of Seth Verrinder
> >
> *Sent:* Tuesday, November 14, 2017 8:45:30 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations?
>
> I took part
---
> *From:* clojure@googlegroups.com on behalf of
> Seth Verrinder
> *Sent:* Tuesday, November 14, 2017 8:45:30 AM
> *To:* Clojure
> *Subject:* Re: [core.spec] Stricter map validations?
>
> I took part of the goal to be that specs themselves would remain
> compatible, so an
;re not really alive."
-- Margaret Atwood
From: clojure@googlegroups.com on behalf of Seth
Verrinder
Sent: Tuesday, November 14, 2017 8:45:30 AM
To: Clojure
Subject: Re: [core.spec] Stricter map validations?
I took part of the goal to be that specs themselve
Oh, I see! That makes sense. Thanks!
On Tuesday, November 14, 2017 at 10:45:30 AM UTC-6, Seth Verrinder wrote:
>
> I took part of the goal to be that specs themselves would remain
> compatible, so an old set of specs wouldn't start failing on data that
> conforms to a new but compatible set of s
I took part of the goal to be that specs themselves would remain
compatible, so an old set of specs wouldn't start failing on data that
conforms to a new but compatible set of specs. That sort of compatibility
isn't possible when you go from disallowing something to allowing it.
On Tuesday, Nov
Hey everybody!
I'm chiming in after seeing this linked to in The Repl
(https://therepl.net/).
On Alex's suggestion, I rewatched Spec-ulation last night. The parts about
negation and evolution are towards the end. I was struck (once again) by
how clearly he picked apart changes. Relaxing a requ
1 - 100 of 2323 matches
Mail list logo
