On Tue, Aug 9, 2016 at 02:29 <clojure@googlegroups.com> wrote: > clojure@googlegroups.com > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/clojure/topics> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/clojure/topics> > > - Using a function to def other functions? > <#m_5766536650690988793_group_thread_0> - 8 Updates > - How to do functional programming > <#m_5766536650690988793_group_thread_1> - 2 Updates > - [JOB] Software Engineer at Xledger in Colorado Springs, CO > <#m_5766536650690988793_group_thread_2> - 1 Update > - Keep application running when main thread only starts go blocks > <#m_5766536650690988793_group_thread_3> - 3 Updates > - ANN: diehard 0.3.0 <#m_5766536650690988793_group_thread_4> - 2 > Updates > - ANN: system 0.3.1 <#m_5766536650690988793_group_thread_5> - 1 Update > > Using a function to def other functions? > <http://groups.google.com/group/clojure/t/34ca35c319f1efb6?utm_source=digest&utm_medium=email> > fah...@gmail.com: Aug 08 11:52AM -0700 > > user> (macroexpand-1 '(defn foo [x] (inc x))) > (def foo (clojure.core/fn ([x] (inc x)))) > > If defn is just a macro, then it seems I can do this: > > user> (defn bar [] (fn ([x] (inc x)))) > #'user/bar > > user> (def foo (bar)) > #'user/foo > > user> foo > #function[user/bar/fn--10778] > > But the result is a little different than doing it directly with defn: > > user> (defn foo [x] (inc x)) > #'user/foo > > We had #'user/*bar/fn--10778* vs #'user/foo. But either way, foo is bound > to something. > > Is the difference significant? It seems like it is because I tried > something similar in my project and got the following: > > IllegalStateException Attempting to call unbound fn: #'p.core/default-step > clojure.lang.Var$Unbound.throwArity (Var.java:43) > p.core> default-step > #function[p.core/make-step/fn--10747] > > Function default-step was def'd using make-step which returned a function > and default-step is bound, so why does the repl say it is not? > > (defn make-step [some-args] > (fn ([other-args] > (some-body using-both-args)))) > > Basically I need to define a bunch of similar functions and am trying to > use another function to help define them (instead of using a macro). But > it > seems I'm doing something wrong... > adrian.med...@mail.yu.edu: Aug 08 01:14PM -0700 > > Using defining macros as non top-level forms may not be forbidden by the > language but its use is generally discouraged. > See http://clhs.lisp.se/Issues/iss104_w.htm for a discussion about this > issue in Common Lisp for some background context. In short, compile time > effects may not be captured whenever you use defining macros as non > top-level forms. I think you're seeing something like this manifest here. > In this case, since you referenced a var which was not installed when the > compiler reaches the calling code, the compiler will throw this error > message. I would suggest rethinking this because the solution is ugly, but > you should use something like clojure.core/resolve or > clojure.core/ns-resolve to resolve the var dynamically and then funcall > it. > > fah...@gmail.com: Aug 08 02:19PM -0700 > > Oh... 'bar' and 'make-step' count as macros? My intent was that they're > ordinary functions that return functions. Am I mistaken? Or does the issue > you referred to apply to using defining *functions and macros *as > non-top-level forms? > > (defn bar [] (fn ([x] (inc x)))) > > (defn make-step [some-args] > (fn ([other-args] > (some-body using-both-args)))) > adrian.med...@mail.yu.edu: Aug 08 02:30PM -0700 > > defn, def, etc are what I mean by "defining macros". > > adrian.med...@mail.yu.edu: Aug 08 02:31PM -0700 > > def isn't a good example actually because it's a special form. But the > same > principle applies when using it as a non-top level form. > > Gregg Reynolds <d...@mobileink.com>: Aug 08 04:32PM -0500 > > > > user> (defn foo [x] (inc x)) > > #'user/foo > > > We had #'user/bar/fn--10778 vs #'user/foo. But either way, foo is bound > to something. > > > Is the difference significant? It seems like it is because I tried > something similar in my project and got the following: > > > IllegalStateException Attempting to call unbound fn: > #'p.core/default-step clojure.lang.Var$Unbound.throwArity (Var.java:43) > > p.core> default-step > > #function[p.core/make-step/fn--10747] > > > Function default-step was def'd using make-step which returned a function > and default-step is bound, so why does the repl say it is not? > > (fn ([other-args] > > (some-body using-both-args)))) > > > Basically I need to define a bunch of similar functions and am trying to > use another function to help define them (instead of using a macro). But it > seems I'm doing something wrong... > > Use the source, Luke! > > Spend some quality time with the source code of deftype, defrecord, ns, > etc. and you will not regret it. Monkey with the ns- functions to explore > namespaces, interning, etc. Make sure you grok the relation between vars > and values. Once you get the hang of how Clojure does it you'll find it > easy to roll your own. > > You will almost certainly want to use some macros, but what's wrong with > that? > > gregg > Andrew C <ache...@gmail.com>: Aug 08 04:10PM -0700 > > I don't understand -- How am I using 'def' in a non-top-level-form? > > I thought I was calling 'bar', getting the result which is a function, and > binding that function to a name 'foo', where the binding is 'def' at the > top level. Is that not what I'm doing? > > I'm trying to avoid the use of unnecessary macros. Is this a situation > that > requires macros? > > Eventually this might be in ClojureScript which requires macros to be > handled differently... > fah...@gmail.com: Aug 08 04:16PM -0700 > > Ah, are you saying the binding isn't taking place at the top level because > I had to call 'bar' to get the right hand side (so to speak) of the > binding? > > And if 'bar' were a macro instead, then it would be expanded first and > then > nothing would have to be evaluated before binding to 'foo', and so it > would > be at the top level? > Back to top <#m_5766536650690988793_digest_top> > How to do functional programming > <http://groups.google.com/group/clojure/t/7209e2bfd635eb07?utm_source=digest&utm_medium=email> > Gary Johnson <lambdatro...@gmail.com>: Aug 08 08:42AM -0700 > > A shell script written in a procedural style (e.g. with Bash or equivalent > shell language) will frequently start out by declaring some global > variables, then perform some conditional checks (if then else), throw in a > few loops (for, while), and ultimately end up with some new values in > those > initially declared variables that you use as your program's output. If you > are feeling particularly intrepid, you might factor out some repetitive > operations into separate subroutines defined higher up in the file and > then > call them as necessary in those aforementioned conditional blocks and > loops. > > The mental model behind this type of programming is the Universal Turing > Machine. Your variables are some internal state that the program > instructions are reading and writing, reading and writing, writing and > reading until you get to the last instruction that returns some subset of > the final variable values. The driving principle is that computation is > accomplished by the free mutation of state. > > A program written in a functional style (e.g. with any Lisp, one of the > MLs, Haskell, Clean, etc) begins with a chunk of data, which may either be > hard-coded, input from the outside world, or generated internally with a > function like "range" or "rand". This piece of data may or may not be > stored in one or more global variables. However (and this is HUGE > however), > these are not generally mutated over the life of the program. That is to > say, they are constants. More often than not, you won't even store the > initial data in a global variable but will just feed it into a function > that processes it and spits out some new data, which is then fed to > another > function that performs some other processing operation and again spits out > some new data. Ultimately, the data that you produce is passed through an > arbitrarily long pipeline of functions until the final result is produced > and returned by the program. In practice, these function calls are rarely > linear and are much more likely to form a branching call tree. But > ultimately, the relevant branches of this tree will be traversed and > executed in a depth first manner (unless lazy evaluation inserts its magic > to reorder some of that computation behind the scenes) and you still get > to > a final output returned by the last function fall evaluated. > > The mental model behind this type of programming is Lambda Calculus. There > is no mutable state anywhere in a pure functional program, and instead the > intermediate results are passed through the call stack from function to > function. In practice, because stack sizes are limited, most values passed > between functions will be boxed references pointing to memory locations on > the heap. However, as far as the functional programmer is concerned, there > is no heap and there is no mutable state. Immutable values simply flow > seamlessly from one function to the next until the program has finished. > The driving principle is that computation is accomplished by transforming > data through mapping a set of immutable inputs to an immutable output. > Think f(x,y) = z. > > In order to accomplish this stateless pipeline of data transformations, > functions much possess a property called "referential transparency". This > means that a function must be able to calculate its outputs > deterministically using only its inputs AND without modifying any of its > inputs in the process. This property is preserved even when global > variables are referenced within the body of a function as long as the > values associated with those global variables are constants throughout the > lifetime of the program. > > In practice, very few languages (outside of Haskell) actually try to be > completely pure and allow no mutation of state whatsoever. Clojure opts to > make all data immutable by default, but provides some special language > features (refs, atoms, agents, volatiles) that you can use if you really > do > want to write an algorithm that involves some mutable state. Unless there > is a performance bottleneck (as in numerical computing) or no other > sensible way to model the domain (as in some web applications), making use > of these features for mutable state is generally frowned upon. When they > are really necessary and valuable, however, Clojure's language tools for > accomplishing mutation are wonderful because they carefully protect it > against concurrency clashes in multi-threated environments. > > To approach writing a functional program, first think about how to model > the computation as a series of data transformations. Then build your > program from the bottom up (prototyping and testing it in the REPL) by > writing small, referentially transparent functions that describe the lower > level operations that you will need. Then build higher level functions on > top of those that build up your abstractions in a layer cake style until > you reach your entry point function that either takes input data from the > outside world or generates it internally and then starts the execution of > the function call tree. > > This is, of course, my attempt at summarizing the mindset that I > frequently > use when trying to write a new functional program, and I welcome additions > or corrections from other folks in this thread to further flesh it out. > Best of luck in your functional programming adventures and with Clojure in > particular. The FP way of thinking can be a bit tricky to wrap your mind > around when coming from a traditional OOP background, but once you grok > it, > there is a great feeling of freedom and simplicity that emerges from what > I > suspect many of my fellow Clojurians would agree is a far more elegant and > powerful programming paradigm. > John Newman <john...@gmail.com>: Aug 08 04:53PM > > So I've been hammocking it up recently on this subject. Just to add more > philosophical perspective - you could look at the universe in two different > ways: from the _inside_, where a thing subjectively experiences the flow of > time, as the world mutates around it; and from the _outside_, where > objectively no time exists, and the history of the universe is a static > network of immutable states, like a unidirectional graph. Animals > understand things from the _inside_ perspective, teleologically, where > things seem dynamic, contextual, and place oriented in time and space. > Physics and philosophy give us the second, ontological understanding. Some > might say the inside perspective is more intuitive while the outside > perspective is more correct or precise. > > FP has an ideally unidirectional flow of causality, whereas OOP has loops, > where state flows backwards in the causal chain. A class instance is like a > state machine (to my mind) and that machine moves through time, updating > it's properties. (Banging on things in place) > > FP allows you to more easily create an objective universe, where you > control all states from the outside and have absolute control over those > states. This also, however, requires more explicit definition of what you > want to occur, because the context of your transformation is not implicit > in the data itself. > > OOP allows you to more easily forget about the complexities of the global, > outside context and operate under the illusion that context is built into > the instance - that the same "thing" is moving across the causal graph, > through time. Unfortunately, as our programs become more complex this > illusion breaks down and our efforts to hide the complexities of the > outside context in looping state machines makes us in fact ignorant of too > much. No, the class is not a duck. No, the method does not actually quack. > It's convenient to pretend like it does, in the small, but the inside, > subjective metaphor becomes a burden in the large. > > So while FP sometimes requires more explicit definition of the desired > transformations from one state to the next, you'll end up with a lot more > hair on your head when working with large systems, if Rich and Stu's heads > are any indication :) > John > > > Back to top <#m_5766536650690988793_digest_top> > [JOB] Software Engineer at Xledger in Colorado Springs, CO > <http://groups.google.com/group/clojure/t/3df16d6a64da64bf?utm_source=digest&utm_medium=email> > Brave Clojure Jobs <j...@braveclojure.com>: Aug 08 07:42AM -0700 > > "Xledger is a finance, project, and business information system that gives > customers tighter control of their businesses. > > We are expanding our team in Colorado Springs, which focuses on > Clojurescript (with Om), F#, and SQL Server. We're looking for engineers > who can make a strong contribution to this stack, helping us create > best-in-class functionality for our customers." > > More at > > https://jobs.braveclojure.com/jobs/17592186046037/software-engineer-jr-sr-clojurescript-f-xledger > Back to top <#m_5766536650690988793_digest_top> > Keep application running when main thread only starts go blocks > <http://groups.google.com/group/clojure/t/8c0473fe2c06b75d?utm_source=digest&utm_medium=email> > "Richard Möhn" <richard.mo...@posteo.de>: Aug 07 08:40PM -0700 > > Am Samstag, 6. August 2016 16:50:35 UTC+9 schrieb Miguel Ping: > > http://stackoverflow.com/a/18779688/22992 > > And then you can await for its shutdown: > > http://stackoverflow.com/a/1250655/22992 > > Thanks for the answer! It's interesting, but a bit hacky, so I would only > use it if there's no alternative. > > Richard > "Richard Möhn" <richard.mo...@posteo.de>: Aug 07 08:48PM -0700 > > Am Samstag, 6. August 2016 21:30:53 UTC+9 schrieb Alex Miller: > > (.countdown signal) > > > You could also use a Lock and Condition (the oo version of wait/notify), > > or a Semaphore, or a CyclicBarrier. > > Ah, thanks! This might make the intention clearer. > > Aside from that, I was more concerned with the resources allocated to the > blocked main thread than to the channel. Although I guess a "main thread > doing nothing for most of the application's lifetime" just sounds wrong, > but actually doesn't matter. > Timothy Baldridge <tbaldri...@gmail.com>: Aug 07 10:21PM -0600 > > So I'm tempted to ask at this point, what does your program do? If you're > doing nothing but CPU work, then yeah you may need to do something in the > main thread. However, all IO work should be done outside of go block. Go > blocks are limited in the number of concurrent threads that they use, so > it's possible to deadlock the pool if you do IO inside the code called by a > go block. So I'd suggest moving what ever IO work you're doing into > dedicated threads and that might just solve your problem. > > > > On Sun, Aug 7, 2016 at 9:48 PM, Richard Möhn <richard.mo...@posteo.de> > wrote: > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > Back to top <#m_5766536650690988793_digest_top> > ANN: diehard 0.3.0 > <http://groups.google.com/group/clojure/t/2c732aaefee2c5ab?utm_source=digest&utm_medium=email> > Ning Sun <classicn...@gmail.com>: Aug 08 10:36AM +0800 > > Diehard 0.3.0 just released! Diehard is a library provides retry and > circuit breaker for your clojure code. Currently it's based on Failsafe. > > What's new in 0.3.0: > > * Updated to Failsafe 0.9.2 > * New option :jitter-factor and :jitter-ms on retry policy for adding > randomness to retry delay > * :fallback value and handler for retry block > * `defretrypolicy` for defining named policy > > Github: https://github.com/sunng87/diehard > Docs: https://sunng87.github.io/diehard > "Richard Möhn" <richard.mo...@posteo.de>: Aug 07 08:37PM -0700 > > Great! I was just going go implement a primitive retry myself, when I > found > this by chance. Thanks for contributing! > Back to top <#m_5766536650690988793_digest_top> > ANN: system 0.3.1 > <http://groups.google.com/group/clojure/t/4dde3e6fc8032f9f?utm_source=digest&utm_medium=email> > Daniel Szmulewicz <daniel.szmulew...@gmail.com>: Aug 07 06:43PM -0700 > > Hello everybody, > > This is to announce that system <https://github.com/danielsz/system> > version > 0.3.1 is out! > > This is a minor update that ships with usability improvements. > > - Boot users will get better error messages when the system task is not > configured properly. > - The system task will produce better console output when it restarts > the system. > - The system task accepts regexes and paths in the files argument. > - The system task can operate as a wrapper for tools.namespace. > > The last bullet point means that the system task can now be used even if > your application doesn’t use Component. > It will then simply track changes in your source code, and reload affected > namespaces automatically. > A demo project can be found here <https://github.com/danielsz/no-restarts > >. > > Also, this version ships with a couple of new readymade components. > > - Carmine/Redis PubSub (pattern channels) > - hara.io.scheduler > > This release was made possible with the contributions of: > > - Daniel Higginbotham > - Martin Klepsch > - Vsevolod Romashov > - Fabrizio Ferrai > - Kenneth Ryall > > > Thank you so much! > > If you don’t know what system is, here is the elevator pitch. > > System is a repository of components for Stuart Sierra’s Component > library. It features readymade components for frequently used > application dependencies like databases, http servers, etc. > > System is also an auto reloading environment compatible with any > editor/IDE. It tries to ensure that your source code is always in-sync > with the application under development. > > System achieves this goal by seamlessly wrapping and leveraging three > fundamental pieces: tools.namespace, Component and Boot. > Back to top <#m_5766536650690988793_digest_top> > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/clojure/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to clojure+unsubscr...@googlegroups.com. >
-- 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.
