Re: Clojure Code Style

2009-08-13 Thread Daniel Lyons


On Aug 12, 2009, at 10:34 PM, Richard Newman wrote:

> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of partials need to be added.


I seem to prefer writing point-free and reading conventional. :)  
Haskell seems to have brainwashed me that point-free style reduces  
bugs. I say brainwashed because I can't remember the reasoning to back  
up the idea, other than to mumble something about less code being  
good. I suspect type checking plays a big role, correspondingly  
minimizing the utility when imported here and compared to the other  
styles.

In this case I would say I prefer Meikel's solutions most of all.  
Still, I wouldn't avoid comp and partial; they have some good  
applications (no pun intended).

—
Daniel Lyons


--~--~-~--~~~---~--~~
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 dosync transaction result computation be parallelized over multiple threads?

2009-08-13 Thread Andy Fingerhut

I know that if you have a dosync call in some function executed by a
thread, and then that function calls other functions (which might have
their own dosyncs, which get bundled together with the original
transaction), then everything is fine.  It seems common that all of
that work would be done sequentially, in a single thread.

But what if that thread that started the dosync did a pmap call, say,
and the function called on each of the elements of the collection
accessed Refs, and perhaps computed new values for some of them, and
those were not the same Refs that the original thread was accessing.
Do all of those get bundled together with the original transaction,
too?

If so, did it require anything special in the implementation to make
that work?

Thanks,
Andy

--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

2009-08-13 Thread Lauri Pesonen

2009/8/12 Chas Emerick :
>
> On Aug 12, 2009, at 3:19 PM, Mark Volkmann wrote:
>
>> I didn't release it was valid to define names with colons in them.
>> Maybe that shouldn't be allowed. I'd like to be able to specify type
>> hints using UML-like syntax like the second example from Chas which
>> was
>>
>> (defh foo [s:String unhinted-arg {a:int :a}] ...)
>
> I *really* like the look of s:String (or String:s, which I used in my
> quickie impl, they're interchangable), but I can easily see colons
> being used for some other syntactic purpose down the road that we're
> not yet aware of (ranges come to mind, eg. [0:50] as in python).  And
> of course, colons and other special characters are very helpful in
> representing domain-specific semantics directly in code, so losing
> those special characters is an expensive choice that should be weighed
> very cautiously.

One possible hack would be to mimic Haskell once again and use a
double colon as the separator between the name and the type, i.e.
s::String. This would still allow for the use of  a single colon (and
more than two colons) in normal names, albeit it might be a bit
confusing if both were used in the same context.

I think that special characters in names make code a lot more
readable, and they are useful in DSLs, so I too would hate to see
characters being removed from the set of legal characters.

Actually, it turns out that the reader does not like more than one
colon in the middle (or end) at the moment. This is probably somehow
related to how the namespace qualified keywords are read:

user> 'foo:bar
foo:bar
user> 'foo::bar
; Evaluation aborted.
user> 'foo:::bar
; Evaluation aborted.
user> 'foo:
; Evaluation aborted.
user> 'foo::
; Evaluation aborted.
user> ':foo
:foo
user> '::foo
:user/foo
user> 'foo
foo

> - Chas

-- 
  ! Lauri

--~--~-~--~~~---~--~~
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: Uncle Bob looking for clojure help!

2009-08-13 Thread David Nolen
http://github.com/swannodette/convex-hull/tree/master
This version runs in 2-2.5s. About exactly an order of magnitude slower than
Java.

Amazingly, I did discover afterwards
that there is a Clojure version that is _exactly_ the same speed as
the Java version:

.
.
.

(.test (new TimeJarvisMarch))

On Wed, Aug 12, 2009 at 9:18 AM, Andrew Wagner wrote:

> http://blog.objectmentor.com/articles/2009/08/11/jarvis-march-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: Pure-functional N-body benchmark implementation

2009-08-13 Thread Nicolas Oury

-XX:+AggressiveOpts improves another 5-10%.

EscapeAnalysis seems more important than BiasedLocking.

I don't have a disassembling module installed. Could someone use the
PrintAssembly option and put the asm for the JITed method somewhere. 

It could be interesting to see it side by side with the java one...

Best,

Nicolas.

On Wed, 2009-08-12 at 17:18 -0400, Aaron Cohen wrote:
> On Wed, Aug 12, 2009 at 4:49 PM, Aaron Cohen wrote:
> > I'm getting a very significant performance improvement by adding a
> > couple of JVM parameters (using jdk 1.6.0_14).  They are:
> > -XX:+DoEscapeAnalysis
> > -XX:+UseBiasedLocking (I think the -server flag is required for those
> > two flags to do anything).
> >
> > My runtime with n = 5,000,000 goes from ~7.5 seconds to ~4.5 seconds.
> >
> > I can't currently check whether the java code gets the same
> > performance boost, but it's possible and even likely that the clojure
> > version would see a better improvement from those parameters than the
> > java one.
> >
> 
> I actually just confirmed that, on my computer at least, those flags
> have basically no effect on the java version and a big difference on
> the clojure one.
> 
> > 


--~--~-~--~~~---~--~~
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 performance tests and clojure a little slower than Java

2009-08-13 Thread Daniel

On Thu, Aug 13, 2009 at 10:40 AM, Glen Stampoultzis wrote:
>> There was a good thread on this list some weeks ago which mentioned
>> another JVM flag:
>> -XX:+PrintOptoAssembly
>>
>> The original thread:
>>
>> http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1
>>
>
> There's some more information about it at [1].  It looks like you need a
> plugin to get it to work.  I'm on Windows and unfortunately for Windows
> there doesn't seem to be a prebuilt binary for this platform.
>
> [1] http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
>

Bugger, and I just read the instructions for building the thing on
windows [2]. Looks to be doable (I'd try cross-compiling on Linux with
VirtualBox [3]), but it's still non-trivial, and it's not sure whether
it'll work on a stock Sun JVM or if you need an OpenJDK build
(backported JDK 6 or work in progress JDK 7). :(

[2] 
http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/share/tools/hsdis/README
[3] http://www.virtualbox.org/

--~--~-~--~~~---~--~~
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 dosync transaction result computation be parallelized over multiple threads?

2009-08-13 Thread Chas Emerick

> I know that if you have a dosync call in some function executed by a
> thread, and then that function calls other functions (which might have
> their own dosyncs, which get bundled together with the original
> transaction), then everything is fine.  It seems common that all of
> that work would be done sequentially, in a single thread.
>
> But what if that thread that started the dosync did a pmap call, say,
> and the function called on each of the elements of the collection
> accessed Refs, and perhaps computed new values for some of them, and
> those were not the same Refs that the original thread was accessing.
> Do all of those get bundled together with the original transaction,
> too?

Andy,

No -- absent some var/binding gymnastics (which are currently possible  
but not very straightforward to do at the moment) -- a transaction is  
associated with a single thread, period.

If your pmap call happens to initialize other transactions on other  
threads, those transactions will be completed completely independently  
of any transaction that may be in flight that initiated the pmap call  
itself (or send or send-off or future, or whatever other asynchronous  
mechanism at play).

That said, I would urge caution in circumstances like what you've  
described.  While you say that the refs being accessed in the other  
threads' transactions aren't the same as the refs being accessed in  
the parent transaction, you'll be in for some unpleasantness if that  
ceases to be true at some point.  e.g. the "child" transactions will  
see the original value of any refs changed so far in the "parent"  
transaction, the parent will not see any changes made to those refs by  
the child transactions, and if a parent transaction is waiting on a  
value being returned by a child transaction, and they both ensure or  
ref-set or alter the same ref, then you're likely in for a deadlock.

> If so, did it require anything special in the implementation to make
> that work?

Migrating transactions across thread boundaries *is* possible by  
judiciously copying thread-local bindings from one thread to another.   
There is a low-level API on clojure.lang.Var, etc. for doing this, but  
it's by no means pretty -- which I think is probably a good sign that  
doing so is fundamentally a bad idea at the moment.

If and until a better approach is available, I'd say the best approach  
would be to ensure that only *values* are going into your pmap calls  
(as opposed to refs), as that's the only way to ensure that you're not  
going to get tripped up by the thread-local nature of transactions.   
I've done just the opposite in the recent past, and the result was a  
lot of confusion and frustration, which ended up being part of  
learning a lesson the hard way. :-/

Cheers,

- Chas


--~--~-~--~~~---~--~~
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 dosync transaction result computation be parallelized over multiple threads?

2009-08-13 Thread Meikel Brandmeyer

Hi,

On Aug 13, 11:58 am, Chas Emerick  wrote:

> That said, I would urge caution in circumstances like what you've  
> described.

Additionally, transactions should be kept small. IIRC,
Rich recommended that before. If possible, don't do
complicated calculations inside a transaction.

Sincerely
Meikel

--~--~-~--~~~---~--~~
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 with problems building clojure-contrib

2009-08-13 Thread Arie van Wingerden
Hi,

I think I know what is going on.
You are using the Clojure 1.0, but you should use the latest Clojure,
because there are depoendencies.

This is what you need to do:
   1. remove Clojure 1.0
   2. get latest Clojure with git
   3. get latest Clojure-Contrib with git
   4. build Clojure using Ant
   5. build clojure-contrib using ant with the option
-Dclojure.jar=../clojure/clojure.jar
   (this is correct when both clojure and clojure-contrib are child
directories of the same parent;
otherwise specify your clojure.jar location)
That should fix your problem!

Regards
   Arie

2009/8/13 Barry Perryman 

>
> I'm new to clojure and I haven't touched the java platform for longer
> than I can remember, and I'm having a little difficulty building
> clojure-contrib.
>
> I've made a software/clojure folder, and installed clojure 1.0
> release. Under that folder I have made a clojure-contrib folder, and
> got the latest code off github, and put it there.
>
> When I try and build I get an error about walk.clj/walk__init.class
> not being in the class path.
>
> I've pasted what my mac system reports at the end, does anybody know
> what I'm doing wrong?
>
> Thanks
>
> Barry
>
>   $ java -version
>   java version "1.5.0_19"
>   Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-
> b02-304)
>   Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode,
> sharing)
>
>   $ ant -version
>   Apache Ant version 1.7.0 compiled on May 21 2009
>
>   $ ant
>   Buildfile: build.xml
>
>   init:
>
>   check_hasclojure:
> [echo] WARNING: You have not defined a path to clojure.jar so I
> can't compile files.
> [echo]   This will cause some parts of clojure.contrib not to
> work (e.g., pretty print).
> [echo]   To enable compiling, run "ant -Dclojure.jar=<...path
> to clojure.jar..>"
> [echo]
>
> compile_clojure:
>
> jar:
>
> BUILD SUCCESSFUL
> Total time: 0 seconds
>
>
>   $ ant -Dclojure.jar=../clojure-1.0.0.jar
>   Buildfile: build.xml
>
>   init:
>
>   check_hasclojure:
>
>   compile_clojure:
> [java] Compiling clojure.contrib.accumulators to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.agent-utils to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.classpath to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.combinatorics to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.command-line to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.complex-numbers to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.cond to /Users/barry/software/
> clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.condition to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.core to /Users/barry/software/
> clojure/clojure-contrib/classes
> [java] Compiling clojure.contrib.dataflow to /Users/barry/
> software/clojure/clojure-contrib/classes
> [java] java.io.FileNotFoundException: Could not locate clojure/
> walk__init.class or clojure/walk.clj on classpath:  (dataflow.clj:17)
>
>   Long stack trace removed...
>
> >
>

--~--~-~--~~~---~--~~
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 fast as Java?

2009-08-13 Thread rob

Piyush,

I would have to disagree.  If fft1976 was a troll then he wouldn't be
contributing meaningfully and substantively to testing performance in
Clojure on another thread.  So I think your accusation was unfair.
That said, I did find some of fft1976's comments to be somewhat
unnecessarily testy considering how friendly the Clojure community is
in general.

Rob

On Aug 12, 5:25 am, Piyush Ranjan  wrote:
> This is a troll question. I have seen similar questions posted on other
> forums about languages like ruby, CL, Haskell, Prolog, C, C++, fortran,
> bigloo(?) etc by the same poster.
>
> Try this link:http://www.google.co.in/search?q=fft1976%40gmail.com
>
> On Wed, Aug 12, 2009 at 2:00 PM, Nicolas Oury wrote:
>
>
>
> > Hello all,
>
> > Just wanted to add a small remark. If you look at the shootout, most
> > languages considered now to be very efficient has been once said to be
> > very very slow and not usable.
>
> > In the eighties, functional languages were doomed to be slow and
> > unusable for anything. And Ocaml/MLton and the like are now very fast.
>
> > Next laziness was thought to be too slow to be practical, and now
> > someone used ghc in this thread as an example of fast language.
> > I think everybody remembers what was being said about java 10 years ago.
> > And now java is the goal to attain.
> > I even think than C and C++ where too slow to be usable at their time.
>
> > Getting a compiler to produce fast code takes time and Clojure is young.
>
> >  What would be more useful than this discussion would be to take
> > fragments of code that looks inexplicably slow, profile them, and
> > transform them by hand to be faster.
> > And keep a wiki with which transformation gives which performance
> > improvement.
> > This could serve 3 goals:
> >  - giving ideas to people on how to optimize (the doc does not contain
> > every trick);
> >  - allow to write ugly but very efficient macros, that can be used in
> > bottlenecks ;
> >  - give ideas to which code transformation performed by the compiler
> > will improve performance and by how much.
>
> > What is sure is that there is no reason why clojure should be slow, when
> > some functional languages (including dynamically typed ones) are fast.
> > So, one day, it will be fast.
>
> > Best,
>
> > Nicolas.
>
> > On Tue, 2009-08-11 at 21:20 -0700, James Sofra wrote:
> > > Hi fft1976,
>
> > > > If you use Java's arrays and declare all types, should Clojure be as
> > > > fast as the equivalent Java?
>
> > > 
>
> > > So is the question you are trying to ask that since we have unwrapped
> > > access to Java is Java code written in Clojure as fast as if it were
> > > written as actual Java code?
>
> > > I guess that is a worthwhile question since it would at least tell you
> > > (if you are worried about speed) whether it is worth while dropping
> > > down to write actual Java code or if you can just write your Java in
> > > Clojure (as unidomatic as that Clojure code may be).
>
> > > I am sorry I don't have an answer for you, just wanted to clear up the
> > > question.
>
> > > Cheers,
> > > James
--~--~-~--~~~---~--~~
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: read-line in emacs slime on windows problem

2009-08-13 Thread DanL

Although I didn't solve the problem, I can confirm it.

I'm using latest clojure, slime, swank-clojure (pulled daily), and
Cygwin Emacs 23 on XP.

On 22 Jul., 22:45, Kelvin Ward  wrote:
> I've been using EmacsW32 withSLIME. Whenever I call (read-line) in
> theREPLit never completes reading the input. This problem does not
> happen when using the command line to launch the clojureREPL.
>
> I've tried combinations of clojure1.0.0.jar the 1.1 alpha snapshot,
> the latest clojure-contrib.jar, the latest clojure-mode for emacs and
> swank-clojure code. I've also tried the clojure box installation, but
> no success.
>
> Has anyone else come across this problem and handled it?
>
> 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: Newbie with problems building clojure-contrib

2009-08-13 Thread Barry Perryman


On Aug 13, 12:25 pm, Arie van Wingerden  wrote:
> Hi,
>
> I think I know what is going on.
> You are using the Clojure 1.0, but you should use the latest Clojure,
> because there are depoendencies.
>
> This is what you need to do:
>    1. remove Clojure 1.0
>    2. get latest Clojure with git
>    3. get latest Clojure-Contrib with git
>    4. build Clojure using Ant
>    5. build clojure-contrib using ant with the option
> -Dclojure.jar=../clojure/clojure.jar
>        (this is correct when both clojure and clojure-contrib are child
> directories of the same parent;
>         otherwise specify your clojure.jar location)
> That should fix your problem!
>
> Regards
>    Arie
>

Thanks to Arie, and everyone who answered, I've just updated with the
latest version and it built without a hitch.

Barry
--~--~-~--~~~---~--~~
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: core.clj: 'into' definition

2009-08-13 Thread Krukow



On Aug 11, 8:45 pm, Chouser  wrote:

> I don't know either.  'loop' is a macro that expands to
> 'loop*', which is in turn a special form.  At that most
> basic level, loop* still creates a recur point, so I don't
> think that's the point.

Can you enlighten us, Rich?

Cheers,
/Karl
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Transcript of Rich's "Clojure for Lispers" talk uploaded

2009-08-13 Thread Andy Fingerhut

This is the same Clojure for Lispers talk with audio, and video of
slides, available on clojure.blip.tv, among others, from the September
2008 Boston Lisp meeting.

It has been uploaded to the files section of the group with this name:

clojure-for-lispers-transcript.txt

I've added a very few references to books and articles that Rich
mentions during the talk, but other than that, it is just the text of
what he says, and a fraction of what the audience asks (some of them
are much more difficult to understand in the audio).

People are welcome to put this in some more easily accessible place,
if you know how and have the access to it.  For example, if a link to
it could be put on clojure.blip.tv, that might be cool.

Andy

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Request for Discussion: user created reader macros

2009-08-13 Thread Brian Hurt
I'm just wondering what people's response would be to allow user-generated
reader macros.  I'm not sure, but I think the only change to the clojure
core that would be necessary in order to do this would be that in
clojure/src/jvm/clojure/lang, LispReader.dispatchMacros would have to be
made public.  This would allow user code to update this array and add new
macro functions.

Now, I can certainly see a lot of potiential downsides to this.  Redefining
what #{} or #() means is just the start.  But it'd make it a lot easier to
do things with DSLs.

So, what are people's thoughts?

Brian

--~--~-~--~~~---~--~~
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: Augmenting the defn attr-map

2009-08-13 Thread Chas Emerick


On Aug 12, 2009, at 3:24 PM, Chas Emerick wrote:

>> I'd hate to see somebody do it, but it's currently valid to define
>> variables with colons in them, so there could be code out in the wild
>> with those definition forms already.  Other than that, I like the
>> looks of it.  I think the macro would be easy as well, so long as
>> you're comfortable munging variable names :)
>
> Well, that's one benefit/motivation to just have another def form,
> rather than trying to make defn support everyone's preferred  
> variation/
> style.
>
> I knocked out a quickie implementation that appears to work with the
> couple of use cases I've thrown at it so far (pasted at the end of
> this msg).

I've been fiddling with this, and produced a slight variant of my  
original macro that uses Type:arg-name symbols instead of arg- 
name:Type symbols. Example:

(defh a
   [b:String [c:Double :as list:java.util.List] {d:java.util.Random :d}]
   (.toCharArray b)
   (.size list)
   (.floatValue c)
   (.nextInt d))

I've actually been using it at the REPL here and there, and I've found  
it pretty pleasant -- it's a very pretty way to hint args compared to  
#^, and arg:Type ordering makes for easy readability (e.g. you can  
very easily scan an arg form and see what the names of the args are,  
as opposed to "actively" parsing them due to #^ hints or scanning for  
the (relatively unobtrusive) colon in the Type:arg style).

Code below.

Cheers,

- Chas

;;

(defn- decorate-hinted-symbol
   [sym]
   (let [[arg type] (.split (name sym) ":")]
 (if type
   (with-meta (symbol arg) {:tag (symbol type)})
   sym)))

(defn- decorate-hinted-args
   [args]
   (cond
 (vector? args) (vec (map decorate-hinted-args args))
 (map? args) (into {} (map decorate-hinted-args args))
 (symbol? args) (decorate-hinted-symbol args)
 (keyword? args) args
 :else (throw (Exception. (str args)

(defmacro defh
   [name args & body]
   `(defn ~name
  ~(decorate-hinted-args args)
  ~...@body))

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Daniel Lyons

On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:

> I'm just wondering what people's response would be to allow user- 
> generated reader macros.  I'm not sure, but I think the only change  
> to the clojure core that would be necessary in order to do this  
> would be that in clojure/src/jvm/clojure/lang,  
> LispReader.dispatchMacros would have to be made public.  This would  
> allow user code to update this array and add new macro functions.
>
> Now, I can certainly see a lot of potiential downsides to this.   
> Redefining what #{} or #() means is just the start.  But it'd make  
> it a lot easier to do things with DSLs.
>
> So, what are people's thoughts?

Trying to use them in Common Lisp has frustrated the crap out of me.  
The only library I know of that promulgates them seriously is CL-SQL  
and the gymnastics you have to do to install the reader macros are  
frustrating. Another library I tried to use I couldn't get to work at  
all (units, I think).

In general I don't think they're worth the trouble. Reducing code  
compatibility is also a problem. Perhaps with namespaces there could  
be a better way to do it than CL does but I'm very wary of them. I  
don't think Scheme lets you have them at all.

—
Daniel Lyons


--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Meikel Brandmeyer

Hi,

Am 13.08.2009 um 22:30 schrieb Brian Hurt:

Now, I can certainly see a lot of potiential downsides to this.   
Redefining what #{} or #() means is just the start.


I think, this is the reason Rich is not very positive for that idea:  
because nobody came up with a way of defining "namespaces" for reader  
macros, so that they don't interfere with each other.



But it'd make it a lot easier to do things with DSLs.


I'm happy with macros for DSLs. Actually the macros just quasiquote  
their arguments and pass them on to actual functions.



So, what are people's thoughts?


I've yet to see the desire for a self-defined reader macro. But I'm no  
Common Lisper (a Schemer actually). So I'm not used to reader macros.  
Maybe I'm missing the paradise.


I'm not necessarily opposed to the idea. But I wouldn't give it high  
priority either.


Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature


Re: Request for Discussion: user created reader macros

2009-08-13 Thread Chas Emerick


On Aug 13, 2009, at 4:59 PM, Daniel Lyons wrote:

> On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
>> I'm just wondering what people's response would be to allow user- 
>> generated reader macros.  I'm not sure, but I think the only change  
>> to the clojure core that would be necessary in order to do this  
>> would be that in clojure/src/jvm/clojure/lang,  
>> LispReader.dispatchMacros would have to be made public.  This would  
>> allow user code to update this array and add new macro functions.
>>
>> Now, I can certainly see a lot of potiential downsides to this.   
>> Redefining what #{} or #() means is just the start.  But it'd make  
>> it a lot easier to do things with DSLs.
>>
>> So, what are people's thoughts?
>
> Trying to use them in Common Lisp has frustrated the crap out of me.  
> The only library I know of that promulgates them seriously is CL-SQL  
> and the gymnastics you have to do to install the reader macros are  
> frustrating. Another library I tried to use I couldn't get to work  
> at all (units, I think).
>
> In general I don't think they're worth the trouble. Reducing code  
> compatibility is also a problem. Perhaps with namespaces there could  
> be a better way to do it than CL does but I'm very wary of them. I  
> don't think Scheme lets you have them at all.

Indeed, Rich has said that he's strongly disinclined to add them:

http://groups.google.com/group/clojure/browse_frm/thread/f1148b3569e8d275

For my part, I would like to have them available, simply because I  
like concise, purpose-built languages (xpath-esque tree traversal  
stuff lately).  But then, I can see the damage they've caused in other  
environments.  Power and responsibility aren't always well-managed.

- Chas

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Aaron Cohen

On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>
>> Now, I can certainly see a lot of potiential downsides to this.
>>  Redefining what #{} or #() means is just the start.
>
> I think, this is the reason Rich is not very positive for that idea: because
> nobody came up with a way of defining "namespaces" for reader macros, so
> that they don't interfere with each other.
>
>> But it'd make it a lot easier to do things with DSLs.
>
> I'm happy with macros for DSLs. Actually the macros just quasiquote their
> arguments and pass them on to actual functions.
>
>> So, what are people's thoughts?
>
> I've yet to see the desire for a self-defined reader macro. But I'm no
> Common Lisper (a Schemer actually). So I'm not used to reader macros. Maybe
> I'm missing the paradise.
>
> I'm not necessarily opposed to the idea. But I wouldn't give it high
> priority either.
>
> Sincerely
> Meikel
>
>

Would it make any difference if the scope of the reader macro was
limited to the file which defines/uses it?  Any file that wanted to
use a custom reader macro would then have to add its own
(use-reader-macro ...) statements, and there'd be no possibility for
conflicts.

Something like:

(defn comment-block-begin []
 "Dispatch function for beginning of block comments")

(use-reader-macro '#| comment-block-begin)

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Aaron Cohen

On Thu, Aug 13, 2009 at 5:23 PM, Aaron Cohen wrote:
> On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
>> Hi,
>>
>> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>>
>>> Now, I can certainly see a lot of potiential downsides to this.
>>>  Redefining what #{} or #() means is just the start.
>>
>> I think, this is the reason Rich is not very positive for that idea: because
>> nobody came up with a way of defining "namespaces" for reader macros, so
>> that they don't interfere with each other.
>>
>>> But it'd make it a lot easier to do things with DSLs.
>>
>> I'm happy with macros for DSLs. Actually the macros just quasiquote their
>> arguments and pass them on to actual functions.
>>
>>> So, what are people's thoughts?
>>
>> I've yet to see the desire for a self-defined reader macro. But I'm no
>> Common Lisper (a Schemer actually). So I'm not used to reader macros. Maybe
>> I'm missing the paradise.
>>
>> I'm not necessarily opposed to the idea. But I wouldn't give it high
>> priority either.
>>
>> Sincerely
>> Meikel
>>
>>
>
> Would it make any difference if the scope of the reader macro was
> limited to the file which defines/uses it?  Any file that wanted to
> use a custom reader macro would then have to add its own
> (use-reader-macro ...) statements, and there'd be no possibility for
> conflicts.
>
> Something like:
>
> (defn comment-block-begin []
>     "Dispatch function for beginning of block comments")
>
> (use-reader-macro '#| comment-block-begin)
>

Oops, I see on the link given elsewhere in this thread that that was
already discussed and dismissed.

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Bradbev

What is the main point of reader macros?  Is it so you can define your
own short-hand syntax, or is it the ability to get more direct access
to the reader?
If it is the first point, then I'd be happy to not have them - to me
shorthand doesn't buy much.
If it is the second point then why not simply have the reader pipe raw
text into a reader macro?
Ie, usage would be like
(def-reader-macro pass-through [raw-string]
  (read-string raw-string))

Usage would be (pass-through (+ 1 2)).  The pass-through call would be
given "(+ 1 2)" in the raw-string argument and must return a value
that can be eval'd.

More complex "reader" macros could be (infix x + y + z / 3).

Thoughts?
Brad


On Aug 13, 2:23 pm, Aaron Cohen  wrote:
> On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
> > Hi,
>
> > Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>
> >> Now, I can certainly see a lot of potiential downsides to this.
> >>  Redefining what #{} or #() means is just the start.
>
> > I think, this is the reason Rich is not very positive for that idea: because
> > nobody came up with a way of defining "namespaces" for reader macros, so
> > that they don't interfere with each other.
>
> >> But it'd make it a lot easier to do things with DSLs.
>
> > I'm happy with macros for DSLs. Actually the macros just quasiquote their
> > arguments and pass them on to actual functions.
>
> >> So, what are people's thoughts?
>
> > I've yet to see the desire for a self-defined reader macro. But I'm no
> > Common Lisper (a Schemer actually). So I'm not used to reader macros. Maybe
> > I'm missing the paradise.
>
> > I'm not necessarily opposed to the idea. But I wouldn't give it high
> > priority either.
>
> > Sincerely
> > Meikel
>
> Would it make any difference if the scope of the reader macro was
> limited to the file which defines/uses it?  Any file that wanted to
> use a custom reader macro would then have to add its own
> (use-reader-macro ...) statements, and there'd be no possibility for
> conflicts.
>
> Something like:
>
> (defn comment-block-begin []
>      "Dispatch function for beginning of block comments")
>
> (use-reader-macro '#| comment-block-begin)
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Daniel Lyons


On Aug 13, 2009, at 3:35 PM, Bradbev wrote:

>
> What is the main point of reader macros?  Is it so you can define your
> own short-hand syntax, or is it the ability to get more direct access
> to the reader?
> If it is the first point, then I'd be happy to not have them - to me
> shorthand doesn't buy much.
> If it is the second point then why not simply have the reader pipe raw
> text into a reader macro?
> Ie, usage would be like
> (def-reader-macro pass-through [raw-string]
>  (read-string raw-string))
>
> Usage would be (pass-through (+ 1 2)).  The pass-through call would be
> given "(+ 1 2)" in the raw-string argument and must return a value
> that can be eval'd.
>
> More complex "reader" macros could be (infix x + y + z / 3).


I think you can already do that with regular macros.

I'm under the impression reader macros usually have to be prefixed  
with #, like #(foo %) which expands to (fn [x] (foo x)) or something  
like that. I can't find the common lisp units package I was talking  
about, but if it were perfect it would have worked something like Frink:

   http://futureboy.us/frinkdocs/

So you could do something like (+ 1m 2m) and have it give you back 3m,  
and if you did (/ 10m 5s) it would give you back 2m/s, and blow up if  
you tried to do (+ 1m 2m^2).

It would be difficult to do such a thing unobtrusively without a  
reader macro.

The other project I had experience with, CL-SQL, I think having a  
reader macro was sort of an abuse; it doesn't matter much if you have  
to put a call around your SQL or even stick it in quotes. Especially  
because it's unclear to me what value you should get from reading an  
SQL expression other than a string, unless it's going to blow up when  
you have a syntax error at compile time, but as an abstraction layer  
it certainly didn't have enough information to do that correctly at  
compile time.

—
Daniel Lyons


--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Bradbev



On Aug 13, 3:43 pm, Daniel Lyons  wrote:
> On Aug 13, 2009, at 3:35 PM, Bradbev wrote:
>
>
>
>
>
> > What is the main point of reader macros?  Is it so you can define your
> > own short-hand syntax, or is it the ability to get more direct access
> > to the reader?
> > If it is the first point, then I'd be happy to not have them - to me
> > shorthand doesn't buy much.
> > If it is the second point then why not simply have the reader pipe raw
> > text into a reader macro?
> > Ie, usage would be like
> > (def-reader-macro pass-through [raw-string]
> >  (read-string raw-string))
>
> > Usage would be (pass-through (+ 1 2)).  The pass-through call would be
> > given "(+ 1 2)" in the raw-string argument and must return a value
> > that can be eval'd.
>
> > More complex "reader" macros could be (infix x + y + z / 3).
>
> I think you can already do that with regular macros.

I don't think so.  Macros are invoked after the read stage but before
evaluation of arguments.  This kind of macro would be invoked without
the text going through any kind of reader expansion.

Brad
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Scott


On Aug 13, 1:30 pm, Brian Hurt  wrote:
> I'm just wondering what people's response would be to allow user-generated
> reader macros. [...]

I think you could get most of the benefits for DSL's by using regular
strings, except that regular strings have quoting issues:

  (my-dsl-macro "Here is my string, but I have to escape \"
characters, which is unpleasant")


A single "super quoted" string reader would avoid this problem.
Instead of defining a new read syntax like:

  #my-syntax(your DSL goes between here and here)

Clojure could provide a general purpose string creating read syntax.
Something like #"...

  (my-dsl-macro #"///Here is a specially quoted string, and I can put
anything besides three slashes in it///)

  (my-dsl-macro #"--- In this case, I can type anything except three
dashes---)

  (pretend-this-one-is-apl #"///X[⍋X+.≠' ';]///)

They're just plain old macros, so namespaces would be resolve as they
do now.

Just a thought...


--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Chas Emerick

On Aug 13, 2009, at 8:29 PM, Scott wrote:

> A single "super quoted" string reader would avoid this problem.
> Instead of defining a new read syntax like:
>
>  #my-syntax(your DSL goes between here and here)
>
> Clojure could provide a general purpose string creating read syntax.
> Something like #"...

A good thought, but #"foo" is reader syntax for defining a regular  
expression with the pattern "foo". :-/

Double-quoted strings are decent for stuff like this. (Triple-quotes  
in python always appealed to me, though triple-quoting things can get  
tiring.)

- Chas

--~--~-~--~~~---~--~~
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: Keyword not serializable

2009-08-13 Thread Chas Emerick

On Jul 31, 1:47 pm, Chris Kent  wrote:
> Great.  As far as my (possibly flawed) understanding goes it should be
> pretty simple.  Make it implementSerializableand add a readResolve
> method that returns intern(sym).  sym will have already been interned
> by its own readResolve method.

No, you're exactly right.  I've opened a ticket for this enhancement/
fix, including a patch:

http://www.assembla.com/spaces/clojure/tickets/174

You can use the patch on your own right away if you're building
clojure from source.

Cheers,

- Chas
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Michele Simionato

On Aug 14, 2:47 am, Chas Emerick  wrote:
> On Aug 13, 2009, at 8:29 PM, Scott wrote:
>
> > A single "super quoted" string reader would avoid this problem.
> > Instead of defining a new read syntax like:
>
> >  #my-syntax(your DSL goes between here and here)
>
> > Clojure could provide a general purpose string creating read syntax.
> > Something like #"...
>
> A good thought, but #"foo" is reader syntax for defining a regular  
> expression with the pattern "foo". :-/
>
> Double-quoted strings are decent for stuff like this. (Triple-quotes  
> in python always appealed to me, though triple-quoting things can get  
> tiring.)
>

Have a look at Scribble in PLT Scheme:

http://barzilay.org/misc/scribble-reader.pdf
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Richard Newman

>> So, what are people's thoughts?
>
> Trying to use them in Common Lisp has frustrated the crap out of me.  
> The only library I know of that promulgates them seriously is CL-SQL  
> and the gymnastics you have to do to install the reader macros are  
> frustrating. Another library I tried to use I couldn't get to work  
> at all (units, I think).

AllegroGraph uses ! as a reader macro to introduce URIs and RDF  
literals, which means they appear quite frequently in user code. You  
can write

!rdf:type
!
!"chien"@fr

and the appropriate object (a so-called future-part) is integrated  
directly into the read code, just like a string or a list. This has  
three advantages over something like

(resource "rdf" "type")

—

* This process happens at read-time, which means that you can use this  
syntax in *unevaluated* positions, such as in macros, query forms that  
are only read, not evaluated, etc. That can be really convenient.

* The syntax is much closer to the conventional syntax used in  
serialization formats (simply add a '!' to the front of the usual  
syntax). Users who are more familiar with Java or Python don't seem to  
mind, which is not true when you add parentheses to your syntax.

* You can raise a syntax error at read time, rather than at compile-  
or run-time. That's a nice feature in a dynamic language, where you  
might not know your code is broken until much later. It's nice for  
DSLs to have distinct syntax and semantics, and requiring the use of  
macros or functions to implicitly construct syntactic elements blurs  
that line.

I've observed this in the discrepancy between the 'primary' Clojure  
types, such as set, map, et al, which have syntax, and those which do  
not: sorted-set or struct-map, for example.

However, for all these benefits I'm still not sure whether it would be  
worthwhile allowing user-generated reader macros. They are absolute  
hell when integrating conflicting libraries — it only takes one major  
library to use a reader macro character, and it's pretty much verboten  
for all other libraries, just in case you want to combine them.

Franz's Allegro Common Lisp offers a workaround for this problem —  
named readtables, which makes using readtables in CL much tidier. If a  
library's readtable does not take effect in user code until demanded,  
then conflicts do not occur. Code that uses libraries with conflicting  
syntax can be partitioned to use different readtables.

If it were possible to signal to Clojure's reader which readtable to  
use when reading a file/stream/string, and readtables were named in a  
similar manner to namespaces, and could be composed, then I think user- 
defined reader macros would be safe and convenient. Just as in-ns and  
ns adjust the current namespace, they could adjust the readtable:

(ns com.example.foo
   (:refer-clojure)
   (:use com.example.library1)
   (:readtables
 clojure.core
 com.example.library1))


I'm sure this would complicate Clojure's reader significantly.

-R
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Scott


On Aug 13, 5:47 pm, Chas Emerick  wrote:
>
> A good thought, but #"foo" is reader syntax for defining a regular  
> expression with the pattern "foo". :-/
>

Sorry about that, I'm not experienced at Clojure, but I should have
been more clear.  The first important part isn't which character
triggers the arbitrary string literal (as you point out, #" is already
taken), but that you get to choose the terminating delimiter such that
it doesn't interfere with your DSL.  The second part is that once you
can cleanly express arbitrary string literals, a regular macro can
substitute for a reader macro and avoids the namespace issues.

>
> Double-quoted strings are decent for stuff like this. (Triple-quotes  
> in python always appealed to me, though triple-quoting things can get  
> tiring.)
>

I use Python's triple quotes too, but you may want to create a DSL
that can contain both ''' (triple single quote) and """ (triple double
quote) in it.  (For instance if you were embedding Python source. :-)


--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Adrian Cuthbertson

Hmm, not so sure this is related, but I've often thought it would be
great to have some way of having "embedded" source of other types as a
"special" string defined as normal in the clojure source but marked in
such as way that the editor (vim, emacs, etc) could recognise this and
do formatting, syntax highlighting, etc on that text. Similarly to say
editing HTML with embedded javascript/css/jsp.

This could presumably be done by using some meta-data convention
rather than a reader macro, but this thread brought up the idea.

Any thoughts?

On Fri, Aug 14, 2009 at 5:55 AM, Scott wrote:
>
>
> On Aug 13, 5:47 pm, Chas Emerick  wrote:
>>
>> A good thought, but #"foo" is reader syntax for defining a regular
>> expression with the pattern "foo". :-/
>>
>
> Sorry about that, I'm not experienced at Clojure, but I should have
> been more clear.  The first important part isn't which character
> triggers the arbitrary string literal (as you point out, #" is already
> taken), but that you get to choose the terminating delimiter such that
> it doesn't interfere with your DSL.  The second part is that once you
> can cleanly express arbitrary string literals, a regular macro can
> substitute for a reader macro and avoids the namespace issues.
>
>>
>> Double-quoted strings are decent for stuff like this. (Triple-quotes
>> in python always appealed to me, though triple-quoting things can get
>> tiring.)
>>
>
> I use Python's triple quotes too, but you may want to create a DSL
> that can contain both ''' (triple single quote) and """ (triple double
> quote) in it.  (For instance if you were embedding Python source. :-)
>
>
> >
>

--~--~-~--~~~---~--~~
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: Transcript of Rich's "Clojure for Lispers" talk uploaded

2009-08-13 Thread fft1976

I was just watching that earlier. Here's an interesting part (as per
earlier discussion).

http://blip.tv/file/1313503
56:00

With type hints, you can get Java (?) code to run EXACTLY the same
speed as Java, so Clojure is FAST.

P.S. The moderators (Chouser) are now censoring my posts, so if you
don't see this message on the list as well, that's why.

On Aug 13, 1:40 pm, Andy Fingerhut 
wrote:
> This is the same Clojure for Lispers talk with audio, and video of
> slides, available on clojure.blip.tv, among others, from the September
> 2008 Boston Lisp meeting.
>
> It has been uploaded to the files section of the group with this name:
>
> clojure-for-lispers-transcript.txt
>
> I've added a very few references to books and articles that Rich
> mentions during the talk, but other than that, it is just the text of
> what he says, and a fraction of what the audience asks (some of them
> are much more difficult to understand in the audio).
>
> People are welcome to put this in some more easily accessible place,
> if you know how and have the access to it.  For example, if a link to
> it could be put on clojure.blip.tv, that might be cool.
>
> Andy

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Daniel Lyons


On Aug 13, 2009, at 5:30 PM, Bradbev wrote:

>>> More complex "reader" macros could be (infix x + y + z / 3).
>>
>> I think you can already do that with regular macros.
>
> I don't think so.  Macros are invoked after the read stage but before
> evaluation of arguments.  This kind of macro would be invoked without
> the text going through any kind of reader expansion.


Isn't reader expansion exactly what you don't want?

user> (defmacro infix [& args]
`(quote ~args))
#'user/infix
user> (infix 3 + 4 * 7)
(3 + 4 * 7)

I don't understand what's stopping anyone from implementing the body  
of that macro to make it actually implement infix arithmetic.

—
Daniel Lyons


--~--~-~--~~~---~--~~
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: Transcript of Rich's "Clojure for Lispers" talk uploaded

2009-08-13 Thread Daniel Lyons


On Aug 13, 2009, at 6:56 PM, fft1976 wrote:

>
> I was just watching that earlier. Here's an interesting part (as per
> earlier discussion).
>
> http://blip.tv/file/1313503
> 56:00
>
> With type hints, you can get Java (?) code to run EXACTLY the same
> speed as Java, so Clojure is FAST.

And you can, just not always.

The point of my previous message which exasperated you so much was  
just to say that if the performance of the language isn't acceptable  
to you, the code is open source and the techniques for adding  
optimizations to compilers are well known. So marshall your impulses  
for the good and we'll all benefit. Instead it feels to me like you're  
trying to "win" something or other by catching Rich or the community  
in a lie. This kind of behavior isn't helpful to anyone and it's why  
you're being moderated.

—
Daniel Lyons


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Problems with AOT compiled Clojure on Azul

2009-08-13 Thread Krukow

When running the AOT compiled Clojure (clojure.jar) on an Azul box I
get an error during startup (in particular in the class-initializer
for clojure.main). This error does not occur in the clojure-slim.jar.
The stacktrace is this:

k...@azulpod1:~/download$ java $JVM_PARAMS -cp clojure.jar clojure.main
RTPM: Listening for HTTP connections on 0.0.0.0:52798.
Exception in thread "main" java.lang.ExceptionInInitializerError
   at clojure.lang.Namespace.(Namespace.java:32)
   at clojure.lang.Namespace.findOrCreate(Namespace.java:117)
   at clojure.main.(main.java:21)
Caused by: java.lang.RuntimeException:
java.lang.IllegalStateException: Var clojure.core/refer is unbound.
   at clojure.lang.RT.(RT.java:291)
   ... 3 more
Caused by: java.lang.IllegalStateException: Var clojure.core/refer
is
unbound.
   at clojure.lang.Var.deref(Var.java:140)
   at clojure.lang.Var.fn(Var.java:323)
   at clojure.lang.Var.invoke(Var.java:346)
   at clojure.lang.RT.doInit(RT.java:417)
   at clojure.lang.RT.(RT.java:288)
   ... 3 more
k...@azulpod1:~/download$ echo $JVM_PARAMS
-PX:PolicyVhost=192.168.102.200 -PX:CPMDomain=podv2demo -
PX:AppLabel=v3 -PX:RTPMPort=any -PX:RTPMAuthorization=9@
k...@azulpod1:~/download$

This error does not occur on my 2-core macbook; I've only seen it on
the 216-core Azul box.

Anyone?

/Karl
--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Chouser



On Aug 14, 2009, at 12:48 AM, Daniel Lyons   
wrote:

>
>
> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>
 More complex "reader" macros could be (infix x + y + z / 3).
>>>
>>> I think you can already do that with regular macros.
>>
>> I don't think so.  Macros are invoked after the read stage but before
>> evaluation of arguments.  This kind of macro would be invoked without
>> the text going through any kind of reader expansion.
>
>
> Isn't reader expansion exactly what you don't want?
>
> user> (defmacro infix [& args]
>`(quote ~args))
> #'user/infix
> user> (infix 3 + 4 * 7)
> (3 + 4 * 7)
>
> I don't understand what's stopping anyone from implementing the body
> of that macro to make it actually implement infix arithmetic.

That particular example may not have to be a macro at all:

http://paste.lisp.org/display/75230

I think people want reader macros for a couple different reasons.   
Sometimes it's just to remove parens from a function or macro call."

--~--~-~--~~~---~--~~
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: Request for Discussion: user created reader macros

2009-08-13 Thread Chouser



On Aug 14, 2009, at 2:03 AM, Chouser  wrote:

>
>
> On Aug 14, 2009, at 12:48 AM, Daniel Lyons   
> wrote:
>
>>
>>
>> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>>
> More complex "reader" macros could be (infix x + y + z / 3).

 I think you can already do that with regular macros.
>>>
>>> I don't think so.  Macros are invoked after the read stage but  
>>> before
>>> evaluation of arguments.  This kind of macro would be invoked  
>>> without
>>> the text going through any kind of reader expansion.
>>
>>
>> Isn't reader expansion exactly what you don't want?
>>
>> user> (defmacro infix [& args]
>>   `(quote ~args))
>> #'user/infix
>> user> (infix 3 + 4 * 7)
>> (3 + 4 * 7)
>>
>> I don't understand what's stopping anyone from implementing the body
>> of that macro to make it actually implement infix arithmetic.
>
> That particular example may not have to be a macro at all:
>
> http://paste.lisp.org/display/75230
>
> I think people want reader macros for a couple different reasons.   
> Sometimes it's just to remove parens from a function or macro call."

(sorry, finger slipped on the send button)

Another rather different reason is to implement features that would  
otherwise require manually escaped strings as was mentioned earlier.

Perhaps these different desires can fulfilled with two different  
constructs.

--Chouser

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---