True, lack of conciseness may not be the first thing that comes to mind
when speaking about Lisps :-)
What I should have said is that I think equivalent Python code has fewer
'noise' symbols than S-expressions. Of course, that depends greatly on how
the programs are structured.
And, that bri
There's a very nice summary of previous attempts at this on David Wheeler's
web page: http://www.dwheeler.com/readable/index.html
I think these ideas have some merit. I would like to have the readability
and conciseness of Python with the features and performance of Clojure.
--
You received t
I see! I'll have to go back and read up on these features.
Thanks to everyone!
--
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 p
I've been experimenting with the numeric capabilities of Clojure and I
encountered this:
Clojure 1.2.1
user=> (apply * (repeat 100 2))
1267650600228229401496703205376
Clojure 1.3.0-RC0
user=> (apply * (repeat 100 2))
ArithmeticException integer overflow
clojure.lang.Numbers.throwIntOverflow (Numb
Hi,
I would generally agree with Stuart that wrapping Java functions is
not a good idea.
However, string functions come up so often that I think that this is
one area where the rule should be broken, if only for readablility.
Making str-utils kick-ass is a great idea.
pc
On Mar 24, 7:05 pm
t where it originally came from.
So some sort of naming convention base on "_" for data that came from
a database and "-" for other stuff, would never work.
I realize that this is probably way too late. And maybe the current
way is better anyway.
pc
--~--~-~--~~
s qualified instance
(clojure.contrib.stacktrace/e) -- ns qualified function
(st/e) -- alias qualifed function
Regards,
pc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@g
Hi,
Currently:
(macroexpand-1 '(.toUpperCase #^String s))
==> (. s toUpperCase)
would it be better/possible to preserve type information? I.e.,
(macroexpand-1 '(.toUpperCase #^String s))
==> (. #^String s toUpperCase)
Regards,
-- pc
--~--~-~--~~~
I think that having efficient algorithms for the fundamental data
structures is extremely important.
But Rich and the Contributers must have tons of other stuff to worry
about. In the meantime I will
use Jason's fix.
On Jan 20, 8:27 pm, Mark Engelberg wrote:
> I say "thumbs up" to this proposal.
I think that the get-source function should be changed slightly so
that hyphens in the path (at the first let form) are replaced by
underscores. This would update the function to be consistent with the
documentation for lib.
More generally, are hyphens replaced by underscores in the file and
path
This is very useful. For me it was useful to be able to limit the
output to lines that contained a few selected letters.
(show String "pper")
=== public final java.lang.String ===
[82] toUpperCase : String ()
[83] toUpperCase : String (Locale)
nil
I could always C-C C-O to flush the long outpu
This is very useful. Thanks for doing it.
On windows xp find-javadoc-url would not work for local javadocs,
maybe because of window's "c:\xx" syntax. Using (.toURL file) seemed
to fix it. Maybe that will work for the other systems also.
(defn find-javadoc-url
"Searches for a URL for the given
I think this is a great idea.
On Oct 8, 5:08 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Oct 7, 11:18 pm, Chouser <[EMAIL PROTECTED]> wrote:
>
>
>
> > Is it bad etiquette to reply to myself? I thought it might be useful
> > to compare the proposed syntax with that of other languages with goo
13 matches
Mail list logo
