There are edn impls in at least 15 languages so the problem is wider than just
java and js.
--
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 -
How would you resolve the problem "Rich Hickey" mentioned on the page you
linked? "The lack of portability for regexes"... True, *some* regex
patterns mean the same thing in the JVM and JS, but in general a regex
pattern is not a portable value; it may mean something different to each
regex l
Thanks for the reply! Glad to have confirmations.
--
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.
T
Not adding much to what you've already said, but a custom reader tag is
exactly what I would reach out for in this situation.
--
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 post
clojure.string/replace replaces the portion of the string matched by the regex
with the replacement. If you add ".*" to the regex, the regex will match the
entire input string and the form will evaluate to "First".
--Steve
On May 27, 2014, at 11:24 AM, Glen Rubin wrote:
> I have a string of t
Of course! Thank you.
On Friday, 18 April 2014 15:33:39 UTC+1, A. Webb wrote:
>
>
>
> On Friday, April 18, 2014 8:28:03 AM UTC-5, Thumbnail wrote:
>>
>>
>> ... I decided that the terminal state would always be at index 0 ...
>>>
>>
>> Shouldn't a DFA allow for *any* *set* of states to be termina
On Friday, April 18, 2014 8:28:03 AM UTC-5, Thumbnail wrote:
>
>
> I had a couple of insights. First, to allow the dfa to be generated
>> programmatically, I changed it from a map to a vector. This means
>> that the next state can just be an integer. Second, I decided that
>> the terminal s
> I had a couple of insights. First, to allow the dfa to be generated
> programmatically, I changed it from a map to a vector. This means
> that the next state can just be an integer. Second, I decided that
> the terminal state would always be at index 0 ...
>
Shouldn't a DFA allow for *a
*Hi,*
Not sure about your context and your need.
Are you looking for this?
*[LM][LM][LM][0-9][0-9]*
or this?
*LLL[0-9][0-9]|**MMM[0-9][0-9]*
that matches
*LLL[0-9][0-9]* or *MMM[0-9][0-9]*
Hope that helps.
*Greetings,
Rafael*
On Fri, Jul 30, 2010 at 6:02 PM, Base wrote:
> Hi All -
>
> I am
If you want a single regex that matches either M123.5554 or 1234.435M, you need
to use the OR form (a|b):
([ML]\d+\.\d+|\d+\.\d+[ML])
where:
[ML] matches M or L
\d+ matches 1 or more digits
\. matches a .
-Fred
--
Science answers questions; philosophy questions answers.
That's not a Clojure question, but if you ask it on StackOverflow you'll get
an answer in like 2 seconds. :) From your description it sounds like you
want /^[ML]{3}[0-9]{2}$/ but the description of your problem could be
interpreted in a few other ways, so that might not be what you want.
On Fri,
Cool, I think I'll stick to my current one which lets me easily use multiple
replacements in one call.
--
Discouragement is a dissatisfaction with the past, a distaste for the
present, and a distrust of the future - Maree De Jong, Life Church New
Zealand.
http://www.talios.com
Sent from Auckland
Mark Derricutt wrote:
> Does clojure come with a built-in regex replace method? I see ones for
> re-split, re-seq etc. but nothing for a simple replace, I've been using:
>
> (defn replace-all
> [st reps]
> (reduce #(.replaceAll %1 (first %2) (second %2)) st reps))
There is re-gsub in clojur
On Wed, Oct 15, 2008 at 7:12 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> Patch applied - SVN rev 1070 - thanks!
Possible reader docs:
Regex patterns (#"pattern")
A regex pattern is read and compiled at read time. The pattern is
passed directly to the java.util.regex.Pattern compile method, so
On Oct 10, 5:02 pm, Chouser <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 10, 2008 at 7:48 AM, Chouser <[EMAIL PROTECTED]> wrote:
>
> > Of course that means I need to do this for you when printing...
>
> I've attached an updated patch with a new print method, against the
> latest SVN 1058.
>
> If you
On Fri, Oct 10, 2008 at 7:48 AM, Chouser <[EMAIL PROTECTED]> wrote:
>
> Of course that means I need to do this for you when printing...
I've attached an updated patch with a new print method, against the
latest SVN 1058.
If you really want to dig into the ugliness, here's a test I've been
using.
On Fri, Oct 10, 2008 at 4:07 AM, Christophe Grand <[EMAIL PROTECTED]> wrote:
>
> Hello Chouser, (btw, nice work you are doing with ClojureScript)
Thanks -- good to see you around again!
> Do you plan to support printing of all Pattern instances or only those
> created using the new literal synta
Chouser a écrit :
> On Thu, Oct 9, 2008 at 4:57 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
>> Go for it.
>>
>
> (defmethod print-method java.util.regex.Pattern [p #^Writer w]
> (.write w "#\"")
> (loop [[#^Character c & r :as s] (seq (.pattern #^java.util.regex.Pattern
> p))]
>
On Thu, Oct 9, 2008 at 4:57 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> Go for it.
(defmethod print-method java.util.regex.Pattern [p #^Writer w]
(.write w "#\"")
(loop [[#^Character c & r :as s] (seq (.pattern #^java.util.regex.Pattern p))]
(when s
(cond
(= c \\) (do (.a
On Oct 9, 4:48 pm, Chouser <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 9, 2008 at 3:09 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > The question is, are people willing to deal with the breakage in the
> > short term?
>
> I certainly am, but that may not mean much. :-)
> Nobody has spoken out ag
On Thursday 09 October 2008 12:09, Rich Hickey wrote:
> ...
>
> The question is, are people willing to deal with the breakage in the
> short term?
I have no skin in this game, so what I say is to be taken with a grain
of salt, but...
If you make this change, millions of Clojure users for all et
On Thu, Oct 9, 2008 at 3:09 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> The question is, are people willing to deal with the breakage in the
> short term?
I certainly am, but that may not mean much. :-)
Nobody has spoken out against it yet -- that's a got to be a good sign.
> Could there be a
Clojure is still beta-ish, no? I say either go with the breakage, or use the
#r"" without the user chosen delimiters.
The extra backquoting was admittedly a surprise for me at first. It seemed
awkward, and unexpected, so if some breakage occurs, then I think its
warranted. If breakage is a problem
On Oct 9, 2:44 pm, Chouser <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 9, 2008 at 2:03 PM, Paul Barry <[EMAIL PROTECTED]> wrote:
>
> > What about having #"pattern" work like is does now, and then having #/
> > pattern/ work similarly to Ruby, Python, Perl, etc. regular expression
> > in that they n
On Thu, Oct 9, 2008 at 2:03 PM, Paul Barry <[EMAIL PROTECTED]> wrote:
>
> What about having #"pattern" work like is does now, and then having #/
> pattern/ work similarly to Ruby, Python, Perl, etc. regular expression
> in that they not require double escaping of characters like '\'? So
> in othe
What about having #"pattern" work like is does now, and then having #/
pattern/ work similarly to Ruby, Python, Perl, etc. regular expression
in that they not require double escaping of characters like '\'? So
in other words:
#/(.*?)<\/em>/
instead of:
#"(.*?)<\\/em>"
The advantage to
On Oct 8, 2008, at 11:03 AM, Chouser wrote:
> Of course if this change is unacceptable, these proposed rules could
> be applied to a new dispatch macro. One option would be something
> like #r/foo/ that would allow your choice of delimiters to further
> reduce the need for back-slash quoting wit
Yes, dealing with multiple escaped escape sequences is a weak point of
handling regexs. To really integrate them into the language, and that
integration is essential to success, they must be typed straight into
the code literally without baggage.
As much as flexibility and simplicity, the easy a
Yes, I like this. The double backslashing is really a pain and
confused me at first. Get off that road now while clojure is still
pretty new.
Bob
On Oct 8, 9:03 am, Chouser <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 8, 2008 at 8:08 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > Will existing C
On Wed, Oct 8, 2008 at 11:03 AM, Chouser <[EMAIL PROTECTED]> wrote:
>
> Of course if this change is unacceptable, these proposed rules could
> be applied to a new dispatch macro. One option would be something
> like #r/foo/ that would allow your choice of delimiters to further
> reduce the need f
On Wed, Oct 8, 2008 at 8:08 AM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> Will existing Clojure regex (consumer) code need to change, i.e. will
> people need to modify their existing #"" literals and if so in what
> way?
Yes, many existing #"" literals would have new meaning or become
invalid un
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
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 good
> regex support.
>
> I tried all the examples from my previous message in Perl, Python,
> Ruby, a
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 good
regex support.
I tried all the examples from my previous message in Perl, Python,
Ruby, and JavaScript. All but Python have literal regex syntax, while
Pyth
I love it!
On Tue, Oct 7, 2008 at 4:37 PM, Chouser <[EMAIL PROTECTED]> wrote:
> Ok, I know we've been over this before, but nothing was actually done.
>
> For the record:
>
> http://groups.google.com/group/clojure/browse_thread/thread/81b361a4e82602b7/0313c224a480a161
>
> So here is my attempt fo
35 matches
Mail list logo
