On Mar 20, 2009, at 14:35, Joshua Fox wrote:
> I thought of let as a sort of variable declaration, and so, one
> would want to keep it simple and not do complex calculations in the
> let binding expressions.
>
> On the other hand, the sequential mutually-dependent let bindings
> are of co
>
> I like the sequential let too. For one thing, it allows for the breaking
> apart of complex expressions into more comprehensible parts, with well named
> intermediate variables resulting in self documenting code.
About the 7-part *let* as shown in your example: Could we get some opinions
ab
I like the sequential let too. For one thing, it allows for the
breaking apart of complex expressions into more comprehensible parts,
with well named intermediate variables resulting in self documenting
code. For another, if a calculated value is used more than once, then
using an intermediate v
Tim -
If you're running Windows or Linux/Unix (anything other than Mac OS
X), then I think the ctrl-x key binding for the shortcut will be
overridden by the text field's ctrl-x key binding, which is to the
'cut to clipboard' action. Try selecting some text and pressing ctrl-
x to see.
Keyboard
>
> A more fundamental question than how best to do it is - who needs
> this? Does someone have a real need for parallel let?
>
> Rich
>
>
is "parallel let" just a conventional description? What I mean is that it
seems like I could provide an argument c) to that list, namely, that, some
day, the a
On Mar 19, 2009, at 4:42 PM, Joshua Fox wrote:
> Because parallel bindings are also useful
Could you explain? I don't understand the justification for let in
Lisp, when let* seems so much more useful.
As I mentioned, I like how Clojure's "let" works. I'm also fully on
board with Rich's
>
> On Wed, Mar 18, 2009 at 10:40 PM, Stephen C. Gilardi
> wrote:
> > Because parallel bindings are also useful
>
Could you explain? I don't understand the justification for let in Lisp,
when let* seems so much more useful.
Joshua
--~--~-~--~~~---~--~~
You rece
On Mar 19, 8:22 am, Rich Hickey wrote:
> So far it seems like sequential let has proven a useful default, and
> I'd rather have one let than two.
Agreed - sequential let is a better default.
-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because
On Mar 19, 2009, at 7:53 AM, e wrote:
>
>
> Can't you already do this with:
> (let [[a b c] [1 a 3]]
> (prn a b c))
>
>
> if, indeed you can, that seems to violate the very interesting,
> recent discussion Rich initiated that someone recoined as the
> Property Design Pattern. So, on one ha
>
> Can't you already do this with:
> (let [[a b c] [1 a 3]]
> (prn a b c))
>
>
if, indeed you can, that seems to violate the very interesting, recent
discussion Rich initiated that someone recoined as the Property Design
Pattern. So, on one hand, having let process args lazily is consistent with
Great article!> Although I’ve done only a little Ruby metaprogramming, my
sense is that Clojure’s macros make
> it more powerful than Ruby in this respect
It would be good to see a comparison of metaprogramming with macros. They
sometimes are used for similar purposes, but of course are not the sam
On Wed, Mar 18, 2009 at 10:40 PM, Stephen C. Gilardi wrote:
> Because parallel bindings are also useful, I think it's an interesting idea
> to extend let to allow it to take parallel bindings in a map instead of a
> vector. These would act like Common Lisp's "let":
>
> (def a 4)
> (
On Mar 19, 2009, at 12:28 AM, e wrote:
just started reading it and already have some new perspectives.
Like, I didn't really know that "let" variables could depend on each
other. I would have expected that to be let*, but I just looked in
the API, and I don't see a let*, which seems odd
On Mar 19, 2009, at 12:28 AM, e wrote:
just started reading it and already have some new perspectives.
Like, I didn't really know that "let" variables could depend on each
other. I would have expected that to be let*, but I just looked in
the API, and I don't see a let*, which seems odd
i agree with the comment there that your article is a nice, gentle
introduction that makes me go, "cool, now pick another clojure topic. I'm
ready to read it" -- maybe concureny?
On Thu, Mar 19, 2009 at 12:28 AM, e wrote:
> just started reading it and already have some new perspectives. Like,
just started reading it and already have some new perspectives. Like, I
didn't really know that "let" variables could depend on each other. I would
have expected that to be let*, but I just looked in the API, and I don't see
a let*, which seems odd to me. What's that all about?
Secondly, also a
I found one way to make 'global hotkeys' (its a bit verbose though):
http://groups.google.com/group/clojure/web/global-hotkey.clj
adapted from http://www.javaspecialists.eu/archive/Issue007.html
Just mentioning it for interest seeing key controls in swing has been
driving me nuts :P
Regards,
Tim.
I have another question! I've found your article very interesting. I
really like how you have buttons and keybindings to the same
AbstractAction. However when I run your app if I press ctrl-x while in
a textbox nothing happens... If I'm not in a textbox it exits. I
believe this is because the text
Quite right, thanks for the explanation!
On Mar 17, 3:50 pm, Mark Engelberg wrote:
> On Mon, Mar 16, 2009 at 9:44 PM, Timothy Pratley
>
> wrote:
>
> > Hi Keith,
>
> > I don't follow the 'lazy-init' part... It seems to me that you create
> > a delay but force it immediately which is effectively
On Mon, Mar 16, 2009 at 9:44 PM, Timothy Pratley
wrote:
>
> Hi Keith,
>
> I don't follow the 'lazy-init' part... It seems to me that you create
> a delay but force it immediately which is effectively just running
> create-a-text-field. That behavior seems different from the factory
> style return
Hi Keith,
I don't follow the 'lazy-init' part... It seems to me that you create
a delay but force it immediately which is effectively just running
create-a-text-field. That behavior seems different from the factory
style return if exists or create you originally started with. I don't
see the need
21 matches
Mail list logo
