Re: Leiningen 2.0.0-preview1
The clojure community is thankful! On Mar 7, 11:28 pm, Phil Hagelberg wrote: > Hello folks! > > I'm proud to announce the release of Leiningen 2.0.0-preview1. While > this isn't a final stable release, it's fairly stable and should be > usable for the majority of projects. This is a near-rewrite and contains > a few backwards-compatibility breaks, but updating should be pretty > painless in most cases thanks to the lein-precate plugin that can > suggest a new 2.x-compatible project.clj file. > > Highlights for this release: > > * Support profiles for alternate project configurations. > * Replace maven-ant-tasks with Pomegranate library. (Chas Emerick, Nelson > Morris) > * Complete rewrite of repl task. (Colin Jones, Chas Emerick, Anthony Grimes) > * Rewrite new task. (Anthony Grimes) > * New check task for catching reflection and other issues. (David Santiago) > * Allow partial application of aliases. > * Split out leiningen-core into independent library. > > See the full list of user-visible changes: > > https://github.com/technomancy/leiningen/blob/master/NEWS.md > > There's a guide covering the upgrade process: > > https://github.com/technomancy/leiningen/wiki/Upgrading > > If you are a plugin author, see the newly updated plugin guide, > particularly the section on "Upgrading Existing Plugins": > > https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md > > And we're also launchinghttp://leiningen.orgas an introductory page at > this time. > > Please give this preview release a try and let us know how it works for you. > > -Phil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 5:10 PM, Mark Engelberg wrote: > * introducing variables creates new indenting level, making code "creep to > the right" Mitigated by breaking functions into sub-functions (which is good practice anyway). > * as code creeps to the right, you need to have a lot more newlines Then your code is too deeply nested and should be broken into sub-functions. That's standard best practice across all languages. > * The convention of using hyphens to separate words is hard to read I disagree. I find camelCase far harder to read than hyphenated-names. > * loop/recur is significantly less readable I don't think it's "significantly" less readable but I do agree that recur is a bit of a wart. > * cond branches are sometimes written with the test and the answer on the > same line, or when the test gets too long you have to write it with the test > and answer on subsequent lines; this inconsistent formatting can make it > hard to know in long blocks whether you are looking at the test or the > answer Don't write long blocks. Don't write complex conditions. Introduction more sub-functions. > * Interweavings of cond and let (a common pattern) end up ridiculously > indented and hard to read See above (and I don't agree it's a "common" pattern... perhaps an anti-pattern?). > * Decades worth of classic algorithms involving imperative manipulation of > arrays look significantly uglier in Clojure Yet many algorithms are significantly cleaner in a pure functional style... > * Expression-oriented syntax (along with the indenting cost of using let) > encourages people to pack far too much into one line rather than giving > names to intermediate results. Again, poor style. Break things into sub-functions. > * DSLs are supposed to bring customized readable notation to many tasks, but > by the time you include namespace prefixes and colons for all the keywords, > DSLs don't really look that good. Then those DSLs are not achieving their design goals. DSLs are a good use case for :use or :require/:refer. > * ... But when I read someone else's compact > higher-order stuff, it's usually a nightmare to try to interpret what it is > doing. Really? I find the compaction outweighs the effort involved - as long as the code is modular enough (see comments above). > * And the number 1 problem with all Lisps is that when you look at Lisp > code, it's a sea of sameness. Function applications, Macros, Control > constructs, bindings, data lookups, etc. all look exactly the same. I actually find that to be a plus - there's no distracting variance that artificially makes things "different" that don't need to be. Syntax is very subjective. It's really good to here your pro-Python thoughts tho'... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 10:43 PM, Andy Fingerhut wrote: > You might have a difficult time getting other Clojure coders to adopt the > practice in their code, but would this be almost as good? > > (let [x 2] > code) > > Achieving that would be as simple as hand-indenting it that way, or > adjusting the auto-indenter of your favorite text editor to do it that way. > A couple of minutes of perusing clojure-mode.el for emacs didn't make it > obvious to me how to do that, but I suspect it wouldn't be difficult. > > Andy > > It's an interesting question as to how much of my psychological objection to let is the added nesting versus the physical indenting. I agree it would be a worthwhile experiment to adjust the auto-indenter for a while and see how it feels. In the meantime, I *strongly urge* everyone to check out Grand's flatter cond macro: https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj It lets you insert lets in the middle of cond expressions (like you can currently do with for) like: (cond (pos? x) 2 :let [y (* x x)] (> y 20) 4)) This totally transformed my coding style and improved the readability of my code substantially. Highly recommended. Since it is backwards compatible, I very much wish it were part of the core, and see no reason that it couldn't be. --Mark -- 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
Re: Can Clojure be as readable as Python or Ruby ?
You might have a difficult time getting other Clojure coders to adopt the practice in their code, but would this be almost as good? (let [x 2] code) Achieving that would be as simple as hand-indenting it that way, or adjusting the auto-indenter of your favorite text editor to do it that way. A couple of minutes of perusing clojure-mode.el for emacs didn't make it obvious to me how to do that, but I suspect it wouldn't be difficult. Andy On Mar 7, 2012, at 10:22 PM, Mark Engelberg wrote: > Going back to the original poster's question, I think if I could make only > one change to Clojure's syntax to improve readability, I'd take a page from > other functional languages like F# and Racket and add a way to bind local > variables that doesn't indent. So, for example, > > (let x 2) > code > > would behave like the current: > (let [x 2] >code) > > -- > 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 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
Re: Can Clojure be as readable as Python or Ruby ?
Going back to the original poster's question, I think if I could make only one change to Clojure's syntax to improve readability, I'd take a page from other functional languages like F# and Racket and add a way to bind local variables that doesn't indent. So, for example, (let x 2) code would behave like the current: (let [x 2] code) -- 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
Re: How I can use InteractionEvent in clojure?
You are trying to call method GetTransform on an instance of vtk.vtkTransform, and this method does not exist (you are probably wanting to call that method on boxWidget, not t). On Thu, Mar 8, 2012 at 12:32 AM, Antonio Recio wrote: > You are right. I have capitalized InteractionEvent and now callback it is > called and it prints "invoke". > > The application runs but the boxWidget still doesn't work, and I obtain an > error message: > Exception in thread "main" java.lang.IllegalArgumentException: No matching > field found: GetTransform for class vtk.vtkTransform > at clojure.lang.Reflector.getInstanceField(Reflector.java:285) > at > clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:314) > at example$myCallback.invoke(cone.clj:15) > at clojure.lang.AFn.run(AFn.java:24) > at vtk.vtkRenderWindowInteractor.Start_5(Native Method) > at > vtk.vtkRenderWindowInteractor.Start(vtkRenderWindowInteractor.java:32) > at example$main.invoke(cone.clj:54) > at example$eval21.invoke(cone.clj:58) > at clojure.lang.Compiler.eval(Compiler.java:6488) > at clojure.lang.Compiler.load(Compiler.java:6929) > at clojure.lang.Compiler.loadFile(Compiler.java:6889) > at clojure.main$load_script.invoke(main.clj:283) > at clojure.main$script_opt.invoke(main.clj:343) > at clojure.main$main.doInvoke(main.clj:427) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.lang.Var.invoke(Var.java:415) > at clojure.lang.AFn.applyToHelper(AFn.java:161) > at clojure.lang.Var.applyTo(Var.java:532) > at clojure.main.main(main.java:37) > > -- > 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 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
Re: clojure-py 0.1.0 Clojure on Python
Congrat's on the release! I am getting the following error on my
Macbook (running 64-bit Lion, Python 2.7.1) when trying to run "sudo
easy_install clojure-py":
Searching for clojure-py
Reading http://pypi.python.org/simple/clojure-py/
Reading https://github.com/halgari/clojure-py
Best match: clojure-py 0.1.0
Downloading
http://pypi.python.org/packages/source/c/clojure_py/clojure_py-0.1.0.tar.gz#md5=794da1e8031e2d4f3fbc6484ed51c172
Processing clojure_py-0.1.0.tar.gz
Running clojure_py-0.1.0/setup.py -q bdist_egg --dist-dir /tmp/
easy_install-feUpDQ/clojure_py-0.1.0/egg-dist-tmp-78bqof
Traceback (most recent call last):
File "/usr/bin/easy_install-2.7", line 10, in
load_entry_point('setuptools==0.6c12dev-r85381',
'console_scripts', 'easy_install')()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 1712, in
main
with_ei_usage(lambda:
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 1700, in
with_ei_usage
return f()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 1716, in
distclass=DistributionWithoutHelpCommands, **kw
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 211, in
run
self.easy_install(spec, not self.no_deps)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 446, in
easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 476, in
install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 655, in
install_eggs
return self.build_and_install(setup_script, setup_base)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 930, in
build_and_install
self.run_setup(setup_script, setup_base, args)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/command/easy_install.py", line 919, in
run_setup
run_setup(setup_script, args)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/sandbox.py", line 62, in run_setup
lambda: execfile(
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/sandbox.py", line 105, in run
return func()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/
Extras/lib/python/setuptools/sandbox.py", line 64, in
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 10, in
File "/tmp/easy_install-feUpDQ/clojure_py-0.1.0/clojure/
__init__.py", line 2, in
File "/tmp/easy_install-feUpDQ/clojure_py-0.1.0/clojure/main.py",
line 104, in
File "/tmp/easy_install-feUpDQ/clojure_py-0.1.0/clojure/main.py",
line 48, in import_hook
ImportError: module clojure.core not found, looked in ['.', '/tmp/
easy_install-feUpDQ/clojure_py-0.1.0', '/usr/bin', '/Library/Python/
2.7/site-packages/mercurial-2.0-py2.7-macosx-10.7-intel.egg', '/
Library/Python/2.7/site-packages/hg_git-0.3.2-py2.7.egg', '/Library/
Python/2.7/site-packages/dulwich-0.8.3-py2.7-macosx-10.7-intel.egg', '/
Library/Python/2.7/site-packages/Pygments-1.4-py2.7.egg', '/System/
Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/
System/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/plat-darwin', '/System/Library/Frameworks/
Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/
Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-
mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/
Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/
Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/
Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/
System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/
2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages', '/
tmp/easy_install-feUpDQ/clojure_py-0.1.0/cloj
Re: How I can use InteractionEvent in clojure?
You are right. I have capitalized InteractionEvent and now callback it is called and it prints "invoke". The application runs but the boxWidget still doesn't work, and I obtain an error message: Exception in thread "main" java.lang.IllegalArgumentException: No matching field found: GetTransform for class vtk.vtkTransform at clojure.lang.Reflector.getInstanceField(Reflector.java:285) at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:314) at example$myCallback.invoke(cone.clj:15) at clojure.lang.AFn.run(AFn.java:24) at vtk.vtkRenderWindowInteractor.Start_5(Native Method) at vtk.vtkRenderWindowInteractor.Start(vtkRenderWindowInteractor.java:32) at example$main.invoke(cone.clj:54) at example$eval21.invoke(cone.clj:58) at clojure.lang.Compiler.eval(Compiler.java:6488) at clojure.lang.Compiler.load(Compiler.java:6929) at clojure.lang.Compiler.loadFile(Compiler.java:6889) at clojure.main$load_script.invoke(main.clj:283) at clojure.main$script_opt.invoke(main.clj:343) at clojure.main$main.doInvoke(main.clj:427) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.lang.Var.invoke(Var.java:415) at clojure.lang.AFn.applyToHelper(AFn.java:161) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) > -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
Armando, Thanks for the message. See below: On Mar 7, 10:48 am, Armando Blancas wrote: > > Apparently, types/records can implement a protocol "in name only." > > That can't in name only since you obviously got an implementation, though > abstract. We agree on a couple points: -- Yes, my code did generate an implementation. Clojure will definitely consider a protocol implemented even if none of its methods are. -- Some consider this a feature: http://bit.ly/xilScm -- Abstract classes appear to be involved as an implementation detail. But I'm wondering what balance of considerations informed these semantics, since the opposite approach would seem to have advantages as well. On one hand, the current semantics have these benefits: (1) As you say, users could find it convenient to be able to implement just a few methods of a big protocol. (2) Clojure tends not to enforce limitations on access to data, so the current approach could be seen as consistent with the rest of the language. (3) The opposite approach -- requiring a type to implement all of its protocols' methods -- would make the type brittle to expansions of the protocols. (4) The current semantics do achieve high-performance polymorphic dispatch on type, which was one of the goals behind protocols. The opposite approach would be to check that a type implements all of a protocol's methods in order for it be in an extends?/satisfies? relationship with that protocol. To avoid brittleness, this check could be restricted to a subset of the protocol's methods that the protocol-designer designates :required (not sure whether this could be implemented on the JVM). The advantages I see in this approach include: (1) It's useful for protocol-writers to know that implementing types can be relied upon to respond to certain methods. This promotes reuse because code written by the protocol-writer can be confident about how to operate on data received from elsewhere whenever satisfies? returns true. This reflects the notion that a protocol is a specification. (2) Enforcing availability of a protocol's methods does not create the same rigidity problems as enforcing a concrete type system. A type can still implement multiple protocols, and anyway the type is just data and access is always available by its fields. Enforced method implementation simply provides some confidence in the protocol abstraction whenever it's claimed by the type. (3) Brittleness could be avoided by restricting the required methods to a subset that the protocol-designer labels :required. I don't know whether this could be performant on the JVM. (4) Conceptually, it just feels to me like it's part of the point of a protocol to enforce/check implementation of its methods. This is where I would most appreciate hearing alternative perspectives. Here's how I see it. Performant, type-dispatching methods could, in principle, look just like multimethods: free-standing methods that are not grouped into named protocols. Allowing methods to be grouped into named protocols therefore suggests that the point is to provide a concise way to check whether a certain collection of methods is applicable to a certain piece of data. This suggests some enforcement/checking of method implementation via something like satisfies? and extends?. I'm interested in hearing other perspectives. -- Are there important use-cases that rely on partially implemented protocols? -- Is there something about the JVM implementation that would prevent satisfies? and extends? from checking whether methods are implemented? -- Could it be that deftype/defrecord's behavior is just a bug? I notice that (doc deftype) provides, "Methods should be supplied for all methods of the desired protocol(s) and interface(s)." All the best, Garth Sheldon-Coulson P.S. I'm attracted to Tassilo's ideas about extenders. His options do match my intuitions about how this function should work if it remains available. -- 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
Clojurescript: named/numbered releases?
It's great to see the steady activity on the clojurescript github page. However I'm not totally comfortable developing against the master branch. As it stands now, if I change development environments, or deploy on a new machine, the master branch may have moved. I could choose an arbitrary commit as my stable reference point, and periodically make a judgement call about upgrading to a new arbitrary commit, but thats not easy for someone not involved in the internals. I gather this is still "pre-1.0" , but it would still be nice to have some incremental version numbers to rationalize things. thanks for listening. -- 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
[ANN] clojure-py 0.1.0 Clojure on Python
The Clojure-Py team is happy to announce the release of Clojure-Py 0.1.0. https://github.com/halgari/clojure-py Clojure-Py is an implementation of Clojure running atop the Python VM. As it currently stands, we have translated over 235 functions from clojure.core. This is not a clojure interpreter in python; the Clojure-Py compiler compiles clojure code directly to python code. Clojure-py functions are python functions. Clojure-py types are python types, Clojure-py name spaces are python modules. Please feel free to browse the examples at https://github.com/halgari/clojure-py/tree/master/examples to get an idea of what Clojure-Py can currently accomplish. Version 0.1.0 should be considered "alpha" and "proof of concept". That being said, if you stick to the afore mentioned 235 functions, and python interop, the implementation is very usable and so far quite stable. The package is released via the Python Package index so you can simply type easy_install clojure-py clojurepy To install and startup the repl. Python 2.6, 2.7 and PyPy are all supported. Please check out this release and send us your feedback via Github. --- Upcoming in version 0.2.0: Support for bindings defprotocol and defmulti defrecord full support for pr-str --- Thank you for all the interest we've received from the Clojure and Python communities. We look forward to seeing this project grow. Timothy Baldridge (halgari) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 3:12 PM, Joachim De Beule wrote: > Please define "readable". > > Thanks! > > "Readable" is a measure of how readily apparent the meaning of a program is from looking at it. If you wanted to measure this objectively, one possible way to do this would be to time how long it takes a group of programmers to read and understand a well-crafted program to perform some complex algorithm. Let's assume that the programmers are all competent in the language being measured. There are other things you might also measure: you could quiz them to determine if they really understand it as well as they think they do, you could ask them to modify the code, you could ask them to self-rate their subjective sense of how easy it was to understand the program. Tim Daly has opined several times that it would be nice if researchers would do something like this for literate programming, for example. It would be useful to know for sure whether programs in literate form are more readable than ordinary "self-documenting" code. We tend to think of readability as a fairly subjective thing, and it is subjective to the extent that for most of us, the only measure that matters is how long we personally feel it takes us to understand code written in a given language, and how much effort we have to expend to gain that understanding. But certainly it is a quantifiable concept, and it is theoretically possible to compare languages, code coloring schemes, documentation styles, pop-up support, and all other aspects of code readability in an objective way. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 7, 6:39 pm, Leon Talbot wrote: > If so, how ? > > Thanks ! Please define "readable". Thanks! -- 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
Re: How to escape a space in a keyword?
On Thu, Mar 8, 2012 at 9:00 AM, Meikel Brandmeyer wrote: > However documenting everywhere that feeding garbage in might result in shit > coming out has this “things in the mirror might be closer than they appear” > taste. WTF? The mirror is not the problem. Nor is the car manufacturer to be > held responsible. If the driver of a car causes an accident, it's her fault. > *She* is responsible. No one else. If the driver is unaware that what they see in the mirror is distorted, the driver will assume it is not. A driver who has been supplied incomplete information about the operation of their vehicle can not reasonably be held fully responsible, which is why we have so many warning labels. Documentation for programming languages should take the same approach. If any input other than what is specified will lead to undefined results, that needs to be documented. Otherwise, someone will feed in invalid input, get what looks like valid output, and assume that the documentation is out of date, incomplete, or something equally inane, and continue to misuse the feature. You can never underestimate the power of ignorance, no matter a person's creed, intelligence, lifestyle, or profession. If invalid input will not throw an error immediately, then it DOES need to be documented that invalid input will result in undefined output. ~Justin -- 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
clojure on android over CLI
Hi. I'm trying to run:
java -cp clojure-${VERSION}.jar clojure.main
on an Android phone from bash (using the 'terminal-ide' app) but I
can't make it past the error bellow. I did the jar-to-dex conversion
using:
dx --verbose --dex --output=clojure-${VERSION}.dex.jar
clojure-${VERSION}.jar
for clojure-1.3.0.jar, clojure-1.3.0-slim.jar and even for the clojure
clone for Android Neko Toolkit from Daniel Solano Gómez:
https://github.com/sattvik/clojure.git
Does anyone know what I missed? Thx in advance
Bost
Now searching: clojure-1.3.0.dex.jar
found
java.lang.ExceptionInInitializerError
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.spartacusrex.spartacuside.external.java.main(java.java:124)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ExceptionInInitializerError
at clojure.main.(main.java:20)
... 4 more
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException:
Could not locate clojure/core__init.class or clojure/core.clj on
classpath:
at clojure.lang.Util.runtimeException(Util.java:165)
at clojure.lang.RT.(RT.java:319)
... 5 more
Caused by: java.io.FileNotFoundException: Could not locate
clojure/core__init.class or clojure/core.clj on classpath:
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:398)
at clojure.lang.RT.doInit(RT.java:434)
at clojure.lang.RT.(RT.java:316)
... 5 more
In case of the clojure clone for Daniel Solano Gómez:
Now searching: clojure-1.4.0-master-SNAPSHOT.dex.jar
found
java.lang.ExceptionInInitializerError
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.spartacusrex.spartacuside.external.java.main(java.java:124)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ExceptionInInitializerError
at clojure.main.(main.java:20)
... 4 more
Caused by: java.lang.ExceptionInInitializerError
at java.lang.Class.classForName(Native Method)
at java.lang.Class.forName(Class.java:234)
at java.lang.Class.forName(Class.java:181)
at clojure.lang.RT.(RT.java:235)
... 5 more
Caused by: java.lang.ExceptionInInitializerError
at android.os.Build$VERSION.(Build.java:75)
... 9 more
Caused by: java.lang.UnsatisfiedLinkError: native_get
at android.os.SystemProperties.native_get(Native Method)
at android.os.SystemProperties.get(SystemProperties.java:59)
at android.os.Build.getString(Build.java:216)
at android.os.Build.(Build.java:27)
... 10 more
--
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
Re: [ANN] Leiningen 2.0.0-preview1
Just found a bug that only manifests when you don't have any profiles
and are running outside a project. It's fixed in git, but if you're
getting an NPE on 2.0.0-preview1 and don't have any profiles defined,
try this as a temporary workaround:
$ mkdir ~/.lein; echo "{:user {:plugins []}}" >> ~/.lein/profiles.clj
-Phil
--
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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 3:16 PM, Alex Baranosky < alexander.barano...@gmail.com> wrote: > I think that the real question that is: if you know Python and Clojure > equally well, then which is easier to read? > > Alex > > > I know both equally well (actually, I've logged more hours in my life coding in Lisp syntax than other syntaxes), and I still consider Python to be significantly easier to read. A few specific things that hinder Clojure's readability in my opinion: * prefix notation for arithmetic operators defies centuries of mathematical notation conventions and consequently any mathematical formula will be less readable. * introducing variables creates new indenting level, making code "creep to the right" * as code creeps to the right, you need to have a lot more newlines (for example, between each input to a function) to get it to fit on the page. This lengthens the code block making less fit on a page, and also makes the code look a lot different than the exact same code would look if it were appearing in a place that were less indented. * The convention of using hyphens to separate words is hard to read (since - looks like the minus operator) and also takes up more width than camel case, contributing to the problem that you quickly find lines getting too wide and needing to be broken up. * loop/recur is significantly less readable than either the corresponding looping constructs in Python or the named let that Scheme offers, *especially* when you have some sort of nested looping going on, which is extraordinarily difficult to read in Clojure. * cond branches are sometimes written with the test and the answer on the same line, or when the test gets too long you have to write it with the test and answer on subsequent lines; this inconsistent formatting can make it hard to know in long blocks whether you are looking at the test or the answer * Interweavings of cond and let (a common pattern) end up ridiculously indented and hard to read [Grand's flatter cond macro helps with this; I'd love to see this brought into Clojure core] * Decades worth of classic algorithms involving imperative manipulation of arrays look significantly uglier in Clojure, because Clojure intentionally makes imperative manipulation more difficult. I have, for fun, converted many Knuth algorithms to Clojure, and they invariably are far less scrutable than the original. * Expression-oriented syntax (along with the indenting cost of using let) encourages people to pack far too much into one line rather than giving names to intermediate results. * DSLs are supposed to bring customized readable notation to many tasks, but by the time you include namespace prefixes and colons for all the keywords, DSLs don't really look that good. I mean, compare Frinj to Frink. Frinj's integration into Clojure is cool, but is there anyone who considers it even half as readable as Frink? I certainly don't. * I feel really clever when I condense some complex loop into some sort of map/filter/reduce using anonymous functions. And it looks brilliant when I read my own code that does this. But when I read someone else's compact higher-order stuff, it's usually a nightmare to try to interpret what it is doing. Python's loops may be verbose, but I always know exactly what I'm looking at when I read someone else's code. * And the number 1 problem with all Lisps is that when you look at Lisp code, it's a sea of sameness. Function applications, Macros, Control constructs, bindings, data lookups, etc. all look exactly the same. You look at Python code, and you instantly see the control flow of the code, the assignments, the tests, the results, the loops, the data, the data lookups, the breaks. It's organized, but visually distinct. I write code in Clojure because I find the semantics appealing, and I feel I can get more done in less time than a language like Python. "Code as data" might be nice for writing macros, but the reality is that it forces programmers to code in an abstract syntax tree which is more computer friendly than human friendly. If I were given the option to *read* a sample program illustrating some concept in any language of my choice, I would choose Python over Clojure in a heartbeat. All one man's opinion, of course, but I wanted to bring it up because I am someone who has logged many years working in Clojure and related Lisp languages and I still have the opinion that Python is the most readable language I have encountered. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Mar 7, 9:39 am, Leon Talbot wrote: > If so, how ? > > Thanks ! [Closed as: Not a real question] -- 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
Re: How to escape a space in a keyword?
Frank Siebenlist writes: > My suggestion still stands: add more text to the doc-string of some of > the functions such that the user has a better understanding of what to > expect: no validation, nil, exception, expected parameter type, ???. > I'd be happy to suggest wording. Agreed. This is only one instance of a number of cases that the user must hunt around on clojure.org for things that should be available in docstrings, which is unreasonable for a number of reasons. > Another option that may help us to use valid identifiers in our code > is to have a function like: (clojure.core/valid-name? a-str), which is > maintained by core (and not by us all writing some regex based on the > current specs on a web page). If you're just interested in what's round-trippable, that could be done with this: (apply = ((juxt read-string symbol) "symbol-name")) But something more formal wouldn't hurt either. -Phil -- 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
Re: How to escape a space in a keyword?
Clojure is a young language, and I believe there is little argument that some of the interfaces/implementations and associated docs could be improved. You can find plenty of examples where functions would throw exceptions for invalid input, others return nil in that case, and a number return garbage for garbage. Some of this perceived inconsistency could be improved upon, either by changing/adding validation code or by adding clarifications to the documentation of the functions. The symbol function doc consists of only: "Returns a Symbol with the given namespace and name." Unless you suggest that we all look at the symbol code itself before we start using those parameters, it may help to add a little bit more text to guide the novice user of the interface such that one knows that this particular function doesn't throw exceptions or return nil, but returns invalid output for invalid input… for that suggestion I'm rewarded with a condescending "…WTF…" gender-neutral (?) rant - guess you're truly encouraging people on this list to ask questions and suggest solutions/improvements ;-). My suggestion still stands: add more text to the doc-string of some of the functions such that the user has a better understanding of what to expect: no validation, nil, exception, expected parameter type, ???. I'd be happy to suggest wording. Another option that may help us to use valid identifiers in our code is to have a function like: (clojure.core/valid-name? a-str), which is maintained by core (and not by us all writing some regex based on the current specs on a web page). We can use it in our code and tests to ensure we're following the current specs. If the valid characters are extended in the next clojure version, so is the function, and we can automatically conform. I'd be happy to provide code. "Sincerely", FrankS. On Mar 7, 2012, at 2:00 PM, Meikel Brandmeyer wrote: > Hi, > > Am 07.03.2012 um 01:11 schrieb Leif: > >> Unfortunately, the reader does not actually follow this spec, e.g. it will >> happily accept :div#id.cla$$ as a valid keyword. Some web programming >> clojure[script] libraries use this pseudo-CSS syntax in keywords, so if the >> reader was changed to strictly follow these rules, a lot of web code would >> probably break. > > It's the other way around: the reader *does* follow the spec. Feed it a valid > sequence of characters and you will get a valid keyword. Feed it an invalid > sequence of characters and you will get an invalid keyword. This is not in > conflict with the spec. A bad decision to do so instead of bailing out? > Maybe. Maybe not. > > However documenting everywhere that feeding garbage in might result in shit > coming out has this “things in the mirror might be closer than they appear” > taste. WTF? The mirror is not the problem. Nor is the car manufacturer to be > held responsible. If the driver of a car causes an accident, it's her fault. > *She* is responsible. No one else. > > The developers of said libraries obviously didn't live up to their > responsibility. Either they did not research how the reader works and what > valid keyword characters are. Then they did not do their job correctly. Or > they knew how the reader works but knowingly decided to operate it outside > defined limits. Then they basically gambled that things keep working and that > the characters will be eventually allowed in future versions of the reader. > > In this particular case I would expect the bet to pay off. But if suddenly > the reader is changed to handle # differently, then all these libraries will > break. And now guess who is responsible. The reader? No. > > Don't pass the buck. > > Sincerely > Meikel > > PS: I hope Clojure's development mode is not switched to “fait accompli > driven.” > > -- > 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 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
Re: How I can use InteractionEvent in clojure?
On Mon, Mar 5, 2012 at 5:50 PM, Antonio Recio wrote: > (.AddObserver "interactionEvent" myCallback "run") I suspect this is mis-capitalized, it need to be "InteractionEvent". --Aaron -- 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
Re: How I can use InteractionEvent in clojure?
It seems that callback is not called. I have added (println "Testing callback") in the definition of myCallback and there is not message in the prompt when I run the application. (def myCallback (fn [] (let [t (vtk.vtkTransform.)] (.GetTransform t) (-> boxWidget .GetProp3D (.SetUserTransform t)) (println "Testing callback" -- 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
Re: Clojure 1.3 treatment of integers and longs
On Sunday, October 23, 2011 5:21:52 PM UTC-4, Rich Hickey wrote:
>
> Hi all,
>
> This reply is to the thread, not Luc specifically.
>
> Thanks everyone for your feedback and input.
>
> I have pushed 3 commits:
>
> 1) Fixes the inconsistency between the hash function used by Clojure maps
> (was .hashCode) and =. Thanks Paul for the report.
>
> 2) Changes core/hash to return the result of this hashing function. Thus,
> it returns a different value than does .hashCode for Integers, Shorts,
> Bytes and Clojure collections. Feedback welcome.
>
> 3) Only due to the first fix, it now becomes possible to box ints to
> Integers without much grief. This commit implements that for evaluation
> purposes, and is not a commitment to that policy. Note well that while in
> the first commit the answer is clear, on this point there is always going
> to be a tradeoff and there is no 'right' answer.
>
> Here are the issues as I see them:
>
> First, note there is no 'following' of Java semantics as an objective.
> Java semantics are that Integers are never equal to Longs, and I presume no
> one wants to go back to that.
>
> Second, boxing is a change of type, period. There is no valid complaint
> that 'you changed my type'. int != Integer either.
>
> Third, there are 2 scenarios in consuming things you box in Clojure from
> Java:
>
> a) You control the Java. In this case, having Clojure make everything
> uniform (Longs) make things easier for you. There is no heterogeneousness
> regardless of the source or manipulation of numbers, and can always expect
> Longs.
>
> b) You don't control the Java. In this case you must match consuming
> expectations i.e. conforming to Java promotion, types of generics etc.
> ***This will *always* require vigilance and explicitness due to arithmetic
> conversions etc***. Auto promotion is only one part. Note that this is true
> in Java as well - while type checker may scold you, you still have to
> cast/coerce on mismatch.
>
> Even with the auto box change, you are only an arithmetic operation away
> from having the problem again. For instance in the original report,
> wrapping .getValue with dec generates an interop mismatch again:
>
> (let [amap {1 (dec (.getValue obj))}] …)
>
> There is no way we are going to 'fix' that by adopting Java's numeric
> tower, which is dangerous and requires static types. The bottom line is
> specific type requirements on the Java side require explicit boxing on
> order to have correct and non-brittle code.
>
> The final consideration is collection equality. When Clojure autoboxes to
> Longs, you get homogeneous collection contents, and thus .equals is still
> true for the collection on the Java side, vs random - 'depends on where I
> got the contents from and what I did with them'.
>
> FYI - there are the RT/box functions that box as per Java. These could be
> exposed in Clojure.
>
> -
> In short, having autoboxing match Java does not really free you from your
> responsibility to create specific boxed types when you need them on the
> Java side. I.e., Clojure can't help you.
>
> On the flip side, when you are in charge of the Java code, Clojure's being
> more consistent makes things more consistent on the other side and *does*
> give you less to do to make sure things work.
>
> I prefer what we had (auto box to Longs), but I think it matters a
> somewhat less now with = consistent hashing. If we decide to revert to that
> we can discuss making auto boxing of short and byte consistent.
> -
>
Rich,
In Clojure 1.4.0-beta3 ints are boxed as Integers.
Clojure 1.4.0-beta3
user=> (map type [(byte 1) (short 1) (int 1) (long 1)])
(java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long)
Based on the above and my conversation with you at the Conj you seemed to
be pretty convinced that ints should be boxed as Longs. You made a
temporary commit to box them as Integers
(https://github.com/clojure/clojure/commit/a2e4d1b4eaa6dad26a1a96b9e9af129a9d10),
then Stu Halloway reverted it
(https://github.com/clojure/clojure/commit/abfa803838a1884d0c5112bc6b876cf33a8a05cc),
then he reverted the revert
(https://github.com/clojure/clojure/commit/798a98bc1b844b0fe08e9309886823cf7ca92604).
Are we still in the temporary period for evaluation purposes? Have you
changed your mind? If so, I'd be interested to hear why. Should we expect
this behavior from beta3 to change any time soon?
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
Re: How I can use InteractionEvent in clojure?
I meant do: (def myCallback (fn [] (println "Invoked!") (let [t (vtk.vtkTransform.)] (.GetTransform t) (-> boxWidget .GetProp3D (.SetUserTransform t) -- 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
Re: How I can use InteractionEvent in clojure?
When I print myCallback I obtain this: (println myCallback) user => # I have used this: (doto coneMapper (.SetInput (.GetOutput cone))) And the applications runs, with not errors in the prompt too, but the boxWidget still doesn't work. On Wednesday, March 7, 2012 9:19:38 PM UTC+1, Aaron Cohen wrote: > > Unfortunately, I've been unable to get vtk to compile locally. > > At this point, it's seeming to me that your issue is more vtk-related > than clojure, though. Can you put a println in the callback to confirm > that it's at least being called? > > One question, is it significant that your code is slightly different > from the example here? > > (doto coneMapper > (.SetInputConnection (.GetOutputPort cone))) > > Although I'm not sure if it's significant, from reading the example > code, it would be: > > (doto coneMapper >(.SetInput (.GetOutput cone))) > > -- 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
Re: Can Clojure be as readable as Python or Ruby ?
If we're going to talk about readability at all, then we need to first define what attributes make up that which is readable. What commonly passes for readability is simply a variant of Easy, namely readable means "near to" your current body of knowledge. Is German less readable than English? I think that the real question that is: if you know Python and Clojure equally well, then which is easier to read? Alex -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Hi, I have recently started working in python, I don't find python very readable at all compared to clojure. It is more about familiarity than anything else. On Thursday, March 8, 2012 4:39:08 AM UTC+11, Leon Talbot wrote: > > If so, how ? > > Thanks ! -- 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
Re: Google Summer of Code 2012 Application
March 9th! David On Wed, Mar 7, 2012 at 5:26 PM, Chris Granger wrote: > When's the official cutoff? > > Cheers, > Chris. > > > On Wed, Mar 7, 2012 at 2:24 PM, David Nolen wrote: > >> Looks like Dan Friedman, William Byrd and the IU Googlers they know might >> be getting behind our application as vouchers. >> >> There's no better time to submit proposals or step up to be a mentor than >> now :) >> >> David >> >> >> On Wed, Mar 7, 2012 at 1:47 PM, David Nolen wrote: >> >>> I've made some progress here: >>> >>> >>> http://dev.clojure.org/display/community/Google+Summer+of+Code+2012+Application+Questions >>> >>> For those with edit right please edit as you see fit and as soon as you >>> can, we're running out of time, thanks! :) >>> >>> David >>> >>> On Wed, Mar 7, 2012 at 1:37 PM, Alexander Yakushev < >>> yakushev.a...@gmail.com> wrote: >>> Great job answering the application questions, David! I was just wondering if Steve Yegge could vouch for Clojure since I remember him being very excited about the language, so maybe he might say a nice word for Clojure participation... -- 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 Dev" group. >> To post to this group, send email to clojure-...@googlegroups.com. >> To unsubscribe from this group, send email to >> clojure-dev+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/clojure-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Clojure Dev" group. > To post to this group, send email to clojure-...@googlegroups.com. > To unsubscribe from this group, send email to > clojure-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/clojure-dev?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@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
[ANN] Leiningen 2.0.0-preview1
Hello folks! I'm proud to announce the release of Leiningen 2.0.0-preview1. While this isn't a final stable release, it's fairly stable and should be usable for the majority of projects. This is a near-rewrite and contains a few backwards-compatibility breaks, but updating should be pretty painless in most cases thanks to the lein-precate plugin that can suggest a new 2.x-compatible project.clj file. Highlights for this release: * Support profiles for alternate project configurations. * Replace maven-ant-tasks with Pomegranate library. (Chas Emerick, Nelson Morris) * Complete rewrite of repl task. (Colin Jones, Chas Emerick, Anthony Grimes) * Rewrite new task. (Anthony Grimes) * New check task for catching reflection and other issues. (David Santiago) * Allow partial application of aliases. * Split out leiningen-core into independent library. See the full list of user-visible changes: https://github.com/technomancy/leiningen/blob/master/NEWS.md There's a guide covering the upgrade process: https://github.com/technomancy/leiningen/wiki/Upgrading If you are a plugin author, see the newly updated plugin guide, particularly the section on "Upgrading Existing Plugins": https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md And we're also launching http://leiningen.org as an introductory page at this time. Please give this preview release a try and let us know how it works for you. -Phil -- 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
Re: Google Summer of Code 2012 Application
When's the official cutoff? Cheers, Chris. On Wed, Mar 7, 2012 at 2:24 PM, David Nolen wrote: > Looks like Dan Friedman, William Byrd and the IU Googlers they know might > be getting behind our application as vouchers. > > There's no better time to submit proposals or step up to be a mentor than > now :) > > David > > > On Wed, Mar 7, 2012 at 1:47 PM, David Nolen wrote: > >> I've made some progress here: >> >> >> http://dev.clojure.org/display/community/Google+Summer+of+Code+2012+Application+Questions >> >> For those with edit right please edit as you see fit and as soon as you >> can, we're running out of time, thanks! :) >> >> David >> >> On Wed, Mar 7, 2012 at 1:37 PM, Alexander Yakushev < >> yakushev.a...@gmail.com> wrote: >> >>> Great job answering the application questions, David! I was just >>> wondering if Steve Yegge could vouch for Clojure since I remember him being >>> very excited about the language, so maybe he might say a nice word for >>> Clojure participation... >>> >>> -- >>> 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 Dev" group. > To post to this group, send email to clojure-...@googlegroups.com. > To unsubscribe from this group, send email to > clojure-dev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/clojure-dev?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@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
Re: Google Summer of Code 2012 Application
Looks like Dan Friedman, William Byrd and the IU Googlers they know might be getting behind our application as vouchers. There's no better time to submit proposals or step up to be a mentor than now :) David On Wed, Mar 7, 2012 at 1:47 PM, David Nolen wrote: > I've made some progress here: > > > http://dev.clojure.org/display/community/Google+Summer+of+Code+2012+Application+Questions > > For those with edit right please edit as you see fit and as soon as you > can, we're running out of time, thanks! :) > > David > > On Wed, Mar 7, 2012 at 1:37 PM, Alexander Yakushev < > yakushev.a...@gmail.com> wrote: > >> Great job answering the application questions, David! I was just >> wondering if Steve Yegge could vouch for Clojure since I remember him being >> very excited about the language, so maybe he might say a nice word for >> Clojure participation... >> >> -- >> 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 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
Re: How to escape a space in a keyword?
Hi, Am 07.03.2012 um 01:11 schrieb Leif: > Unfortunately, the reader does not actually follow this spec, e.g. it will > happily accept :div#id.cla$$ as a valid keyword. Some web programming > clojure[script] libraries use this pseudo-CSS syntax in keywords, so if the > reader was changed to strictly follow these rules, a lot of web code would > probably break. It's the other way around: the reader *does* follow the spec. Feed it a valid sequence of characters and you will get a valid keyword. Feed it an invalid sequence of characters and you will get an invalid keyword. This is not in conflict with the spec. A bad decision to do so instead of bailing out? Maybe. Maybe not. However documenting everywhere that feeding garbage in might result in shit coming out has this “things in the mirror might be closer than they appear” taste. WTF? The mirror is not the problem. Nor is the car manufacturer to be held responsible. If the driver of a car causes an accident, it's her fault. *She* is responsible. No one else. The developers of said libraries obviously didn't live up to their responsibility. Either they did not research how the reader works and what valid keyword characters are. Then they did not do their job correctly. Or they knew how the reader works but knowingly decided to operate it outside defined limits. Then they basically gambled that things keep working and that the characters will be eventually allowed in future versions of the reader. In this particular case I would expect the bet to pay off. But if suddenly the reader is changed to handle # differently, then all these libraries will break. And now guess who is responsible. The reader? No. Don't pass the buck. Sincerely Meikel PS: I hope Clojure's development mode is not switched to “fait accompli driven.” -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I think readable is in the eye of the beholder. I've only moderate experience with Clojure, but the following example from Open Dylan made me realize I really do prefer a concise representation over what is considered easier to read. http://opendylan.org/documentation/intro-dylan/why-dylan.html#functional-languages define method shoe-size (person :: ) if (person = "Larry") 14 else 11 end if end method; Versus http://opendylan.org/documentation/intro-dylan/why-dylan.html#algebraic-infix-syntax (define (shoe-size person) (if (equal? person "Joe") 14 11)) Albeit my preference could be different over a different example. Silly humans 8) The thing is, if you just keep using Clojure or another Lisp for a little while, you'll probably get used to it and find it comfortable. -- 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
Re: Can Clojure be as readable as Python or Ruby ?
On Wed, Mar 7, 2012 at 12:39 PM, Leon Talbot wrote: > If so, how ? > > Thanks ! > Isn't it already? -- 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
Re: Can Clojure be as readable as Python or Ruby ?
>> If so, how ? >> I think Python may be easier for you, but it's not simpler than Clojure. Simplicity is the strength of Clojure. http://www.infoq.com/presentations/Simple-Made-Easy I can learn a new syntax almost overnight (last night I started writing Dart code for the first time after googling the syntax for 15 min), but the power of macros, immutable data, and laziness are what really makes Clojure stand out. Timothy -- “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) -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Maybe this proposal: http://grokbase.com/t/gg/clojure/11ctt573jq/list-syntax-sugar-f-x-notation On Wed, Mar 7, 2012 at 6:09 PM, Angel Java Lopez wrote: > An old thread: > > http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38?pli=1 > > > Also, someone proposed instead of > (f a b c) > begin to use > f(a, b, c) or something alike > > but I don't have the thread link now > > On Wed, Mar 7, 2012 at 2:39 PM, Leon Talbot wrote: > >> If so, how ? >> >> Thanks ! >> >> -- >> 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 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
Re: Can Clojure be as readable as Python or Ruby ?
An old thread: http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38?pli=1 Also, someone proposed instead of (f a b c) begin to use f(a, b, c) or something alike but I don't have the thread link now On Wed, Mar 7, 2012 at 2:39 PM, Leon Talbot wrote: > If so, how ? > > Thanks ! > > -- > 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 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
Can Clojure be as readable as Python or Ruby ?
If so, how ? Thanks ! -- 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
Re: How to escape a space in a keyword?
Unfortunately, the reader does not actually follow this spec, e.g. it will happily accept :div#id.cla$$ as a valid keyword. Some web programming clojure[script] libraries use this pseudo-CSS syntax in keywords, so if the reader was changed to strictly follow these rules, a lot of web code would probably break. On Tuesday, March 6, 2012 12:13:20 PM UTC-8, stuart@gmail.com wrote: > > I don't think you're supposed to use spaces in keywords. > > > > Using spaces in keywords is completely valid, as is using spaces in > symbols. > > > Legal characters in keywords and symbols are documented at > http://clojure.org/reader : > > "Symbols begin with a non-numeric character and can contain alphanumeric > characters and *, +, !, -, _, and ? ... Keywords are like symbols ..." > > Stu > > > > On Tuesday, March 6, 2012 12:13:20 PM UTC-8, stuart@gmail.com wrote: > > I don't think you're supposed to use spaces in keywords. > > > > Using spaces in keywords is completely valid, as is using spaces in > symbols. > > > Legal characters in keywords and symbols are documented at > http://clojure.org/reader : > > "Symbols begin with a non-numeric character and can contain alphanumeric > characters and *, +, !, -, _, and ? ... Keywords are like symbols ..." > > Stu > > > > -- 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
labrepl in eclipse 3.6
I am a novice at both java and clojure. I installed the counterclockwise eclipse plugin and the labrepl as per http://dev.clojure.org/display/doc/Getting+Started+with+Eclipse+and+Counterclockwise . After install one of the steps is to Enable Clojure Support - Right-click the "labrepl" project in Package Explorer and choose "Enable/disable Clojure language support" When I do this I get "Error while tryiing to toggle clojure language support for project labrepl:" Any suggestion as to what this means and how I can proceed to get the lab working ? Thx -- 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
Re: What Java classes/objects/methods do you find yourself most often using?
On 06/03/12 17:09, John Gabriele wrote: While writing Clojure code, what Java classes, objects, and static methods do you most often find yourself using? I use java.lang.Math quite a lot... Jim -- 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
Re: How I can use InteractionEvent in clojure?
Unfortunately, I've been unable to get vtk to compile locally. At this point, it's seeming to me that your issue is more vtk-related than clojure, though. Can you put a println in the callback to confirm that it's at least being called? One question, is it significant that your code is slightly different from the example here? (doto coneMapper (.SetInputConnection (.GetOutputPort cone))) Although I'm not sure if it's significant, from reading the example code, it would be: (doto coneMapper (.SetInput (.GetOutput cone))) -- 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
Re: Google Summer of Code 2012 Application
Looks amazing David, I'm very interested to apply as a student if we get in as an Organization. Best, Federico On Wed, Mar 7, 2012 at 4:47 PM, David Nolen wrote: > I've made some progress here: > > > http://dev.clojure.org/display/community/Google+Summer+of+Code+2012+Application+Questions > > For those with edit right please edit as you see fit and as soon as you > can, we're running out of time, thanks! :) > > David > > On Wed, Mar 7, 2012 at 1:37 PM, Alexander Yakushev < > yakushev.a...@gmail.com> wrote: > >> Great job answering the application questions, David! I was just >> wondering if Steve Yegge could vouch for Clojure since I remember him being >> very excited about the language, so maybe he might say a nice word for >> Clojure participation... >> >> -- >> 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 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 -- Federico Brubacher @fbru02 -- 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
Google Summer of Code 2012 Proposal & Backup Mentors
http://dev.clojure.org/display/community/Google+Summer+of+Code+2012 A reminder that we're still looking for proposals from community members and interested students. We're also looking for backup mentors - if you'd be willing to step up this summer should something happen to a mentor please say so! Thanks, David -- 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
Google Summer of Code 2012 Application
I've made some progress here: http://dev.clojure.org/display/community/Google+Summer+of+Code+2012+Application+Questions For those with edit right please edit as you see fit and as soon as you can, we're running out of time, thanks! :) David On Wed, Mar 7, 2012 at 1:37 PM, Alexander Yakushev wrote: > Great job answering the application questions, David! I was just wondering > if Steve Yegge could vouch for Clojure since I remember him being very > excited about the language, so maybe he might say a nice word for Clojure > participation... > > -- > 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 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
Re: Google Summer of Code 2012 - any mentors?
Great job answering the application questions, David! I was just wondering if Steve Yegge could vouch for Clojure since I remember him being very excited about the language, so maybe he might say a nice word for Clojure participation... -- 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
Re: How to use goog.dom.query
Have you tried giving the full path in the :libs option? On Tuesday, January 24, 2012 12:35:00 PM UTC-5, Jonas wrote: > > Hi all > > I was wondering if it's possible to use goog.dom.query[1] from > ClojureScript or ClojureScript One? It's a third party module but it's > bundled with the Closure version which is downloaded by scripts/bootstrap. > I've tried (:require [goog.dom.query :as query]) but that doesn't work out > of the box for me. Looking at the source code[2] I can see it referenced > several times which makes me hopeful that I should get it working. It seems > that maybe I should add > > :libs ["closure/library/third_party/closure"] > > or something similar to my build options but still no luck. > > [1]: > http://closure-library.googlecode.com/svn/docs/closure_third_party_closure_goog_dojo_dom_query.js.html > [2]: > https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/closure.clj#L555 > -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
> > user=> (boom (Record.)) > AbstractMethodError user.Record.boom()Ljava/lang/Object; user/eval55 > (NO_SOURCE_FILE:3) > > Apparently, types/records can implement a protocol "in name only." > That can't in name only since you obviously got an implementation, though abstract. > What is behind this choice? That's convenient when an implementation only cares about a few methods in a big protocol. -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
Alan Malloy writes: Hi Alan, >> IMHO, `extenders' should return also types implementing the protocol >> interface directly [i.e., deftypes and defrecords], so that >> >> (extends? P T) <=> (some #(= % T) (extenders P)) >> >> holds. > > You're entitled to that humble opinion, but it's not really possible > with any kind of reasonable performance. When you implement the > protocol interface directly, no machinery in clojure.core gets > involved at all - you just define a class that implements an > interface. For `extenders` to be able to list Java classes that > implement the interface directly, it would have to walk through every > class loaded in the JVM and check its implemented-interfaces. > > Of course, you could make it almost-work, by having deftype/defrecord > emit some special code for hooking into extenders whenever you define > a class in Clojure, That's what I had in mind. deftype/defprotocol could just alter the :impls of the protocol, just like `extend' does. > but then it would only work for classes defined within Clojure, and > not for Java classes that implement Clojure's interfaces/protocols. Well, yes. > Frankly I think that's worse than just limiting it to "dynamic" > extenders. I'd prefer if it was limited to "extenders that extend within clojure", because that seems to be the more common case. My use case for `extenders' was my API docs generator, where I'd like to add to every protocol description the types that extend that protocol. So basically, I see 3 options: 1) rename `extenders' to `dynamic-extenders' (or something like that) to get rid of the extends?/extenders inconsistency 2) remove `extenders' completely (can anyone think of any use case for it in its current incarnation that is important enough that it justifies a core function instead of using (keys (:impls protocol)) directly?) 3) make deftype/defrecord alter the :impls just like `extend' does and document the limitation concerning implementing protocol interfaces in java explicitly in the `extenders' docstring I'm happy to provide a patch for either option. Bye, Tassilo -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
On Mar 7, 1:09 am, Tassilo Horn wrote: > David Powell writes: > > Hi David, > > > When you create a protocol, as an implementation detail, it also > > creates a Java interface. > > Is a protocal neccessarily an implementation detail? I mean, it might > be, but it can also be a public specification of the requirements types > have to satisfy in order to integrate with my lib. You misread his assertion. The implementation detail is that an interface is defined along with each protocol. > > When you list protocols in a deftype or defrecord form, the generated > > class actually implements that Java interface. And protocol calls to > > that type call through the interface. This gives the best performance. > > > If you add protocols to an existing class, record or type; this > > dispatch is done dynamically and interfaces aren't involved. > > That suggests that `extenders' is actually a private function for doing > the dynamic dispatch. But it's not used at all in clojure.core. And > it's inconsistent with extends?. I don't really see how it suggests that, but okay. It does appear that you're right that extenders and extends? are not consistent between each other. > user> (defrecord R2 [] Bashable (boom [this] :boom)) > user.R2 > user> (extenders Bashable) ;; just returns the "dynamic" extenders > (user.Record) > user> (extends? Bashable R2) ;; does an implements? check as well > true > > IMHO, `extenders' should return also types implementing the protocol > interface directly, so that > > (extends? P T) <=> (some #(= % T) (extenders P)) > > holds. You're entitled to that humble opinion, but it's not really possible with any kind of reasonable performance. When you implement the protocol interface directly, no machinery in clojure.core gets involved at all - you just define a class that implements an interface. For `extenders` to be able to list Java classes that implement the interface directly, it would have to walk through every class loaded in the JVM and check its implemented-interfaces. Of course, you could make it almost-work, by having deftype/defrecord emit some special code for hooking into extenders whenever you define a class in Clojure, but then it would only work for classes defined within Clojure, and not for Java classes that implement Clojure's interfaces/protocols. Frankly I think that's worse than just limiting it to "dynamic" extenders. -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
David Powell writes: Hi David, > When you create a protocol, as an implementation detail, it also > creates a Java interface. Is a protocal neccessarily an implementation detail? I mean, it might be, but it can also be a public specification of the requirements types have to satisfy in order to integrate with my lib. > When you list protocols in a deftype or defrecord form, the generated > class actually implements that Java interface. And protocol calls to > that type call through the interface. This gives the best performance. > > If you add protocols to an existing class, record or type; this > dispatch is done dynamically and interfaces aren't involved. That suggests that `extenders' is actually a private function for doing the dynamic dispatch. But it's not used at all in clojure.core. And it's inconsistent with extends?. user> (defrecord R2 [] Bashable (boom [this] :boom)) user.R2 user> (extenders Bashable);; just returns the "dynamic" extenders (user.Record) user> (extends? Bashable R2) ;; does an implements? check as well true IMHO, `extenders' should return also types implementing the protocol interface directly, so that (extends? P T) <=> (some #(= % T) (extenders P)) holds. Bye, Tassilo -- 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
When you create a protocol, as an implementation detail, it also creates a Java interface. When you list protocols in a deftype or defrecord form, the generated class actually implements that Java interface. And protocol calls to that type call through the interface. This gives the best performance. If you add protocols to an existing class, record or type; this dispatch is done dynamically and interfaces aren't involved. -- Dave On Mar 7, 2012 8:09 AM, "Tassilo Horn" wrote: > Garth Sheldon-Coulson writes: > > Hi Garth, > > > I'm returning to Clojure in earnest for the first time since 1.1 (and > > very happy to be back!). Apologies if this question revisits old > > issues. > > I've revisited mostly the same 2 days ago: < > 87399ocg9a@thinkpad.tsdh.de> > > > I'm trying to understand why the semantics of protocols are such that > > the third statement here returns true: > > > > user=> (defprotocol Bashable (bash [this]) (boom [this])) > > Bashable > > > > user=> (defrecord Record [] Bashable (bash [this] "bash!")) > > user.Record > > > > user=> (and (satisfies? Bashable (Record.)) (extends? Bashable > > Record)) > > true > > > > This returns true even though boom is not implemented for Record: > > > > user=> (boom (Record.)) > > AbstractMethodError user.Record.boom()Ljava/lang/Object; user/eval55 > > (NO_SOURCE_FILE:3) > > > > Apparently, types/records can implement a protocol "in name only." > > What do you mean with "in name only"? > > > What is behind this choice? Intuitively, I would have conceived of a > > protocol as a collection of methods all of which must be implemented > > in order for a type/record to extend the protocol. > > I think it would be nice if extends?/satisfies? would return the set of > implemented methods, say, as keywords. Then you could check if an > object implements exactly the methods that your function wants to call. > > > A second question. How does one "explicitly" extend a protocol per the > > documentation of the extenders function? Intuitively, I would have > > thought that the code above "explicitly" extends Bashable if it > > extends Bashable at all. Yet: > > > > user=> (extenders Bashable) > > nil > > That was my initial question in my posting two days ago. extenders > returns only types that extend a protocol using the `extend' function > (or `extend-type', `extend-protocol' macros). So this works: > > user> (defprotocol Bashable (bash [this]) (boom [this])) > Bashable > user> (defrecord Record []) > user.Record > user> (extend-protocol Bashable > Record (bash [_] "Bash!")) > nil > user> (extenders Bashable) > (user.Record) > > IMO, that behavior is not very obvious. > > OTOH, Stu said that extenders is specific to the extend form (as > suggested by its name), and in fact, neither defrecord's nor deftype's > documentation speak of extending a protocol, but their terminology is to > supply method implementations for protocol methods. > > But then, what's the use case of `extenders' anyway? I mean, I want to > know what types participate in a protocol. I don't care if they do > because they were explicitly extended to the protocol or because the > method implementations were provided directly in their definition form. > That's an implementation detail I shouldn't have to bother with... > > Bye, > Tassilo > > -- > 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 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
Re: Why don't extends? and satisfies? require implementation of all protocol methods?
Garth Sheldon-Coulson writes: Hi Garth, > I'm returning to Clojure in earnest for the first time since 1.1 (and > very happy to be back!). Apologies if this question revisits old > issues. I've revisited mostly the same 2 days ago: <87399ocg9a@thinkpad.tsdh.de> > I'm trying to understand why the semantics of protocols are such that > the third statement here returns true: > > user=> (defprotocol Bashable (bash [this]) (boom [this])) > Bashable > > user=> (defrecord Record [] Bashable (bash [this] "bash!")) > user.Record > > user=> (and (satisfies? Bashable (Record.)) (extends? Bashable > Record)) > true > > This returns true even though boom is not implemented for Record: > > user=> (boom (Record.)) > AbstractMethodError user.Record.boom()Ljava/lang/Object; user/eval55 > (NO_SOURCE_FILE:3) > > Apparently, types/records can implement a protocol "in name only." What do you mean with "in name only"? > What is behind this choice? Intuitively, I would have conceived of a > protocol as a collection of methods all of which must be implemented > in order for a type/record to extend the protocol. I think it would be nice if extends?/satisfies? would return the set of implemented methods, say, as keywords. Then you could check if an object implements exactly the methods that your function wants to call. > A second question. How does one "explicitly" extend a protocol per the > documentation of the extenders function? Intuitively, I would have > thought that the code above "explicitly" extends Bashable if it > extends Bashable at all. Yet: > > user=> (extenders Bashable) > nil That was my initial question in my posting two days ago. extenders returns only types that extend a protocol using the `extend' function (or `extend-type', `extend-protocol' macros). So this works: user> (defprotocol Bashable (bash [this]) (boom [this])) Bashable user> (defrecord Record []) user.Record user> (extend-protocol Bashable Record (bash [_] "Bash!")) nil user> (extenders Bashable) (user.Record) IMO, that behavior is not very obvious. OTOH, Stu said that extenders is specific to the extend form (as suggested by its name), and in fact, neither defrecord's nor deftype's documentation speak of extending a protocol, but their terminology is to supply method implementations for protocol methods. But then, what's the use case of `extenders' anyway? I mean, I want to know what types participate in a protocol. I don't care if they do because they were explicitly extended to the protocol or because the method implementations were provided directly in their definition form. That's an implementation detail I shouldn't have to bother with... Bye, Tassilo -- 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
