Re: Empty defstruct
as I said, structs are an optimization on maps, that optimization doesn't work for empty structs, so empty structs of course don't make sense For me structs are more than just optimizations. They add documentary information to the map, which is a great feature for readability. Optimization is nice too, but I use them only because of their self-documentary style in combination with struct-map. Anyway, thanks for the hint to deftype. That sounds even better than defstruct. -- 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
Types in deftype vs. gen-class
Hi, I read that deftype is often a better replacement for gen-class and defstruct. Indeed, it would fit for my purposes very well, except the following problem: deftype does not (yet?) use all the information from type hints. Simple example: (:gen-class :methods [[getText [] String]] ... compiles to: public java.lang.String getText(); But: (deftype ... [#^java.lang.String text]) compiles to: public final java.lang.Object text; Although the documentation states that fields [...] can have type hints, this seems to work only for primitive types at the moment. For Java interop (using deftype-defined classes from Java code) however, it may be crucial to have the right types. Will this feature be added, and if not, what is the best alternative solution? Thank you! Andi -- 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: Empty defstruct
Just another option to consider:
{:type :person, :name Bill, :age 20}
Why then use defstruct at all? I think defstruct is useful, but it
would be even
more useful if I had nothing to fear if it runs empty sometime
because of
little design changes. It might be only experimental and later I may
choose
other obligatory keys, but breaking the consistency of defstruct at
this
point is in my opinion a singularity that is just unnecessary.
--
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: Empty defstruct
I think your use of workaround is pejorative. And can it even be called a work around if it is a best practice even when there is nothing to work around? I just can't understand why throwing an exception should be more useful than returning some object you can actually work with. I wouldn't throw an exception for empty vectors or list either. Why artificially introducing this constraint where it is not necessary at all? Please help me to understand why I am wrong. Why are empty structs in C, empty classes in Java, empty hashmaps in Clojure, why are all of these objects allowed (of course, because it makes sense), but empty defstructs are forbidden by a if-empty-then-exception where it is not necessary or helpful at all? -- 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
Empty defstruct
Hi, I would like to know why defstruct without providing any keys (like (defstruct s)) is not allowed (exception: Must supply keys). Let me shortly describe why I think that this would be useful: Imagine you have a defstruct like in Rich's Ants demo: (defstruct cell :food :pher) ;may also have :ant and :home :ant and :home are optional, since they are not often used (Rich actually states in his talk, that this is an advantage compared to Java where we would always have to store null for each of the optional class members). Image, you use (struct-map cell ...) very often in your program. Now, you notice that :food and :pher are also not used very often, and that most times only one or two of the four possible keys are actually used. So you make them all optional: (defstruct cell) ;may have :food, :pher, :ant and :home This is not allowed. You have to remove the whole defstruct, which makes all your (struct-map cell ...) calls useless. This is bad, because you have to replace it everywhere and struct-map has a very nice documentary style you want to use anyway. (Later, when we notice that at least one key is obligatory, we again have to find these places and convert them back to struct-map...) In practice, I had this problem with a struct containing 10 possible keys, where mostly only 1-2 are used in practice. Now I have to remove the whole defstruct... or let at least one arbitrary key be non- optional, which is more a hack than a nice solution. Looking in the PersistentStructMap.java, I found out that allowing structs with no obligatory key would be no problem at all (change 2 lines?). I don't know why it was written that way, but I think here Clojure puts a spoke in me wheel where it just not needed. Any comments? Thanks! Andi -- 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: Empty defstruct
On 20 Jan., 00:56, Kevin Downey redc...@gmail.com wrote: clojure structs are an optimized version of maps for a set of shared keys. if you don't have a defined set of shared keys you just have a map. so by all means, use a map You're talking about the implementation in the background, but I am talking about nice code. I'm aware that defstruct with optional keys introduce a slight overhead compared to normal hashmaps, but that is minimal and defstruct/struct-map is much cleaner and more documentary that a pure hashmap. I can not find a reason why Clojure forbids to make use of this nice feature. -- 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: Empty defstruct
I think Andreas's point is that there's a discontinuity: 0 required keys: map 1 required key: struct-map 2 required keys: struct-map ... That's exactly the point! If I change only a little detail in my program, this can have impact on a huge part of my program. I can not see any reason why it is forbidden to use empty defstructs. The solution for Andreas, of course: either * Always use map. The performance impact is small. And documentary style is lost. Would be ok though, but not optimal. * Always have at least one required key in your struct-map, even if you don't actually use it. That's definitely not a solution but a problem itself. -- 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: Empty defstruct
I fail to see how it requires changing a lot of code. it just means you need to change the place where you create your maps. which if you are also type tagging them is a lot of repetitive code, so it should already be factored out into a function, so then you just switch out one function. That's probably true, but you just argue why this inconsistency in Java is not overly severe. But this is no argument for not fixing this inconsistency. Remember, it would only need to change 2 or 3 lines in PersistentStructMap, which is less than the lines I have to fix in my clojure code for only one single instance of this problem. -- 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: Empty defstruct
And documentary style is lost. Would be ok though, but not optimal.
On the contrary, I think
{:name Bill :age 23 :friends 20}
is better than
(struct-map person Bill 23 20)
Please review the definition of struct-map...
Actually we seem to have the same opinion! Even better readable is
(struct-map person :name Bill)
A person which name is Bill... ideal! {:name Bill :age 23 :friends
20} is not so good because you can not see at a glance that it is a
person. (struct person Bill 23 20) is also not so good because you
could confuse age and friends (even more horrible, when you change the
definition of your person later...)
--
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: Empty defstruct
how is that not an argument? I'm pretty sure I just used it as one. What I wanted to say is that you are completely right, if you say that it is easy to create a workaround. But although doing this is easy, this does not mean that we should not fix this inconsistency (or do you see none?) anyway. -- 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: newbie clojure/eclipse question
Im running counterclockwise too, without this problem. I'm sure the people at the counterclockwise users group can help you, since this here is a more general Clojure discussion group. http://groups.google.com/group/clojuredev-users -- 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
Ants: Good Java solution?
Hi, for seminar talk at my university I have to prepare a demo program showing Clojure's concurrency features. I stumbled upon the ants demo presented in Rich Hickey's Clojure Concurrency talk ( http://blip.tv/file/812787 ) which I like very much. I began to port the program to Java to demonstrate how difficult it is to do the same job in Java. Rich already said that is very hard to do that. For example, he states that you need to lock the whole world (all cells and ants) if you want to create a report with a consistent view of the program's state in a certain point of time. What does that mean in Java? Do we need a global lock for that? But then, I have to use the same global lock on all writing operations, too? This results in destroying all concurrency. So my question is: Has anybody tried to port the ants demo to Java? Any experiences? Thanks, Andi -- 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
Automatic parallelization (again)
In January, there was a discussion about automatic parallelization ( http://groups.google.com/group/clojure/browse_thread/thread/a053fac1235d3820/ - Google doesn't allow me to continue this thread, so I have to open a new one). I'm interested if anybody has made some progress in this topic? The idea I'm interested in (maybe for project at university) is if it could be possible to speed up a program by computing the parameter values of a function call concurrently. For example, if we have (f param1 param2 param3) then we could compute param1, param2 and param3 each in an own agent. Of course, there are restrictions: - the computations must be free of side effects (any Java code and (de) references disqualify, I guess) - in most cases, it will slowdown the execution, but the runtime could keep track on which positions it was sucessfull and only apply parallelization there in the future) No matter if this really makes sense, my first question is how side effects are actually defined in Clojure. This is also important for the dosync macro, where no side effects should be used. But what does that mean exactly? And shouldn't there be a way for the compiler to figure out, if there are side effects or not? Of course, Clojure has a problem there because of the tight integration to Java (which is, as I think, one of its greatest features). You can never know what your called Java code does. But perhaps it is at least possible to distinguish between guaranteed side-effect functions (if we ignore the binding macro which can destroy this, as far as I understand) and possible side-effect containing functions? When using dosync the compiler could optionally show a warning for the latter ones, but - as mentioned before - also try auto-parallelization for the former ones. Any ideas, papers, experiments I should know about? --~--~-~--~~~---~--~~ 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: Automatic parallelization (again)
In the last paragraph, I mean: But perhaps it is at least possible to distinguish between guaranteed side-effect FREE functions (if we ignore the binding macro which can destroy this, as far as I understand) and possible side-effect containing functions? --~--~-~--~~~---~--~~ 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: college courses
At the Technische Universität München (Germany), I know of two courses where Clojure was at least mentioned. This year there was an advanced Java seminar with one talk about Clojure ( http://www2.in.tum.de/hp/Main?nid=59 ). Next year there is a programming models and code generation seminar with a talk about the concurrency features of Clojure ( http://www.lrr.in.tum.de/public/HauptseminarCodegenerierungWS09 - not mentioned yet). But I know of no lecture that uses Clojure as its main language (yet). In the second semester, our students are teached OCaml or a self- constructed functional-like Java when they learn functional programming. --~--~-~--~~~---~--~~ 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: Bug: -main function corrupts applet
*push* Can please anybody verify this bug? Should take only 3 minutes or so. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug: -main function corrupts applet
When writing an applet with Clojure I discovered the following bug: Whenever a class with a -main function is loaded (e.g. by :use), the applet is broken (Java 6 with new plugin technology): java.lang.NullPointerException at sun.plugin2.applet.Plugin2Manager.findAppletJDKLevel (Plugin2Manager.java:2996) at sun.plugin2.applet.Plugin2Manager.createApplet (Plugin2Manager.java:2947) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run (Plugin2Manager.java:1397) at java.lang.Thread.run(Thread.java:619) You can very easily reproduce the problem with the following experiment I prepared: http://www.xenoage.com/extern/bugreports/clojure-main-problem.zip First, look at the .clj files. There are three identical (minimal) applets. Each uses another (minimal) file: One uses a class with a - main method, one uses a class with no main method and the third one uses a renamed main method. Now, compile the files by calling the build.sh script. When finished, open the HTML files in the browser. You will see that the two applets without -main functions work, but the applet with the -main function fails. I guess, this is a bug in Clojure? --~--~-~--~~~---~--~~ 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 Applets: Tutorial
Fantastic news: - Clojure applets do not have to be signed, when reflection can be avoided (by type hints and so on) - Java code is indeed not needed (thanks @ rob) I've updated the tutorial accordingly. Here is another Clojure applet which works without Java code and without signing: http://chouser.n01se.net/misc/tree.html --~--~-~--~~~---~--~~ 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 Applets: Tutorial
However, compatibility with Java 5 is lost again. Java 5 plugin shows the following error message when loading the applet (even when Clojure compiler was started with Java 5, but I guess, this does not matter anyway): Java Plug-in 1.5.0_19 Verwendung der JRE-Version 1.5.0_19 Java HotSpot(TM) Client VM Home-Verzeichnis des Benutzers = /home/andi [...] java.lang.VerifyError: class applet overrides final method “Ÿʐh ‘ .ó¬ʐh ‘ (- yeah, really.) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java: 124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:172) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:144) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:687) at sun.applet.AppletPanel.createApplet(AppletPanel.java:723) at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1813) at sun.applet.AppletPanel.runLoader(AppletPanel.java:652) at sun.applet.AppletPanel.run(AppletPanel.java:326) at java.lang.Thread.run(Thread.java:595) /usr/share/themes/Human/gtk-2.0/gtkrc:51: error: lexical error or unexpected token, expected valid token Any idea? --~--~-~--~~~---~--~~ 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 Applets: Tutorial
Hi Jon, Applet net.n01se.Tree ist just an example I found on the web. My new demo code can be found here: http://www.xenoage.com/extern/clojurebook/applet2/cljapp.html But as already said, Java 5 doesn't like it (see error message two posts above) and tells me that the bytecode generated by the Clojure compiler was wrong... Hm... --~--~-~--~~~---~--~~ 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 Applets: Tutorial
You might want to try clojure-slim.jar, which gets built alongside clojure.jar, and is about 500KB. Good idea, thanks. I'll add it. Another idea: Since the applet itself needs not to be signed, it would be great if there is an official precompiled clojure.jar which is certified from a certificate authority. Then (as far as I know) the user is not confronted with a daunting warning dialog. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
