Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Hi Brian, Not crazy at all! Spec errors are maps at the bottom, and IMO these maps should flow anywhere we are making exceptions. This is already true for the exceptions coming from spec.test, and we should make it true for the macroexpand exceptions as well. (I actually prefer reading the map format, IIRC it is what I show in most places in the screencasts.) Thank you for pointing this out. Regards, Stu On Wed, Aug 24, 2016 at 9:34 PM, Brian Marick wrote: > > > On Aug 24, 2016, at 7:46 PM, Brian Marick > wrote: > > So why not do it in the bottom layer? Is there some deep reason why only > an unserious programmer would want information in anything other than the > current clojure.spec order? (We’re talking here about reordering a list.) > > An even crazier idea: given that there are N difference pieces of > information, they could be presented in a map, with keys that described > each of them. > > -- > 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, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Brian, The tone of your previous post is not constructive. Let's keep the discussion about ideas, not people. Thanks, Stu On Wed, Aug 24, 2016 at 8:46 PM, Brian Marick wrote: > > On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3. "Follow the inverted pyramid so people see what is most important." > This kind of thing is easily done in a layer above spec, e.g. a custom > REPL printer for spec macro errors. Worth working on but not critical to > getting spec right. > > > So why not do it in the bottom layer? Is there some deep reason why only > an unserious programmer would want information in anything other than the > current clojure.spec order? (We’re talking here about reordering a list.) > > There has been a notable lack of “yeah, we might have made a sub-optimal > decision” in this discussion. It looks bad, in my opinion. Has looked bad > for a long time. > > > -- > 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, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I do not think your tone and lack of constructive feedback to Alex's (and others) thoughtful responses is helping your case. On Wednesday, August 24, 2016 at 8:46:47 PM UTC-4, Brian Marick wrote: > > > On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3. "Follow the inverted pyramid so people see what is most important." > This kind of thing is easily done in a layer above spec, e.g. a custom > REPL printer for spec macro errors. Worth working on but not critical to > getting spec right. > > > So why not do it in the bottom layer? Is there some deep reason why only > an unserious programmer would want information in anything other than the > current clojure.spec order? (We’re talking here about reordering a list.) > > There has been a notable lack of “yeah, we might have made a sub-optimal > decision” in this discussion. It looks bad, in my opinion. Has looked bad > for a long time. > > > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
> On Aug 24, 2016, at 7:46 PM, Brian Marick wrote: > So why not do it in the bottom layer? Is there some deep reason why only an > unserious programmer would want information in anything other than the > current clojure.spec order? (We’re talking here about reordering a list.) An even crazier idea: given that there are N difference pieces of information, they could be presented in a map, with keys that described each of them. -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote: > > 3. "Follow the inverted pyramid so people see what is most important." This > kind of thing is easily done in a layer above spec, e.g. a custom REPL > printer for spec macro errors. Worth working on but not critical to getting > spec right. So why not do it in the bottom layer? Is there some deep reason why only an unserious programmer would want information in anything other than the current clojure.spec order? (We’re talking here about reordering a list.) There has been a notable lack of “yeah, we might have made a sub-optimal decision” in this discussion. It looks bad, in my opinion. Has looked bad for a long time. -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
This is almost exactly the intuition behind the standard error reporting
heuristic for grammars involving alternations. It is a heuristic, but it
has to be since on a failure it's impossible to entirely accurately
determine the user's intention. But intuitively, generally the rule that
has managed to parse the furthest into the input is considered the rule
that is most likely to be what the user intended since that's the one that
has matched the most. This is usually calculated using the source offset,
this is subtly different to :path since :path is the distance in the
grammar itself. This doesn't necessarily correspond to the distance into
the input - consider the regex aabcd|a* when matching - the first
alternation would produce a path of length 2 if the two a's in the grammar
are labeled, but the second would produce a path of length 1 (a single
rule) even though it would match more input.
Here's how the basic algorithm works to produce an error like I showed
above.
1. Parse the form - if it matches some path through your grammar, you're
done.
2. If not, for each failure record the path to that failure, the text
offset of the error point and what the rule was expecting at that point.
This may be that you found something unexpected, but may also be that you
ran out of input and needed more.
3. When done, find the furthest error point and collect all the failure
info for rules which failed at that point.
4. If there's just a single failed rule, use that as your error rule to
report from. Otherwise, use a heuristic like "find the shortest subset of
all failed rules and use that path as the failing rule" (since all failures
start from that point).
5. Report something like "Error when parsing , found but was expecting one of ".
There are some complications here in Clojure since we're parsing forms, and
not all form elements have metadata saying where they exist in the source
(e.g. keywords). Also, when you run out of input it's really useful to be
able to indicate the end of the form you were parsing to say "I needed more
input here". Finally, if we're parsing the result of a previous
macroexpansion, macros are historically pretty bad at propagating source
metadata. I'd like to see the following improvements:
1. Ensure that forms always get source metadata added - I believe there
were some bugs around this.
2. For composite forms (i.e. collection literals) add metadata
indicating the end of the form in the source.
3. On macroexpansion, automatically propagate the source location
metadata from the source form to the expansion if it's not present there -
that way at least the form itself will retain it.
tools.reader handles all this stuff a lot better, I believe. I think there
are also open JIRAs for some of this work.
On 25 August 2016 at 09:33, Leon Grapenthin
wrote:
>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (?
>> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))),
>>
>> the predicate that is actually failing in the spec, probably not
>> particularly helpful given the complexity (and recursiveness) of the
>> destructuring specs
>>
>>
>> Extra input
>>
>> this is the part of cat that I think could be made more explicit - could
>> be saying here that the value it had (above) was expected to match the next
>> part of the cat (binding-form). So that could say the equivalent of
>> "Expected binding-form but had non-matching value ..." and could even find
>> what parts of that value matched and maybe which didn't (the :or keys) such
>> that you'd have a more precise description. There is some more stuff Rich
>> and I have worked on around "hybrid maps" which is the case here with map
>> destructuring - it's particularly challenging to get a good error out of
>> that at the moment, but there's more that can be done.
>>
>>
> Thank you for doing the walkthrough. I observed this too and became
> sceptical why spec doesn't go further down the path and apparently stops at
> ::binding-form.
> I could isolate the problem a bit by changing the spec of ::arg-list and
> temporarily removing the :varargs branch.
>
> (s/def ::arg-list
> (s/and
> vector?
> (s/cat :args (s/* ::binding-form)
> ;; :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
>)))
>
> This leads to a much better message:
>
> (s/explain (:args (s/get-spec 'clojure.core/defn))
>'[foo [{:or {a/b 42}}]])
>
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name
> at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
> In: [1 0 0] val: ([:or #:a{b 42}]) fails spec:
> :clojure.core.specs/seq-binding-form
> at: [:bs :arity-1 :args :args :seq] predicate: (cat :elems (*
> :clojure.core.specs/binding-form) :rest (? (cat :amp #{(quote &)} :form
> :clojure.core.specs/binding-form)) :as (? (cat :as #{:as}
[ANN] Leiningen 2.7.0
Greetings, fellow Clojurians! I am happy to announce Leiningen 2.7.0! This release contains mostly bugfixes, but two major new improvements were added. There is now a PowerShell version of `lein.bat`, and `:managed-dependencies` has been added to Leiningen. Both improvements should be considered to be in beta, but please try them out and report bugs you find in the GitHub issue tracker. The rationale for `:managed-dependencies` can be found at [1]. To replace `lein.bat` with the PowerShell equivalent, download `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If you end up with an error related to `Invoke-WebRequest`, then it may be a result of an old version of PowerShell, which seems to be resolved by installing the Windows Management Framework 4.0 [4]. The full list of significant user changes: * Add PowerShell script for Windows users. (Brian Lalonde) * Run `:prep-tasks` before `lein test`, so generated test namespaces will be tested. (Martin Reck) * Better error message when attempting to do `lein run` without `project.clj`. (Eduardo Seabra Silva) * Add support for `:managed-dependencies`. (Chris Price) * Provide the current clojars certificate. (Toby Crawley) * Add `*eval-print-dup*` to evaluate forms passed to `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva) * Update bash completions. (Zack Dever) * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins) * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson) * Catch and handle fixture errors during `lein test`. (Alex Hall) * Fix a bug where spaces in directory names on Windows caused crashes. (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange) * Fix a bug where `lein search` would take forever downloading clojars.org. (Paul Dorman) * Retain user defined private repositories when building jars, uberjars and deploy. (Rick Moynihan) * Honor whitelist settings when `lein javac` is called via `lein jar`. (Chris Price) * `lein vsc push` for git will now only push branch-related tags. (Łukasz Klich) Those who have manually installed Leiningen can run `lein upgrade` to pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the previous version if you run into any issues. Keep in mind that the PowerShell script was introduced in this release, hence there are no downgrade candidates for it right now. We have had lots of contributors help out making this release happen, and I'd especially like to thank Chris Price (cprice404) and Florian Anderiasch (winks) for their help with this release. [1]: https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md [2]: https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd [3]: https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1 [4]: http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx -- Jean Niklas -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Parsing namespaced XML with clojure.data.xml
Namespaced XML is inherently value-comparable and unambiguous. It would be shame to give up on that, and disperse the burden throughout every layer of library and consumer. Pretty-printing need not be a concern of the XML parsing library. Everyone seems to be interested nowadays in easing the usage of namespaced keywords. Perhaps printing could be improved (globally) to use the caller's keyword namespace aliases. Anyway, pretty-printing is always expensive. If a keyword-conversion step must encumber either pretty-printing or everything else, better do it in pretty-printing. Keyword *literals* make the source code easy to read, but composing keywords programmatically with a caller-provided namespace might be intolerable. Moreover, providing those namespace mappings would be a messy headache for the consumer of XML processing libraries. The mappings would have to pass through layer after layer. No doubt, every library will provide different defaults. One false step, and you would lose value comparability. By contrast!, with well-known keyword namespaces, computed by a well-known function from their respective well-known namespace URI, everyone could write source code using keyword literals with whatever keyword namespace alias they want, and XML structures would be value-comparable. In the short run, the best pretty-print might be actual XML serialization. In the long run, I predict, Clojure's namespaced keywords will go down as smooth as fudge. By all means, use an encoding more legible than Base64. URLEncoder could be an example in the way it uses %. Pick an escape character that's legal in Clojure namespace names, but unusual in the best-known namespace URIs. Apostrophe? -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Hi Alex, I could track down why explain stops
early. http://dev.clojure.org/jira/browse/CLJ-2013
On Wednesday, August 24, 2016 at 11:33:43 PM UTC+2, Leon Grapenthin wrote:
>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (?
>> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))),
>>
>> the predicate that is actually failing in the spec, probably not
>> particularly helpful given the complexity (and recursiveness) of the
>> destructuring specs
>>
>>
>> Extra input
>>
>> this is the part of cat that I think could be made more explicit - could
>> be saying here that the value it had (above) was expected to match the next
>> part of the cat (binding-form). So that could say the equivalent of
>> "Expected binding-form but had non-matching value ..." and could even find
>> what parts of that value matched and maybe which didn't (the :or keys) such
>> that you'd have a more precise description. There is some more stuff Rich
>> and I have worked on around "hybrid maps" which is the case here with map
>> destructuring - it's particularly challenging to get a good error out of
>> that at the moment, but there's more that can be done.
>>
>>
> Thank you for doing the walkthrough. I observed this too and became
> sceptical why spec doesn't go further down the path and apparently stops at
> ::binding-form.
> I could isolate the problem a bit by changing the spec of ::arg-list and
> temporarily removing the :varargs branch.
>
> (s/def ::arg-list
> (s/and
> vector?
> (s/cat :args (s/* ::binding-form)
> ;; :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
>)))
>
> This leads to a much better message:
>
> (s/explain (:args (s/get-spec 'clojure.core/defn))
>'[foo [{:or {a/b 42}}]])
>
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name
> at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
> In: [1 0 0] val: ([:or #:a{b 42}]) fails spec:
> :clojure.core.specs/seq-binding-form at: [:bs :arity-1 :args :args :seq]
> predicate: (cat :elems (* :clojure.core.specs/binding-form) :rest (? (cat
> :amp #{(quote &)} :form :clojure.core.specs/binding-form)) :as (? (cat :as
> #{:as} :sym :clojure.core.specs/local-name))), Extra input
> In: [1 0 :or a/b 0] val: a/b fails spec: :clojure.core.specs/or at: [:bs
> :arity-1 :args :args :map :or 0] predicate: simple-symbol?
> In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/arg-list
> at: [:bs :arity-n :bodies :args] predicate: vector?
>
> The third one is the desired one and very precise - it seems to be usually
> the one with the largest :in path. The length of the :in path seems a good
> sorting criterium for reporting.
>
> However I was not able to track the issue further down. I also wasn't able
> to reproduce a more minimal case of this problem. It seems like a bug in
> how spec parses and must have something to do with s/cat and the :varargs
> branch.
>
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>
> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (?
> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))),
>
> the predicate that is actually failing in the spec, probably not
> particularly helpful given the complexity (and recursiveness) of the
> destructuring specs
>
>
> Extra input
>
> this is the part of cat that I think could be made more explicit - could
> be saying here that the value it had (above) was expected to match the next
> part of the cat (binding-form). So that could say the equivalent of
> "Expected binding-form but had non-matching value ..." and could even find
> what parts of that value matched and maybe which didn't (the :or keys) such
> that you'd have a more precise description. There is some more stuff Rich
> and I have worked on around "hybrid maps" which is the case here with map
> destructuring - it's particularly challenging to get a good error out of
> that at the moment, but there's more that can be done.
>
>
Thank you for doing the walkthrough. I observed this too and became
sceptical why spec doesn't go further down the path and apparently stops at
::binding-form.
I could isolate the problem a bit by changing the spec of ::arg-list and
temporarily removing the :varargs branch.
(s/def ::arg-list
(s/and
vector?
(s/cat :args (s/* ::binding-form)
;; :varargs (s/? (s/cat :amp #{'&} :form ::binding-form))
)))
This leads to a much better message:
(s/explain (:args (s/get-spec 'clojure.core/defn))
'[foo [{:or {a/b 42}}]])
In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/local-name
at: [:bs :arity-1 :args :args :sym] predicate: simple-symbol?
In: [1 0 0] val: ([:or #:a{b 42}]) fails spec:
:clojure.core.specs/seq-binding-form at: [:bs :arity-1 :args :args :seq]
predicate: (cat :elems (* :clojure.core.specs/binding-form) :rest (? (cat
:amp #{(quote &)} :form :clojure.core.specs/binding-form)) :as (? (cat :as
#{:as} :sym :clojure.core.specs/local-name))), Extra input
In: [1 0 :or a/b 0] val: a/b fails spec: :clojure.core.specs/or at: [:bs
:arity-1 :args :args :map :or 0] predicate: simple-symbol?
In: [1 0] val: {:or #:a{b 42}} fails spec: :clojure.core.specs/arg-list at:
[:bs :arity-n :bodies :args] predicate: vector?
The third one is the desired one and very precise - it seems to be usually
the one with the largest :in path. The length of the :in path seems a good
sorting criterium for reporting.
However I was not able to track the issue further down. I also wasn't able
to reproduce a more minimal case of this problem. It seems like a bug in
how spec parses and must have something to do with s/cat and the :varargs
branch.
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Hi Beau, Yes. Nevermind and everyone should learn to read spec. :-) That said, such customizations allow people to experiment and flesh out a bunch different ideas in parallel. Best, Stu On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry wrote: > Just specifically on a custom REPL printer, wouldn't that negate the > benefits Alex sees in people becoming accustomed to reading spec error > messages? If every error report from each different environment potentially > looks different? Also, from the position of a community maintainer Brian is > most commonly going to be seeing the lowest common denominator error > messages in bug reports filed, and it probably wouldn't be helpful for him > to be getting multiple representations of the same error in different > reports. > > On Wednesday, August 24, 2016 at 6:39:51 AM UTC-7, stuart@gmail.com > wrote: >> >> Brian originally raised 5 points that were concrete & specific, and >> therefore potentially actionable. That is usefully-shaped feedback, thanks >> Brian! My take on those points, which I will recast in my own words: >> >> 1. "Loosen rules about ns form to match what people have actually done." >> This is pretty unlikely, for reasons already covered. >> >> 2. "You can tailor a much better specific message for 'require should be >> a keyword' than what spec makes today." There are several possible things >> to explore here. The most interesting one is "can spec come closer to a >> bespoke message while maintaining its simplicity and composability?" We >> want to make all errors better, not one error awesome. Ideas welcome! >> >> 3. "Follow the inverted pyramid so people see what is most important." >> This kind of thing is easily done in a layer above spec, e.g. a custom >> REPL printer for spec macro errors. Worth working on but not critical to >> getting spec right. >> >> 4. "Name the problem namespace." Spec does way better than this already, >> finding the precise file and line. If there are places where this is >> busted we should fix them. >> >> 5. "I don't want to see the stack trace." Then filter it out of your >> REPL. Intermediaries should never discard telemetry, but end consumers can >> choose to. >> >> Cheers, >> Stu >> >> >> >> On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming >> wrote: >> >>> Sure, at the end of the day I don't really care about thre >>> require/:require issue, it just seems a little incongruent with previous >>> decisions which have promoted backwards compatibility. I generally prefer >>> increased strictness, so I'm fine with the change. I do care about the >>> error messages, though. >>> >>> On 24 August 2016 at 21:32, Mond Ray wrote: >>> I agree Colin, this feels more like the beatings shall continue until morale improves ;-) More seriously, I understand the point of the musical instruments analogy to be a reminder to programmers that learning a language and understanding it in depth will increase your power and expressivity with that language. That should not be used as a reason to increase the difficulties caused by obscure error reporting. My initial understanding of the sales pitch for specs was that it would serve to improve error messages as the macro expansions / transformations would be more tractable in the compiler. I get that it is a work in progress but let's retain that original goal. Unlike you however, I would prefer correctness and the consequent ripples over the continuing acceptance of incorrect expressions. My reasoning is that code which has fewer compatibility style branches will be easier to equip with the necessary instrumentation for generating more human friendly error messages. Ray PS I think this require vs :require thing comes from the way that novices confuse the ns macro with the function that pulls dependencies in at the REPL. Cutting / pasting between the REPL and the file can allow that to bleed in. I know it confused me. On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: > > But creating error messages that are optimal for a user with no >> knowledge or Clojure or spec is just not the goal. > > > This is a totally false dichotomy. No-one in this thread is asking for > that. This thread has several examples of expert Clojure users for whom > the > error messages are incomprehensible. > > I am equally unapologetic about thinking that the musical instrument > analogy is mostly bogus here. There are things that will always be > difficult about learning Clojure because they're conceptual, such as > functional programming. I think the analogy is fair there, they are just > things that will require effort and practice to learn. But the error > messages are about giving people the information they need *so that > they can actually learn from their mistakes*. Clojure has >>>
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Just specifically on a custom REPL printer, wouldn't that negate the benefits Alex sees in people becoming accustomed to reading spec error messages? If every error report from each different environment potentially looks different? Also, from the position of a community maintainer Brian is most commonly going to be seeing the lowest common denominator error messages in bug reports filed, and it probably wouldn't be helpful for him to be getting multiple representations of the same error in different reports. On Wednesday, August 24, 2016 at 6:39:51 AM UTC-7, stuart@gmail.com wrote: > > Brian originally raised 5 points that were concrete & specific, and > therefore potentially actionable. That is usefully-shaped feedback, thanks > Brian! My take on those points, which I will recast in my own words: > > 1. "Loosen rules about ns form to match what people have actually done." > This is pretty unlikely, for reasons already covered. > > 2. "You can tailor a much better specific message for 'require should be a > keyword' than what spec makes today." There are several possible things to > explore here. The most interesting one is "can spec come closer to a > bespoke message while maintaining its simplicity and composability?" We > want to make all errors better, not one error awesome. Ideas welcome! > > 3. "Follow the inverted pyramid so people see what is most important." > This kind of thing is easily done in a layer above spec, e.g. a custom > REPL printer for spec macro errors. Worth working on but not critical to > getting spec right. > > 4. "Name the problem namespace." Spec does way better than this already, > finding the precise file and line. If there are places where this is > busted we should fix them. > > 5. "I don't want to see the stack trace." Then filter it out of your > REPL. Intermediaries should never discard telemetry, but end consumers can > choose to. > > Cheers, > Stu > > > > On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming > wrote: > >> Sure, at the end of the day I don't really care about thre >> require/:require issue, it just seems a little incongruent with previous >> decisions which have promoted backwards compatibility. I generally prefer >> increased strictness, so I'm fine with the change. I do care about the >> error messages, though. >> >> On 24 August 2016 at 21:32, Mond Ray > >> wrote: >> >>> I agree Colin, this feels more like the beatings shall continue until >>> morale improves ;-) >>> >>> More seriously, I understand the point of the musical instruments >>> analogy to be a reminder to programmers that learning a language and >>> understanding it in depth will increase your power and expressivity with >>> that language. That should not be used as a reason to increase the >>> difficulties caused by obscure error reporting. My initial understanding of >>> the sales pitch for specs was that it would serve to improve error messages >>> as the macro expansions / transformations would be more tractable in the >>> compiler. I get that it is a work in progress but let's retain that >>> original goal. >>> >>> Unlike you however, I would prefer correctness and the consequent >>> ripples over the continuing acceptance of incorrect expressions. My >>> reasoning is that code which has fewer compatibility style branches will be >>> easier to equip with the necessary instrumentation for generating more >>> human friendly error messages. >>> >>> Ray >>> >>> PS I think this require vs :require thing comes from the way that >>> novices confuse the ns macro with the function that pulls dependencies in >>> at the REPL. Cutting / pasting between the REPL and the file can allow that >>> to bleed in. I know it confused me. >>> >>> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: But creating error messages that are optimal for a user with no > knowledge or Clojure or spec is just not the goal. This is a totally false dichotomy. No-one in this thread is asking for that. This thread has several examples of expert Clojure users for whom the error messages are incomprehensible. I am equally unapologetic about thinking that the musical instrument analogy is mostly bogus here. There are things that will always be difficult about learning Clojure because they're conceptual, such as functional programming. I think the analogy is fair there, they are just things that will require effort and practice to learn. But the error messages are about giving people the information they need *so that they can actually learn from their mistakes*. Clojure has historically been appallingly bad at that, and no-one should expect their users to flail around randomly trying things to see what works. I've spoken to various smart people who have described their experience of using Clojure as exactly that, even after a non-trivia
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
A suggestion for making all errors better would be to give not only the precise file and line _of the beginning of the top level form containing the problem_, but a more precise line and column of _the part of the form that spec is complaining about_. Multi-line forms are the biggest and hardest to figure out which part spec is complaining about. Andy On Wed, Aug 24, 2016 at 6:39 AM, Stuart Halloway wrote: > Brian originally raised 5 points that were concrete & specific, and > therefore potentially actionable. That is usefully-shaped feedback, thanks > Brian! My take on those points, which I will recast in my own words: > > 1. "Loosen rules about ns form to match what people have actually done." > This is pretty unlikely, for reasons already covered. > > 2. "You can tailor a much better specific message for 'require should be a > keyword' than what spec makes today." There are several possible things to > explore here. The most interesting one is "can spec come closer to a > bespoke message while maintaining its simplicity and composability?" We > want to make all errors better, not one error awesome. Ideas welcome! > > 3. "Follow the inverted pyramid so people see what is most important." > This kind of thing is easily done in a layer above spec, e.g. a custom > REPL printer for spec macro errors. Worth working on but not critical to > getting spec right. > > 4. "Name the problem namespace." Spec does way better than this already, > finding the precise file and line. If there are places where this is > busted we should fix them. > > 5. "I don't want to see the stack trace." Then filter it out of your > REPL. Intermediaries should never discard telemetry, but end consumers can > choose to. > > Cheers, > Stu > > > > On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming < > colin.mailingl...@gmail.com> wrote: > >> Sure, at the end of the day I don't really care about thre >> require/:require issue, it just seems a little incongruent with previous >> decisions which have promoted backwards compatibility. I generally prefer >> increased strictness, so I'm fine with the change. I do care about the >> error messages, though. >> >> On 24 August 2016 at 21:32, Mond Ray wrote: >> >>> I agree Colin, this feels more like the beatings shall continue until >>> morale improves ;-) >>> >>> More seriously, I understand the point of the musical instruments >>> analogy to be a reminder to programmers that learning a language and >>> understanding it in depth will increase your power and expressivity with >>> that language. That should not be used as a reason to increase the >>> difficulties caused by obscure error reporting. My initial understanding of >>> the sales pitch for specs was that it would serve to improve error messages >>> as the macro expansions / transformations would be more tractable in the >>> compiler. I get that it is a work in progress but let's retain that >>> original goal. >>> >>> Unlike you however, I would prefer correctness and the consequent >>> ripples over the continuing acceptance of incorrect expressions. My >>> reasoning is that code which has fewer compatibility style branches will be >>> easier to equip with the necessary instrumentation for generating more >>> human friendly error messages. >>> >>> Ray >>> >>> PS I think this require vs :require thing comes from the way that >>> novices confuse the ns macro with the function that pulls dependencies in >>> at the REPL. Cutting / pasting between the REPL and the file can allow that >>> to bleed in. I know it confused me. >>> >>> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: But creating error messages that are optimal for a user with no > knowledge or Clojure or spec is just not the goal. This is a totally false dichotomy. No-one in this thread is asking for that. This thread has several examples of expert Clojure users for whom the error messages are incomprehensible. I am equally unapologetic about thinking that the musical instrument analogy is mostly bogus here. There are things that will always be difficult about learning Clojure because they're conceptual, such as functional programming. I think the analogy is fair there, they are just things that will require effort and practice to learn. But the error messages are about giving people the information they need *so that they can actually learn from their mistakes*. Clojure has historically been appallingly bad at that, and no-one should expect their users to flail around randomly trying things to see what works. I've spoken to various smart people who have described their experience of using Clojure as exactly that, even after a non-trivial amount of time using it. I hope spec can improve on that experience. On 24 August 2016 at 02:45, Alex Miller wrote: > I do not have an idea of what the final end point will look like > exactl
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Brian originally raised 5 points that were concrete & specific, and therefore potentially actionable. That is usefully-shaped feedback, thanks Brian! My take on those points, which I will recast in my own words: 1. "Loosen rules about ns form to match what people have actually done." This is pretty unlikely, for reasons already covered. 2. "You can tailor a much better specific message for 'require should be a keyword' than what spec makes today." There are several possible things to explore here. The most interesting one is "can spec come closer to a bespoke message while maintaining its simplicity and composability?" We want to make all errors better, not one error awesome. Ideas welcome! 3. "Follow the inverted pyramid so people see what is most important." This kind of thing is easily done in a layer above spec, e.g. a custom REPL printer for spec macro errors. Worth working on but not critical to getting spec right. 4. "Name the problem namespace." Spec does way better than this already, finding the precise file and line. If there are places where this is busted we should fix them. 5. "I don't want to see the stack trace." Then filter it out of your REPL. Intermediaries should never discard telemetry, but end consumers can choose to. Cheers, Stu On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming wrote: > Sure, at the end of the day I don't really care about thre > require/:require issue, it just seems a little incongruent with previous > decisions which have promoted backwards compatibility. I generally prefer > increased strictness, so I'm fine with the change. I do care about the > error messages, though. > > On 24 August 2016 at 21:32, Mond Ray wrote: > >> I agree Colin, this feels more like the beatings shall continue until >> morale improves ;-) >> >> More seriously, I understand the point of the musical instruments analogy >> to be a reminder to programmers that learning a language and understanding >> it in depth will increase your power and expressivity with that language. >> That should not be used as a reason to increase the difficulties caused by >> obscure error reporting. My initial understanding of the sales pitch for >> specs was that it would serve to improve error messages as the macro >> expansions / transformations would be more tractable in the compiler. I get >> that it is a work in progress but let's retain that original goal. >> >> Unlike you however, I would prefer correctness and the consequent ripples >> over the continuing acceptance of incorrect expressions. My reasoning is >> that code which has fewer compatibility style branches will be easier to >> equip with the necessary instrumentation for generating more human friendly >> error messages. >> >> Ray >> >> PS I think this require vs :require thing comes from the way that novices >> confuse the ns macro with the function that pulls dependencies in at the >> REPL. Cutting / pasting between the REPL and the file can allow that to >> bleed in. I know it confused me. >> >> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: >>> >>> But creating error messages that are optimal for a user with no knowledge or Clojure or spec is just not the goal. >>> >>> >>> This is a totally false dichotomy. No-one in this thread is asking for >>> that. This thread has several examples of expert Clojure users for whom the >>> error messages are incomprehensible. >>> >>> I am equally unapologetic about thinking that the musical instrument >>> analogy is mostly bogus here. There are things that will always be >>> difficult about learning Clojure because they're conceptual, such as >>> functional programming. I think the analogy is fair there, they are just >>> things that will require effort and practice to learn. But the error >>> messages are about giving people the information they need *so that >>> they can actually learn from their mistakes*. Clojure has historically >>> been appallingly bad at that, and no-one should expect their users to flail >>> around randomly trying things to see what works. I've spoken to various >>> smart people who have described their experience of using Clojure as >>> exactly that, even after a non-trivial amount of time using it. I hope spec >>> can improve on that experience. >>> >>> >>> On 24 August 2016 at 02:45, Alex Miller wrote: >>> I do not have an idea of what the final end point will look like exactly. I don't get the feeling that there is any answer that you will find satisfying, so I'm not sure what else I can do for you. We expect Clojure users to become familiar with spec and its output as it is (now) an essential part of the language. You will see specs in error messages. The focus in Clojure has always been biased towards building a powerful and expressive tool that is rewarding for experts vs optimizing for novices. Rich has talked at length about why that is (see https://www.infoq.com/presentations/design-comp
Re: Job Opportunity | Application Developer (General)-Expert| St Louis, MO 6 months
Hi Revanth, You might want to join and post on the St. Louis Clojure meetup discussion group too to reach a more targeted audience. http://www.meetup.com/stl-clojure/ Alex On Wednesday, August 24, 2016 at 8:21:00 AM UTC-5, Revanth Kumar wrote: > > *Application Developer* > > > > Location: St Louis, MO > > Duration: 6 months > > > > *Description:* > > Provides application software development services or technical support > typically in a defined project. Develops program logic for new applications > or analyzes and modifies logic in existing applications. Codes, tests, > debug, documents, implements and maintain software applications. Analyzes > requirements, and maintains tests and integrates application components. > Ensures that system improvements are successfully implemented. Usually > requires 10-15 years of previous experience. > > > > *Required Skills: * > > *- Proficient in Clojure * > > *- Experience with AWS SQS * > > *- Experience with DynamoDB * > > *- Experience with AWS S3 * > > > > *Nice to Have: * > > - AWS Lambda > > > Any one interested please share the resume's to reva...@iconma.com or > reach me to (248) 275-1157. > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Job Opportunity | Application Developer (General)-Expert| St Louis, MO 6 months
*Application Developer* Location: St Louis, MO Duration: 6 months *Description:* Provides application software development services or technical support typically in a defined project. Develops program logic for new applications or analyzes and modifies logic in existing applications. Codes, tests, debug, documents, implements and maintain software applications. Analyzes requirements, and maintains tests and integrates application components. Ensures that system improvements are successfully implemented. Usually requires 10-15 years of previous experience. *Required Skills: * *- Proficient in Clojure * *- Experience with AWS SQS * *- Experience with DynamoDB * *- Experience with AWS S3 * *Nice to Have: * - AWS Lambda Any one interested please share the resume's to reva...@iconma.com or reach me to (248) 275-1157. -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN: konserve 0.4.0 - A clojuresque key-value/document store protocol with core.async.
Hi, I am pleased to announce the 0.4.0 release of konserve. The major change is key iteration for the file-store and a fast append-log + reducing function for all stores. >From the README: A simple document store protocol defined with core.async semantics to allow Clojuresque collection operations on associative key-value stores, both from Clojure and ClojureScript for different backends. Data is generally serialized with edn semantics or, if supported, as native binary blobs and can be accessed similar to clojure.core functions get-in,assoc-in and update-in. update-in especially allows to run functions atomically and returns old and new value. Each operation is run atomically and must be consistent (in fact ACID), but further consistency is not supported (Riak, CouchDB and many scalable solutions don't have transactions over keys for that reason). This is meant to be a building block for more sophisticated storage solutions (Datomic also builds on kv-stores). An append-log for fast writes is also implemented. https://github.com/replikativ/konserve Cheers, Christian -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
Sure, at the end of the day I don't really care about thre require/:require issue, it just seems a little incongruent with previous decisions which have promoted backwards compatibility. I generally prefer increased strictness, so I'm fine with the change. I do care about the error messages, though. On 24 August 2016 at 21:32, Mond Ray wrote: > I agree Colin, this feels more like the beatings shall continue until > morale improves ;-) > > More seriously, I understand the point of the musical instruments analogy > to be a reminder to programmers that learning a language and understanding > it in depth will increase your power and expressivity with that language. > That should not be used as a reason to increase the difficulties caused by > obscure error reporting. My initial understanding of the sales pitch for > specs was that it would serve to improve error messages as the macro > expansions / transformations would be more tractable in the compiler. I get > that it is a work in progress but let's retain that original goal. > > Unlike you however, I would prefer correctness and the consequent ripples > over the continuing acceptance of incorrect expressions. My reasoning is > that code which has fewer compatibility style branches will be easier to > equip with the necessary instrumentation for generating more human friendly > error messages. > > Ray > > PS I think this require vs :require thing comes from the way that novices > confuse the ns macro with the function that pulls dependencies in at the > REPL. Cutting / pasting between the REPL and the file can allow that to > bleed in. I know it confused me. > > On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: >> >> But creating error messages that are optimal for a user with no knowledge >>> or Clojure or spec is just not the goal. >> >> >> This is a totally false dichotomy. No-one in this thread is asking for >> that. This thread has several examples of expert Clojure users for whom the >> error messages are incomprehensible. >> >> I am equally unapologetic about thinking that the musical instrument >> analogy is mostly bogus here. There are things that will always be >> difficult about learning Clojure because they're conceptual, such as >> functional programming. I think the analogy is fair there, they are just >> things that will require effort and practice to learn. But the error >> messages are about giving people the information they need *so that they >> can actually learn from their mistakes*. Clojure has historically been >> appallingly bad at that, and no-one should expect their users to flail >> around randomly trying things to see what works. I've spoken to various >> smart people who have described their experience of using Clojure as >> exactly that, even after a non-trivial amount of time using it. I hope spec >> can improve on that experience. >> >> >> On 24 August 2016 at 02:45, Alex Miller wrote: >> >>> I do not have an idea of what the final end point will look like >>> exactly. I don't get the feeling that there is any answer that you will >>> find satisfying, so I'm not sure what else I can do for you. We expect >>> Clojure users to become familiar with spec and its output as it is (now) an >>> essential part of the language. You will see specs in error messages. >>> >>> The focus in Clojure has always been biased towards building a powerful >>> and expressive tool that is rewarding for experts vs optimizing for >>> novices. Rich has talked at length about why that is (see >>> https://www.infoq.com/presentations/design-composition- >>> performance-keynote / https://github.com/matthiasn/t >>> alk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md >>> in the section around languages as instruments). Pertinent bit (but you >>> should watch the whole thing for context): >>> >>> So we need players. I would rant here, but I won't. But look at this >>> guitar player with blisters. A harpist has blisters, a bass player with >>> blisters. There's this barrier to overcome for every musician. Imagine if >>> you downloaded something from GitHub and it gave you blisters. >>> >>> [Audience laughter] >>> >>> Right? The horrors! And yet how many people here play an instrument or >>> have at one point in their lives? Yeah, a lot of programmers do. And for >>> how many people did you just pick it up and it was awesome? How many >>> wished, like, something could have made it more straightforward to get >>> started with and, like, just made it easy? And how many would have believed >>> after that that they could play it later? No, not at all. This is - it's >>> actually quite important. The level of engagement that's required is quite >>> important. >>> >>> So we shouldn't sell humanity short. Humans are incredible. In >>> particular, they're incredible learners. >>> >>> One of the things that's really cool is you give a five-year-old or, I >>> don't know, eight, maybe, a cello and some decent instruction, and they >>
Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11
I agree Colin, this feels more like the beatings shall continue until morale improves ;-) More seriously, I understand the point of the musical instruments analogy to be a reminder to programmers that learning a language and understanding it in depth will increase your power and expressivity with that language. That should not be used as a reason to increase the difficulties caused by obscure error reporting. My initial understanding of the sales pitch for specs was that it would serve to improve error messages as the macro expansions / transformations would be more tractable in the compiler. I get that it is a work in progress but let's retain that original goal. Unlike you however, I would prefer correctness and the consequent ripples over the continuing acceptance of incorrect expressions. My reasoning is that code which has fewer compatibility style branches will be easier to equip with the necessary instrumentation for generating more human friendly error messages. Ray PS I think this require vs :require thing comes from the way that novices confuse the ns macro with the function that pulls dependencies in at the REPL. Cutting / pasting between the REPL and the file can allow that to bleed in. I know it confused me. On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: > > But creating error messages that are optimal for a user with no knowledge >> or Clojure or spec is just not the goal. > > > This is a totally false dichotomy. No-one in this thread is asking for > that. This thread has several examples of expert Clojure users for whom the > error messages are incomprehensible. > > I am equally unapologetic about thinking that the musical instrument > analogy is mostly bogus here. There are things that will always be > difficult about learning Clojure because they're conceptual, such as > functional programming. I think the analogy is fair there, they are just > things that will require effort and practice to learn. But the error > messages are about giving people the information they need *so that they > can actually learn from their mistakes*. Clojure has historically been > appallingly bad at that, and no-one should expect their users to flail > around randomly trying things to see what works. I've spoken to various > smart people who have described their experience of using Clojure as > exactly that, even after a non-trivial amount of time using it. I hope spec > can improve on that experience. > > > On 24 August 2016 at 02:45, Alex Miller > wrote: > >> I do not have an idea of what the final end point will look like exactly. >> I don't get the feeling that there is any answer that you will find >> satisfying, so I'm not sure what else I can do for you. We expect Clojure >> users to become familiar with spec and its output as it is (now) an >> essential part of the language. You will see specs in error messages. >> >> The focus in Clojure has always been biased towards building a powerful >> and expressive tool that is rewarding for experts vs optimizing for >> novices. Rich has talked at length about why that is (see >> https://www.infoq.com/presentations/design-composition-performance-keynote >> / >> https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md >> >> in the section around languages as instruments). Pertinent bit (but you >> should watch the whole thing for context): >> >> So we need players. I would rant here, but I won't. But look at this >> guitar player with blisters. A harpist has blisters, a bass player with >> blisters. There's this barrier to overcome for every musician. Imagine if >> you downloaded something from GitHub and it gave you blisters. >> >> [Audience laughter] >> >> Right? The horrors! And yet how many people here play an instrument or >> have at one point in their lives? Yeah, a lot of programmers do. And for >> how many people did you just pick it up and it was awesome? How many >> wished, like, something could have made it more straightforward to get >> started with and, like, just made it easy? And how many would have believed >> after that that they could play it later? No, not at all. This is - it's >> actually quite important. The level of engagement that's required is quite >> important. >> >> So we shouldn't sell humanity short. Humans are incredible. In >> particular, they're incredible learners. >> >> One of the things that's really cool is you give a five-year-old or, I >> don't know, eight, maybe, a cello and some decent instruction, and they >> will learn how to play cello if they spend enough time doing it. In fact, >> humans will pretty much learn how to do anything that they spend enough >> time doing. We're incredibly good at it. >> >> And we're also really good teachers, in general. So I don't think we need >> to go to our tools and our instruments and make them oriented towards the >> first five seconds of people's experien
0-arity of transducer in transduce
Hi,
I'm trying to use the transducer framework for some sequence processing
where I have a core reduction function, but depending on options, extra
functionality can be added to the reduction function. I thought that's a
good fit for hand-written transducers.
However, I'm running into a problem initializing the optional
functionality. I thought I would simply perform it in the 0-arity, like
this:
(defn my-tx
[rf]
(fn
([] (assoc (rf) ::my-ns/my-extra-field my-init-value)
...
But that's never called, at least not in transduce:
(defn transduce
"..." {:added "1.7"}
([xform f coll] (transduce xform f *(f)* coll))
([xform f init coll]
(let [f (xform f)
ret (if (instance? clojure.lang.IReduceInit coll)
(.reduce ^clojure.lang.IReduceInit coll f init)
(clojure.core.protocols/coll-reduce coll f init))]
(f ret
So, my question is: why the (f) instead of (xform f)? And what's the use of
the 0-arity in transducers if it's not called? I assume it's used in other
uses of transducers?
By the way, I understand it's tricky to call (xform f) instead, because
then what do you do with a provided init... And I also understand that I
can create initial state in the closure of the transducer, so I'm not
blocked at all. I'm just very curious :).
Thanks,
-Mathias
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
