Re: Lisp/Scheme Style Guide

On Tue, 31 Aug 2010 15:40:10 -0600
"Eric Schulte" <schulte.eric <at> gmail.com> wrote:

> I apologize for apparently re-opening some fresh wounds.
> 
> I wasn't trying to assert that these guidelines should be universally
> adopted or enforced.
> 
> There are a number of conventions that exist for writing lisp, and I
> thought that this paper was interesting because it
> - collects and explicitly states many of these conventions which are
>   rarely spelled out explicitly
> - attempts to explain some of the conventions that can be mystifying at
>   first
> - offers genuinely good readability and maintenance reasons for some of
>   the mentioned conventions

That was pretty much my impression as well - it was more a collection
of stylistic  "best practices" than a real style guide - at least
until he gets down to "Naming", at which point it starts becoming a
bit more opinion than observed practices.

    <mike
-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

--

-- 

Re: NullPointerExecption after Java class import

Re: Lisp/Scheme Style Guide

On Tue, 31 Aug 2010 15:41:13 -0700
Greg <greg <at> kinostudios.com> wrote:

> On Aug 31, 2010, at 2:35 PM, fin wrote:
> 
> >> The concept of the One-Style-To-Rule-Them-All is just childish.
> > 
> > Have you read "Style is Substance"?
> > http://www.artima.com/weblogs/viewpost.jsp?thread=74230
> 
> No, I hadn't, thanks for the link.
> 
> I tried to read the whole thing but stopped after reading what he considered to be "logic".
> 
> Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in
fact quite questionable.
> 
> I can rip them apart if you'd like:

Except you didn't. At best, you ripped apart a straw man based.

> Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly
greater than any of the common styles.
> 
> All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this
statement is.
> 
> People get very passionate about their preferred style, and if you ask them to write in another style they
will complain and cringe and claim that some such or other capability of theirs is being hampered.

Um, read the explanation: he's talking about productivity and code
quality. He didn't say people didn't care about styles, or weren't
passionate about styles. Which means you haven't addressed his issues,
just your straw man.

> He is making an objective claim about something that is totally, completely, subjective.

Productivity and code quality are totally, completely, subjective? So
all the many, many words written about things agile development,
quality engineering, productivity measures, software lifecycles, and
so on - are basically meaningless, because they're trying to improve
things that are totally, completely subjective?

> Premise 4: For any non-trivial project, a common coding style is a good thing.
> 
> Relevant quote: "having several folks hacking on the same code with conflicting coding styles
introduces more pain than any single style imposes on any single person."

I'm willing to grant that one on slightly less solid ground. He's
assuming that 1) the project chose a reasonable style, as opposed to
one designed to obfuscate code, and 2) that the people involved are
likewise not outliers, and can deal with any reasonable coding style.

But granted that, his statement pretty much stands as is.

> Here he introduces the concept of "conflicting coding styles" without explaining what the hell that is. I
have seen many projects that have different code style interspersed throughout, yet how they were
conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity.
Whether or not a code style is in so-called "conflict" with another is a completely subjective phenomenon
that depends on the observer.
> 
> In fact I regularly use different code styles within my own code, and they are in no way in conflict, in fact,
to me they very much appear to work together in harmony. Some scenarios lend themselves to one style, while
others lend themselves to a different one.

> My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer.
> 

OK, maybe you're one of the outliers, and don't have any problems with
reasonable (or even unreasonable) styles. Yeah, I can see how that
would help you.

I also regularly work on such projects myself, and changing styles in
mid-stream is similar to changing languages in mid-stream: I have to
reset how my mind parses things. That projects *have* style guides
indicate that others also have this problem. Just like Ken said -
adopting any single reasonable style causes me (and probably most
people) a lot less grief than letting me use my (or them use their)
preferred style but having to switch styles between files, or worse
yet, functions.

> Either you:
> 
> 1) Mandate code style to be a part of the language's syntax.
> 
> or you:
> 
> 2) Grow up and learn to accept the reality that some people think differently from you.

And the reason for the posting: you missed a VERY common third
alternative. Or at least, it's commonly suggested, though I don't know
that any project has actually implemented it:

3) Have your scm format code to canonical form when it's checked in.

     <mike
-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Minor macroexpand issue

I agree, that's not the expected behavior. The form is just data, it
doesn't have to be valid code. Since '(Object) is not a macro (Object
is a Symbol there, not a class) it should just return the form just
like (identity) does:
user=> (identity '(Object))
(Object)

But macroexpand-1 does some extra work for the interop sugar. I
suspect that the error comes when it tries to work out a static
member.

user=> (macroexpand-1 '(.length "s"))
(. "s" length)
user=> (macroexpand-1 '(Boolean/TRUE))
(. Boolean TRUE)
user=> (macroexpand-1 '(String.))
(new String)

On Aug 31, 3:17 pm, Frederic Koehler <f.koehler... <at> gmail.com> wrote:
> If you were to say, (macroexpand '(foo)), it returns (foo), even if it's
> not defined in the context, so I'd say it's a little unexpected.
>
> More annoying is the result this has on macroexpand-all, which breaks
> because of this weird behaviour:
>
> (use 'clojure.walk)
> (walk/macroexpand-all '(let [Object (fn [])] (Object)))
>
> java.lang.RuntimeException: java.lang.Exception: Expecting var, but
> Object is mapped to class java.lang.Object (NO_SOURCE_FILE:0)
>
> Of course, this example is somewhat (not super-) obvious, but in more
> complex cases it could be fairly annoying.
>
>
>
> On Tue, 2010-08-31 at 08:14 +0200, Konrad Hinsen wrote:
> > On 30 Aug 2010, at 23:18, Frederic Koehler wrote:
>
> > > I accidentally noticed this:
>
> > > On clojure 1.2,  macroexpanding with a function name which is a class,
> > > causes this ugly error:
>
> > >> (macroexpand '(Object))
> > > java.lang.Exception: Expecting var, but Object is mapped to class
> > > java.lang.Object (repl-1:2)
>
> > > when presumably it should just give '(Object).
> > > I have no clue for any actual use cases of naming your functions after
> > > classes, but:
> > > (let [Object (fn [] 3)] (Object))
> > > is technically valid clojure code, so macroexpand shouldn't just  
> > > die...
>
> > You are right that
>
> >    (let [Object (fn [] 3)] (Object))
>
> > is valid Clojure code, and it works as expected. However,
>
> >    (Object)
>
> > is not a valid expression. It fails with exactly the same error  
> > message as
>
> >    (macroexpand '(Object))
>
> > so I'd say this is consistent behaviour.
>
> > Konrad.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en- Hide quoted text -
>
> - Show quoted text -

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Lisp/Scheme Style Guide

On Aug 31, 2010, at 5:26 PM, Mike Meyer wrote:

> Um, read the explanation: he's talking about productivity and code
> quality. He didn't say people didn't care about styles, or weren't
> passionate about styles. Which means you haven't addressed his issues,
> just your straw man.

There is no straw man, I understood his point fully.

People choose various styles for various reasons, and those reasons include productivity and code quality.

I listed many reasons related to productivity and code quality in a blog post describing the reasons some
choose to trail their parenthesis:

http://gregslepak.posterous.com/on-lisps-readability

It is also interesting to note, that among the responses to that post, it was brought up that some prefer to
stack their parenthesis because it "compactifies" their code, thereby letting them see more code
per-square inch of screen real-estate. They mentioned that this could be very useful if, for example,
you're in a situation were you don't have a large screen to work on (i.e. a netbook).

I think that's a very valid reason to prefer stacked parenthesis. It's rational and it relates to
productivity. More power to them. I don't use a netbook though and usually code on a large monitor, so I can
write using trailing parenthesis and get the added benefits that I mentioned in the post. To each his own!

As someone once observed, programming is very much like painting or other artistic endeavors.

It would be a tragedy if The State ordered Picasso to make his paintings more realistic, ("Yes, we can see how
you might imagine that to be a building, but We say it has to be done this way."), or to use a particular kind or
brush or stroke.

There is always controversy when someone steps outside the wall of How Things Are Done. But that is what
makes life interesting and worthwhile. The same song played over and over eventually loses its magic.

So there are both practical and philosophical reasons to embrace the existence of diversity in code style,
and of all the languages out there, it would be ironic and most tragic if the language that facilitates the
most freedom of expression, were to be hijacked by the Style Police.

- Greg

> On Tue, 31 Aug 2010 15:41:13 -0700
> Greg <greg <at> kinostudios.com> wrote:
> 
>> On Aug 31, 2010, at 2:35 PM, fin wrote:
>> 
>>>> The concept of the One-Style-To-Rule-Them-All is just childish.
>>> 
>>> Have you read "Style is Substance"?
>>> http://www.artima.com/weblogs/viewpost.jsp?thread=74230
>> 
>> No, I hadn't, thanks for the link.
>> 
>> I tried to read the whole thing but stopped after reading what he considered to be "logic".
>> 
>> Premise #2 and #4 were introduced as facts yet consisted of 100% subjective opinion, that is, I think in
fact quite questionable.
>> 
>> I can rip them apart if you'd like:
> 
> Except you didn't. At best, you ripped apart a straw man based.
> 
>> Premise 2: There is not now, nor will there ever be, a programming style whose benefit is significantly
greater than any of the common styles.
>> 
>> All you have to do is take one look at the blood that has been spilled over this topic to see how untrue this
statement is.
>> 
>> People get very passionate about their preferred style, and if you ask them to write in another style they
will complain and cringe and claim that some such or other capability of theirs is being hampered.
> 
> Um, read the explanation: he's talking about productivity and code
> quality. He didn't say people didn't care about styles, or weren't
> passionate about styles. Which means you haven't addressed his issues,
> just your straw man.
> 
>> He is making an objective claim about something that is totally, completely, subjective.
> 
> Productivity and code quality are totally, completely, subjective? So
> all the many, many words written about things agile development,
> quality engineering, productivity measures, software lifecycles, and
> so on - are basically meaningless, because they're trying to improve
> things that are totally, completely subjective?
> 
>> Premise 4: For any non-trivial project, a common coding style is a good thing.
>> 
>> Relevant quote: "having several folks hacking on the same code with conflicting coding styles
introduces more pain than any single style imposes on any single person."
> 
> I'm willing to grant that one on slightly less solid ground. He's
> assuming that 1) the project chose a reasonable style, as opposed to
> one designed to obfuscate code, and 2) that the people involved are
> likewise not outliers, and can deal with any reasonable coding style.
> 
> But granted that, his statement pretty much stands as is.
> 
>> Here he introduces the concept of "conflicting coding styles" without explaining what the hell that is.
I have seen many projects that have different code style interspersed throughout, yet how they were
conflicting is beyond me. This is yet another area where he confuses subjectivity with objectivity.
Whether or not a code style is in so-called "conflict" with another is a completely subjective phenomenon
that depends on the observer.
>> 
>> In fact I regularly use different code styles within my own code, and they are in no way in conflict, in
fact, to me they very much appear to work together in harmony. Some scenarios lend themselves to one style,
while others lend themselves to a different one.
> 
>> My ability to not complain and adapt to understanding their style has not hurt but helped me as a programmer.
>> 
> 
> OK, maybe you're one of the outliers, and don't have any problems with
> reasonable (or even unreasonable) styles. Yeah, I can see how that
> would help you.
> 
> I also regularly work on such projects myself, and changing styles in
> mid-stream is similar to changing languages in mid-stream: I have to
> reset how my mind parses things. That projects *have* style guides
> indicate that others also have this problem. Just like Ken said -
> adopting any single reasonable style causes me (and probably most
> people) a lot less grief than letting me use my (or them use their)
> preferred style but having to switch styles between files, or worse
> yet, functions.
> 
>> Either you:
>> 
>> 1) Mandate code style to be a part of the language's syntax.
>> 
>> or you:
>> 
>> 2) Grow up and learn to accept the reality that some people think differently from you.
> 
> And the reason for the posting: you missed a VERY common third
> alternative. Or at least, it's commonly suggested, though I don't know
> that any project has actually implemented it:
> 
> 3) Have your scm format code to canonical form when it's checked in.
> 
>     <mike
> -- 
> Mike Meyer <mwm <at> mired.org>		http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
> 
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure <at> 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+unsubscribe <at> 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 post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Ed Lambda: Functional programming meetup in Edinburgh

Hi guys,

I'm running a meetup for functional programming in Edinburgh. The
first one will be on the 13th of September at Malone's Irish Bar (14
Forrest Road) and will continue every 2nd monday of each month. For
the first meetup I think we'll just be having a chat and getting to
know each other but I hope to be able to expand it to talks and coding
dojos once we have some regular numbers.

For more details: http://meetup.com/ed-lambda/
And we're on Twitter: http://twitter.com/ed_lambda

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Lisp/Scheme Style Guide

> It would be a tragedy if The State ordered Picasso to make his paintings more realistic

I think your confusing the virtue in shuffling parentheses around.  If
you want to place your parentheses on their own line then more power
to you, it's your style -- but don't confuse it with making high
art.

The beauty is in the painting, not in the fact that you choose to hang
it upside-down.
:f

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: picking out a tag from a nested struct-map and xml-seq

Re: reflection warnings with defprotocol/deftype with type hints

Hi Albert,

I made sense of this by keeping the concept of defprotocol separate
from definterface and deftype. defprotocol is like multimethods and
deftype is like creating an implementation of an interface. You then
need to instantiate a new instance of the deftype to execute its
methods. The following repl session shows this;

./repl.sh
Clojure 1.2.0-master-SNAPSHOT
user=> (set! *warn-on-reflection* true)
true
user=> (defprotocol PTest (test-it [msg]))
PTest
user=> (extend-protocol PTest nil (test-it[msg] "Nix"))
nil
user=> (extend-protocol PTest String (test-it[msg] msg))
nil
user=> (definterface ITest (test_it ^boolean [^String msg]))
user.ITest
user=> (deftype Test [] ITest (test-it [this msg] (> (.length msg) 0)))
user.Test
user=> (test-it nil)
"Nix"
user=> (test-it "two")
"two"
user=> (let [tt (Test.)] (.test-it tt "hello"))
true

Note where you do and don't need type hints (there are no reflection
warnings). Also note that I used test_it in the definterface.

There are probably ways of creating types on protocols, but I haven't
tried that yet.

-Hth, Adrian

On Tue, Aug 31, 2010 at 11:20 PM, Albert Cardona <sapristi <at> gmail.com> wrote:
> Hi all,
>
> I am puzzled by the type hint support in deftype.
> I can add type hints to defprotocol:
>
> user=> (defprotocol PTest
>  (test-it ^boolean [this ^String msg]))
> PTest
>
> … but adding them to deftype fails:
>
>
> user=> (deftype Test [^String name]
>  PTest
>  (test-it [this msg] (str "test " name ": " msg \space (.length msg))))
> java.lang.IllegalArgumentException: Can't find matching method:
> test_it, leave off hints for auto match. (NO_SOURCE_FILE:1)
>
>
> So I write the deftype without type hints:
>
> user=> (deftype Test [^String name]
>  PTest
>  (test-it [this msg] (str "test " name ": " msg \space (.length msg))))
> user.Test
>
>
> But then, I get reflection warnings:
>
> user=> (set! *warn-on-reflection* true)
> true
>
> user=> (test-it (Test. "one") "two")
> "test one: two 3"
>
> 8/31/10 11:11:49 PM     [0x0-0x29029].org.fiji[382]     Reflection warning,
> NO_SOURCE_PATH:3 - reference to field length can't be resolved.
>
> In any case "length" is a method, not a field, in String.
>
> The above is just a minimal example. I am experiencing this issue in
> just about all deftype that I need to type-hint.
>
> The error when type-hinting suggests that the latter is unnecessary,
> that it could be deduced from the hints in the protocol
> definition--but that is not the case.
>
> What am I missing? Thanks for any help.
>
> Albert
>
> --
> http://albert.rierol.net
>

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Minor macroexpand issue

On 1 Sep 2010, at 00:17, Frederic Koehler wrote:

> If you were to say, (macroexpand '(foo)), it returns (foo), even if  
> it's
> not defined in the context, so I'd say it's a little unexpected.

True, but then, the function macroexpand is mostly a development tool,  
for which I can accept such minor issues. Macroexpansion itself is  
part of the evaluation procedure of forms, so it makes no sense to  
define what macroexpansion should return for a form that is not legal  
code anyway. Neither (Object) nor (foo) are legal code.

> More annoying is the result this has on macroexpand-all, which breaks
> because of this weird behaviour:
>
> (use 'clojure.walk)
> (walk/macroexpand-all '(let [Object (fn [])] (Object)))
>
> java.lang.RuntimeException: java.lang.Exception: Expecting var, but
> Object is mapped to class java.lang.Object (NO_SOURCE_FILE:0)

Right, but then this should be blamed on macroexpand-all, which  
implements a crude approximation to how macroexpansion is done by the  
compiler.

There's also clojure.contrib.macro-utils/mexpand-all, which does a  
much better job, but still fails for this particular example. In fact,  
neither one tracks the lexical environment.

Konrad.

--

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en