Re: Errors

[Mars0i]

On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote:
>
> Several of the Clojure/core folks have said at various times over the 
> years that Clojure is deliberately not optimized for novices, on the 
> grounds that whilst everyone starts out as a novice, most of your time 
> spent with Clojure is beyond that stage (and an optimization for novices 
> can be a de-optimization for everyone else).
>

This makes sense for anyone with significant programming experience.  It's 
a shame, though, that Clojure would be a great language for novice 
programmers except for the error messages, which are probably a 
show-stopper for some p teachers thinking of using it for teaching.  I know 
that there are people involved in Clojure Bridge and other teaching 
programs, but as a teacher (in another discipline), I personally would have 
a hard time choosing Clojure over Scheme at this point, if I was teaching 
an intro programming course.  Clojure's probably a better language for 
later growth though, given its easy integration with Java and Javascriptl.

I'm not arguing for a change.  I like run-time performance, too.  Spec 
messages are not any good for novice programmers, either, but I'd guess 
that down the road it will be possible to build a friendly error system on 
top of spec.  Can't do that as easily with JVM stacktraces. :-)

-- 
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: Tight coupling of spec implementation and function preconditions

[Alex Miller]

I went ahead and logged this here so we don't lose it:

http://dev.clojure.org/jira/browse/CLJ-2076



On Monday, December 5, 2016 at 12:01:27 PM UTC-6, Alex Miller wrote:
>
>
>
> On Monday, December 5, 2016 at 11:53:10 AM UTC-6, Tom Locke wrote:
>>
>> I haven't watched the keynote so I look forward to that. I sure Rich's 
>> arguments will convince me, as always!
>>
>> In my case I am spec'ing rather complex and deeply nested structures. The 
>> conformed values are changed all the way down. I have a bunch of functions 
>> to interrogate these structures in useful ways, none of which I can use in 
>> my specs. What would be recommended practice here?
>>
>
> If you are mostly seeing this with s/or, then using something 
> s/nonconforming around ors could help you.
>  
>
>> In the slack channel someone mentioned a possible forthcoming version of 
>> s/and that doesn't flow conformed values through. That sounds like it might 
>> do the trick, and has the advantage of putting the decision with the spec 
>> consumer.
>>
>
> Also something we're considering. 
>

-- 
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: Errors

[Alex Miller]

On Monday, December 5, 2016 at 7:28:21 PM UTC-6, p...@pwjw.com wrote:
>
> Hi!
>

Hi Paul,
 

>
> Boy I really think you've all done a nice job with Clojure. I've used 
> quite a few environments over the years and clojure + CIDER + etc is a 
> great experience. The immutability and threading are smart. I've been able 
> to finish a hobby project in clojure which I've been mulling for a long 
> time and never found the right environment. Super stuff.
>
> And the error messages are not good.
>

If I can make a request, it would be that instead of saying "errors are 
bad" (which is honestly, not helpful by itself), but to step back and 
either take a broader approach towards systemic issues or to file and work 
tickets for specific cases/messages, so they can actually be fixed.
 

> So I was wondering: Is this a philosophical thing? 
>

There is certainly no philosophy that errors should be bad. I would say 
that the state of things right now is more a side effect of prioritization 
and choices over many years. Rich's focus has typically been on building 
powerful expressive tools vs the beginner experience (I'd recommend 
watching his Design, Composition & Performance talk for more background on 
that). That said, there is no reason not to also improve the experience for 
newer users.
 

> Or is it an effort thing? And if it is an effort thing, is there some sort 
> of plan for what effort to put in? And if so, can I help by closing tickets?
>

My first wish would be that you log tickets for stuff like the one below. 
Providing patches would be a helpful next step. Everything is gated by the 
rate at which Rich looks at tickets though.
 

> Here's one, for instance, which bugs me (using a build of branch master in 
> clojure from github just now)
>
> user=> (+ 1 1)
>
> 2
>
> user=> (1 + 1)
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
> user/eval17 (NO_SOURCE_FILE:10)
>
>
>
>
> OK but what sort of noob would actually type in 1 + 1? (That's a joke. 
> Lots of people would. And I do sometimes when switching between java and 
> clojure) But that same error pops up if you misalign in parenthesis or 
> confuse an argument order or do a variety of other things.
>
> And that error message is terrible. I mean I know why it is there. Clojure 
> needs the first element of a list be the function position and 1 is not a 
> function, it is a long. But you have to squint rather generously at that 
> message to get to the problem. Or just learn what that message "really" 
> means, which seems a bit unfriendly.
>
> And so when I go look inside the source 
>
> user=> (print-stack-trace *e 20)
>
> java.lang.ClassCastException: java.lang.Long cannot be cast to 
> clojure.lang.IFn
>
>  at user$eval9.invokeStatic (NO_SOURCE_FILE:6)
>
> user$eval9.invoke (NO_SOURCE_FILE:6)
>
> clojure.lang.Compiler.eval (Compiler.java:6978)
>
> clojure.lang.Compiler.eval (Compiler.java:6941)
>
>
>
> Compiler.java has
>
> IFn fn = (IFn) fexpr.eval();
>
> return fn.invoke();
>
>
> Which of course throws a class cast exception.
>
>
> But there's so much information right there. Imagine this (in pseudo-code) 
> as
>
>
> Object f = fexpr.eval();
>
> if (f instanceof IFn) return (IFn)f.invoke()
>
> else throw ClojureNotAFunctionEvaluationError "First position in form at 
> line " ... " of environment " ... " is not a function object. You handed me 
> " + fexpr.first() " in form " ... " which has type " fexpr.first().class() 
> " and value " fexpr.first().toString()
>
>
> or whatever (like maybe don't toString values - that's why you'd want a 
> plan. And maybe use a string table so you can internationalize. Again, plan 
> :) )
>

Another thing to keep in mind is that you may be underestimating the full 
set of paths that lead to this particular error and whether the error 
message you are crafting makes sense in all of them. In runtime code, 
constructing better errors changes the size of the generated code, which 
can affect the ability of the JVM to inline code and lead to unexpected 
performance degradations (we've had to pull error message improvements for 
this in the past). I say this not to dissuade us, but just to highlight 
that things are not always as easy as they seem at first.
 

> so I almost want to whack this sort of stuff into a local copy as I hit 
> error messages which bug me, but that seems foolish. And anyway I'm new 
> here.
>

Logging bugs is helpful. A search for dupes is helpful, but not essential. 
I am mostly aware of what's in the system already and will dedupe as needed.
 

> Sorry if I have accidentally stepped into some sort of landmine or if this 
> has been rehashed a million times.
>
>
> But I figured, in the spirit of being willing to help if there's help to 
> be applied, I would ask if there's some sort of thinking on this topic for 
> 1.9.1 or 1.10 or something?
>

I have spent some time thinking about 

Re: Errors

[Mikera]

On Tuesday, 6 December 2016 10:47:42 UTC+8, James Reeves wrote:
>
> On 6 December 2016 at 01:28,  wrote:
>>
>> And the error messages are not good.
>>
>> So I was wondering: Is this a philosophical thing? Or is it an effort 
>> thing? And if it is an effort thing, is there some sort of plan for what 
>> effort to put in? And if so, can I help by closing tickets?
>>
>
> This is an issue that's been discussed often.
>
> The fundamental problem is that in a dynamically typed language, good 
> error messages are often at odds with runtime performance. The more checks 
> we add to catch specific scenarios, or to provide more descriptive 
> scenarios, the more performance tends to be impacted.
>
>
Runtime checks are clearly bad for performance, but this kind of thing can 
typically be done at compile time, with no runtime cost.

>

-- 
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: Errors

[Sean Corfield]

> I cherrypicked a case where the runtime difference would be tiny

 

I wouldn’t be so sure of that. Adding any additional code to the function call 
logic is going to impact almost every single expression in Clojure and that 
“tiny” difference is going to add up pretty fast.

 

As others have noted, runtime performance is a Big Deal™ for Clojure and that 
means that some things are traded off for that speed.

 

Also, as others have noted, this topic comes up repeatedly, probably a handful 
of times a year in some form or other. After using Clojure in production for 
just over five and a half years now, all I can say is: you get used to the 
error messages and you develop an intuition for what most of them mean. Several 
of the Clojure/core folks have said at various times over the years that 
Clojure is deliberately not optimized for novices, on the grounds that whilst 
everyone starts out as a novice, most of your time spent with Clojure is beyond 
that stage (and an optimization for novices can be a de-optimization for 
everyone else).

 

My pet peeve is that clojure.string is not nil-safe. (str nil) produces “” but 
if you pass nil to pretty much any clojure.string function, you get a NPE 
instead. You might think “Hey, it would only be a tiny difference if 
clojure.string functions accepted nil and treated it as an empty string!” … 
until you create a fork of Clojure with that modification and run some 
benchmarks … J

 

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."
-- Margaret Atwood

 

On 12/5/16, 7:04 PM, "Paul Walker"  wrote:

 

Yeah I understand that tradeoff. I cherrypicked a case where the runtime 
difference would be tiny but others are harder I’m sure.

 

I guess I will go figure out how spec applies to my project.

 

Thanks as always. This group is so responsive. Appreciated.

 

    - Paul

 

On Dec 5, 2016, at 9:46 PM, James Reeves  wrote:

 

On 6 December 2016 at 01:28,  wrote:

And the error messages are not good.

 

So I was wondering: Is this a philosophical thing? Or is it an effort thing? 
And if it is an effort thing, is there some sort of plan for what effort to put 
in? And if so, can I help by closing tickets?

 

This is an issue that's been discussed often.

 

The fundamental problem is that in a dynamically typed language, good error 
messages are often at odds with runtime performance. The more checks we add to 
catch specific scenarios, or to provide more descriptive scenarios, the more 
performance tends to be impacted.

 

However, Clojure 1.9.0 may have a solution to that in the form of specs. We can 
turn on specs selectively at development time, so we get the benefit of 
detailed error messages, while in production we can turn them off for 
performance.

 

- James

 

-- 
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 a topic in the Google 
Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/ANKq6XD1nW8/unsubscribe.
To unsubscribe from this group and all its topics, 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.


-- 
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 

Re: Errors

[Paul Walker]

Yeah I understand that tradeoff. I cherrypicked a case where the runtime 
difference would be tiny but others are harder I’m sure.

I guess I will go figure out how spec applies to my project.

Thanks as always. This group is so responsive. Appreciated.

- Paul

> On Dec 5, 2016, at 9:46 PM, James Reeves  wrote:
> 
> On 6 December 2016 at 01:28, > wrote:
> And the error messages are not good.
> 
> So I was wondering: Is this a philosophical thing? Or is it an effort thing? 
> And if it is an effort thing, is there some sort of plan for what effort to 
> put in? And if so, can I help by closing tickets?
> 
> This is an issue that's been discussed often.
> 
> The fundamental problem is that in a dynamically typed language, good error 
> messages are often at odds with runtime performance. The more checks we add 
> to catch specific scenarios, or to provide more descriptive scenarios, the 
> more performance tends to be impacted.
> 
> However, Clojure 1.9.0 may have a solution to that in the form of specs. We 
> can turn on specs selectively at development time, so we get the benefit of 
> detailed error messages, while in production we can turn them off for 
> performance.
> 
> - James
> 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/ANKq6XD1nW8/unsubscribe 
> .
> To unsubscribe from this group and all its topics, 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: Errors

[James Reeves]

On 6 December 2016 at 01:28,  wrote:
>
> And the error messages are not good.
>
> So I was wondering: Is this a philosophical thing? Or is it an effort
> thing? And if it is an effort thing, is there some sort of plan for what
> effort to put in? And if so, can I help by closing tickets?
>

This is an issue that's been discussed often.

The fundamental problem is that in a dynamically typed language, good error
messages are often at odds with runtime performance. The more checks we add
to catch specific scenarios, or to provide more descriptive scenarios, the
more performance tends to be impacted.

However, Clojure 1.9.0 may have a solution to that in the form of specs. We
can turn on specs selectively at development time, so we get the benefit of
detailed error messages, while in production we can turn them off for
performance.

- James

-- 
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: Errors

[Gary Trakhman]

I think it has been rehashed often and core is very conservative about
changes, but the current latest and greatest for improving many kinds of
errors is going to be clojure.spec, which runs parallel to the actual
execution path, so as not to effect things like performance or old code
that depends on the specific weird behaviors in core.
http://clojure.org/guides/spec

On Mon, Dec 5, 2016 at 8:28 PM  wrote:

> Hi!
>
> Boy I really think you've all done a nice job with Clojure. I've used
> quite a few environments over the years and clojure + CIDER + etc is a
> great experience. The immutability and threading are smart. I've been able
> to finish a hobby project in clojure which I've been mulling for a long
> time and never found the right environment. Super stuff.
>
> And the error messages are not good.
>
> So I was wondering: Is this a philosophical thing? Or is it an effort
> thing? And if it is an effort thing, is there some sort of plan for what
> effort to put in? And if so, can I help by closing tickets?
>
> Here's one, for instance, which bugs me (using a build of branch master in
> clojure from github just now)
>
> user=> (+ 1 1)
>
> 2
>
> user=> (1 + 1)
>
> ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn
> user/eval17 (NO_SOURCE_FILE:10)
>
>
>
>
> OK but what sort of noob would actually type in 1 + 1? (That's a joke.
> Lots of people would. And I do sometimes when switching between java and
> clojure) But that same error pops up if you misalign in parenthesis or
> confuse an argument order or do a variety of other things.
>
> And that error message is terrible. I mean I know why it is there. Clojure
> needs the first element of a list be the function position and 1 is not a
> function, it is a long. But you have to squint rather generously at that
> message to get to the problem. Or just learn what that message "really"
> means, which seems a bit unfriendly.
>
> And so when I go look inside the source
>
> user=> (print-stack-trace *e 20)
>
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> clojure.lang.IFn
>
>  at user$eval9.invokeStatic (NO_SOURCE_FILE:6)
>
> user$eval9.invoke (NO_SOURCE_FILE:6)
>
> clojure.lang.Compiler.eval (Compiler.java:6978)
>
> clojure.lang.Compiler.eval (Compiler.java:6941)
>
>
>
> Compiler.java has
>
> IFn fn = (IFn) fexpr.eval();
>
> return fn.invoke();
>
>
> Which of course throws a class cast exception.
>
>
> But there's so much information right there. Imagine this (in pseudo-code)
> as
>
>
> Object f = fexpr.eval();
>
> if (f instanceof IFn) return (IFn)f.invoke()
>
> else throw ClojureNotAFunctionEvaluationError "First position in form at
> line " ... " of environment " ... " is not a function object. You handed me
> " + fexpr.first() " in form " ... " which has type " fexpr.first().class()
> " and value " fexpr.first().toString()
>
>
> or whatever (like maybe don't toString values - that's why you'd want a
> plan. And maybe use a string table so you can internationalize. Again, plan
> :) )
>
>
> so I almost want to whack this sort of stuff into a local copy as I hit
> error messages which bug me, but that seems foolish. And anyway I'm new
> here.
>
>
> Sorry if I have accidentally stepped into some sort of landmine or if this
> has been rehashed a million times.
>
>
> But I figured, in the spirit of being willing to help if there's help to
> be applied, I would ask if there's some sort of thinking on this topic for
> 1.9.1 or 1.10 or something?
>
>
> Thanks
>
>
>   Paul
>
> --
> 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 

Errors

[paul]

Hi!

Boy I really think you've all done a nice job with Clojure. I've used quite 
a few environments over the years and clojure + CIDER + etc is a great 
experience. The immutability and threading are smart. I've been able to 
finish a hobby project in clojure which I've been mulling for a long time 
and never found the right environment. Super stuff.

And the error messages are not good.

So I was wondering: Is this a philosophical thing? Or is it an effort 
thing? And if it is an effort thing, is there some sort of plan for what 
effort to put in? And if so, can I help by closing tickets?

Here's one, for instance, which bugs me (using a build of branch master in 
clojure from github just now)

user=> (+ 1 1)

2

user=> (1 + 1)

ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn  
user/eval17 (NO_SOURCE_FILE:10)




OK but what sort of noob would actually type in 1 + 1? (That's a joke. Lots 
of people would. And I do sometimes when switching between java and 
clojure) But that same error pops up if you misalign in parenthesis or 
confuse an argument order or do a variety of other things.

And that error message is terrible. I mean I know why it is there. Clojure 
needs the first element of a list be the function position and 1 is not a 
function, it is a long. But you have to squint rather generously at that 
message to get to the problem. Or just learn what that message "really" 
means, which seems a bit unfriendly.

And so when I go look inside the source 

user=> (print-stack-trace *e 20)

java.lang.ClassCastException: java.lang.Long cannot be cast to 
clojure.lang.IFn

 at user$eval9.invokeStatic (NO_SOURCE_FILE:6)

user$eval9.invoke (NO_SOURCE_FILE:6)

clojure.lang.Compiler.eval (Compiler.java:6978)

clojure.lang.Compiler.eval (Compiler.java:6941)



Compiler.java has

IFn fn = (IFn) fexpr.eval();

return fn.invoke();


Which of course throws a class cast exception.


But there's so much information right there. Imagine this (in pseudo-code) 
as


Object f = fexpr.eval();

if (f instanceof IFn) return (IFn)f.invoke()

else throw ClojureNotAFunctionEvaluationError "First position in form at 
line " ... " of environment " ... " is not a function object. You handed me 
" + fexpr.first() " in form " ... " which has type " fexpr.first().class() 
" and value " fexpr.first().toString()


or whatever (like maybe don't toString values - that's why you'd want a 
plan. And maybe use a string table so you can internationalize. Again, plan 
:) )


so I almost want to whack this sort of stuff into a local copy as I hit 
error messages which bug me, but that seems foolish. And anyway I'm new 
here.


Sorry if I have accidentally stepped into some sort of landmine or if this 
has been rehashed a million times.


But I figured, in the spirit of being willing to help if there's help to be 
applied, I would ask if there's some sort of thinking on this topic for 
1.9.1 or 1.10 or something?


Thanks


  Paul

-- 
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: Tight coupling of spec implementation and function preconditions

[Tom Locke]

I haven't watched the keynote so I look forward to that. I sure Rich's 
arguments will convince me, as always!

In my case I am spec'ing rather complex and deeply nested structures. The 
conformed values are changed all the way down. I have a bunch of functions 
to interrogate these structures in useful ways, none of which I can use in 
my specs. What would be recommended practice here?

In the slack channel someone mentioned a possible forthcoming version of 
s/and that doesn't flow conformed values through. That sounds like it might 
do the trick, and has the advantage of putting the decision with the spec 
consumer.

-- 
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: Tight coupling of spec implementation and function preconditions

[Alex Miller]

On Monday, December 5, 2016 at 11:18:47 AM UTC-6, Tom Locke wrote:
>
> I'm sure this is a well known issue, but I've not found much written about 
> it online.
>
> In the spec guide, we have this example of spec'ing a function
>
> (s/fdef ranged-rand
>   :args (s/and (s/cat :start int? :end int?)
>#(< (:start %) (:end %)))
>   ...)
>
> This form, an s/cat within an s/and, is going to be a standard pattern 
> whenever you want to express some cross-argument constraint. It will be 
> common to use keyword references to specs
>
> (s/fdef f
>   :args (s/and (s/cat :arg1 ::foo, :arg2 ::baa)
>#(... constraint expr ...)
>   ...)
>
> The problem is that the constraint expression has to work on conformed 
> versions of the args, not the simple values passed by the caller, and so is 
> tightly coupled to the implementation of ::foo and ::baa, and liable to 
> break when those specs change.
>

I'd say that you *are* and *should be* tightly coupled to what ::foo and 
::baa are specifying. And you should not "change" them - you should either 
grow them or create a new name. (See Rich's keynote from the conj.)
 

> There is s/unform, but I've found it to not work in all cases, e.g. 
>
> (->> [1 2 "blah"] 
>  (s/conform (s/coll-of (s/or :i integer? :s string?)))
>  (s/unform  (s/coll-of (s/or :i integer? :s string?
> => [[:i 1] [:i 2] [:s "blah"]]
>
> If I am understanding correctly, I should get the original vector there.
>

You definitely should. A quick glance indicates that's a bug for coll-of 
and map-of (and not one I was aware of). Please file a jira.

Aside from this problem, it would be a bit cumbersome to have to unform 
> everything in those preconditions.
>

There are several kinds of specs that conform to a value other than the 
original value (not considering nested specs/values) - namely s/or and all 
of the regex ops. It is possible to undo the conformation with s/conformer 
(but standard caveats about making choices for consumers of your specs 
apply). Additionally, there is an undocumented s/nonconforming that will 
avoid conforming a spec to anything but the original value. Rich is still 
on the fence about whether this should exist or not so I hesitate to 
recommend its use (it may be removed in a subsequent alpha) but might be 
interesting to look at.
 

> Any insight appreciated!
>
> Tom
>

-- 
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.

Tight coupling of spec implementation and function preconditions

[Tom Locke]

I'm sure this is a well known issue, but I've not found much written about 
it online.

In the spec guide, we have this example of spec'ing a function

(s/fdef ranged-rand
  :args (s/and (s/cat :start int? :end int?)
   #(< (:start %) (:end %)))
  ...)

This form, an s/cat within an s/and, is going to be a standard pattern 
whenever you want to express some cross-argument constraint. It will be 
common to use keyword references to specs

(s/fdef f
  :args (s/and (s/cat :arg1 ::foo, :arg2 ::baa)
   #(... constraint expr ...)
  ...)

The problem is that the constraint expression has to work on conformed 
versions of the args, not the simple values passed by the caller, and so is 
tightly coupled to the implementation of ::foo and ::baa, and liable to 
break when those specs change.

There is s/unform, but I've found it to not work in all cases, e.g. 

(->> [1 2 "blah"] 
 (s/conform (s/coll-of (s/or :i integer? :s string?)))
 (s/unform  (s/coll-of (s/or :i integer? :s string?
=> [[:i 1] [:i 2] [:s "blah"]]

If I am understanding correctly, I should get the original vector there.

Aside from this problem, it would be a bit cumbersome to have to unform 
everything in those preconditions.

Any insight appreciated!

Tom

-- 
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: What does "Map literal must contain an even number of forms" mean?

[larry google groups]

This:

(defn turd [] 
{:c "Turd" :d "More Turd"})

Would return this map:

{:c "Turd" :d "More Turd"}


This:

(defn config [username password] 
{:u username :p *password*})

returns a map based on the function arguments. 




On Monday, December 5, 2016 at 10:41:33 AM UTC-5, larry google groups wrote:
>
>
> This is all you need:
>
> {:c "Turd" :d "More Turd"}
>
>
>
> (defn turd [] 
> {:c "Turd" :d "More Turd"})
>
>
> On Sunday, December 4, 2016 at 4:03:04 PM UTC-5, bill nom nom wrote:
>>
>> ;; This works,
>> (hash-map :a 1 :b 2 )
>>
>>
>> ;; Here's another way to create a hash map, this won't work because map
>> ;; literal must contain even number of forms
>>  {hash-map :c "Turd" :d "More Turd"}
>>
>> What does "Map literal must contain an even number of forms" mean?
>>
>>

-- 
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: What does "Map literal must contain an even number of forms" mean?

[larry google groups]

This is all you need:

{:c "Turd" :d "More Turd"}



(defn turd [] 
{:c "Turd" :d "More Turd"})


On Sunday, December 4, 2016 at 4:03:04 PM UTC-5, bill nom nom wrote:
>
> ;; This works,
> (hash-map :a 1 :b 2 )
>
>
> ;; Here's another way to create a hash map, this won't work because map
> ;; literal must contain even number of forms
>  {hash-map :c "Turd" :d "More Turd"}
>
> What does "Map literal must contain an even number of forms" mean?
>
>

-- 
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] data.xml 0.1.0-beta3

[Herwig Hochleitner]

data.xml is a Clojure contrib library that parses and emits XML.

Github: https://github.com/clojure/data.xml
Changelog: https://github.com/clojure/data.xml/blob/master/CHANGES.md

Information on updating the dependency is here
.

0.1.0-beta3 contains a fix for default namespaces, as well as location info
support.
This will likely be the last release of the 0.1.0 series. Stay tuned for a
0.2.0-alpha release.

Thanks to Tamas Jung and all data.xml contributors.

-- 
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.

Call for Participation: BOB 2017 (February 24, Berlin)

[Michael Sperber]

Several Clojure talks at BOB - also, joint registration discounts with 
:clojureD, which is also in Berlin, on the very next day!



   BOB 2017
  Conference

 "What happens if we simply use what's best?"
   February 24, 2017
Berlin
   http://bobkonf.de/2017/
   Program:
 http://bobkonf.de/2017/program.html
Registration:
   http://bobkonf.de/2017/registration.html



BOB is the conference for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today.
Our goal is for all participants of BOB to return home with new
insights that enable them to improve their own software development
experiences.

The program features 14 talks and 8 tutorials on current topics:

http://bobkonf.de/2017/program.html

The subject range of talks includes functional programming, advanced
front-end development, and sophisticated uses of types.

The tutorials feature introductions to Haskell, Swift, PureScript,
React, QuickCheck, Agda, CRDTs and Servant.

John Hughes will give the keynote talk.

Registration is open online:

http://bobkonf.de/2017/registration.html

NOTE: The early-bird rates expire on January 23, 2017!

BOB cooperates with the :clojured conference on the following day.
There is a registration discount available for participants of both events.

http://www.clojured.de/


-- 
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: Clojure as a first programming language?

[Colin Fleming]

On 5 December 2016 at 02:56, 'Lee Spector' via Clojure <
clojure@googlegroups.com> wrote:

Colin Fleming has done some nice work on this in Cursive.
>

Sadly that work is not in Cursive proper yet, although I'm planning to get
it in there soon once I work out what I'm doing with spec.

However I think macro errors are only a part of what Nathan is asking for.
It's true that they cause some of the more confusing stacktraces, but there
are other errors which cause stack traces but which are really compiler
errors. I've been considering some kind of pattern matching system to try
to work out from a stacktrace what the problem really is. After all,
experienced Clojure developers can often work out easily what the issue is
from a stacktrace, so I'm sure a machine can too. However although I'm
considering this, I don't have it at the proof of concept stage yet.


> ... I am currently planning to revisit Proto REPL (in Atom), following a
> nice talk on it by Jason Gilman at Clojure Conj 2016:
> https://www.youtube.com/watch?v=buPPGxOnBnk


I agree, that talk was great and Proto REPL looks lovely. I think it would
probably be a great match for your needs.

Cheers,
Colin




>
>  -Lee
>
> --
> 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: What does "Map literal must contain an even number of forms" mean?

[Karel Miarka]

(hash-map :a 1 :b 2) is equivalent of {:a 1 :b 2} so this will work: {:c "Turd" 
:d "More Turd"}



On Sunday, December 4, 2016 at 10:03:04 PM UTC+1, bill nom nom wrote:
>
> ;; This works,
> (hash-map :a 1 :b 2 )
>
>
> ;; Here's another way to create a hash map, this won't work because map
> ;; literal must contain even number of forms
>  {hash-map :c "Turd" :d "More Turd"}
>
> What does "Map literal must contain an even number of forms" mean?
>
>

-- 
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.

ClojureScript talk

[Asher Coren]

Here is the link to a talk I gave in the last Clojure Conj, about 
developing a web app with ClojureScript:

https://www.youtube.com/watch?v=K6ZoF3CHsa0

Good for beginners and intermediates.

-- 
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.