Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 5077 days ago | link | parent

Whoops, I simplified test 4 a bit too much before I posted it.

  (pr "Test 6 ")
  (= test6 (let args (list t nil 'nil () '() "" '(#\e "s")
                           '(nil "" () (t 6)))
             (list (apply string args)
                   (apply apply + "" args)
                   (apply + "" args))))
  (prn:if (iso test6 '("test6" "test6" "test6"))
    "succeeded."
          (iso test6 '("te\"s\"nil\"\"()(t 6)"
                       "te\"s\"t6"
                       "te\"s\"nil\"\"()(t 6)"))
    "failed with the result expected on Rainbow."
          (iso test6 (list "tnilnilnilnilesnilnil(t 6)"
                           (+ "t(#" #\\ "e \"s\")(t 6)")
                           (+ "t(#" #\\ "e \"s\")(nil \"\" nil (t 6))")))
    "failed with the result expected on Jarc."
    "failed with an unexpected result.")
It's probably more convoluted than it has to be, but I'm leaving it that way this time. ^_^

Note that the string literal "...\e..." crashes Rainbow and the string literal "...\\e..." (which is what I really want) behaves incorrectly on Jarc.

Also, if I paste the above code into the Rainbow REPL directly, Rainbow almost always errors out and exits. The paste works if I remove the Jarc case or the Rainbow case, and I've also found it to work if there's been quite a bit of other input during the session. There's a similar issue on Jarc (which prints a stack trace about not having enough memory to read from the input), and, well, it could have something to do with my system.



1 point by jazzdev 5076 days ago | link

the string literal "...\\e..." (which is what I really want) behaves incorrectly on Jarc.

Yeah, I intentionally don't handle escaped strings in Jarc the same as Arc. One frustration in Java is using regular expressions. You have to say

  \\s*(\\d+)\\s*
when you mean

  \s*(\d+)\s*
and regex's are hard enough to read without making them more complex. So in Jarc, I decided that only \n \r \t and \\ would have a special meaning. Every other \ is treated as a literal backslash. So Jarc treats \e as the two characters \ and e. Yeah. Non-standard, non-intuitive. No argument there. But it made regex's so much nicer to read that I decided it was a worthwhile trade-off.

This has made me realize why Perl has a separate syntax for regex.

Jarc should probably have a declare to turn this behavior on and off. At least that would provide compatibility with Arc. Jarc doesn't have \x or \u syntax either, which it should.

-----

1 point by rocketnia 5075 days ago | link

Well, I don't disagree with you on most of those topics, but you missed what I was saying. Your special meaning of \\ seems to be two backslashes. ^_^

  arc> (prn "...\\e...")   ; Arc 3.1
  ...\e...
  "...\\e..."
  
  Jarc> (prn "...\\e...")  ; Jarc
  ...\\e...
  nil
Note that if you were to "fix" this, it would mean certain regexes would use "\\\\", and that sounds like it could be what you want the least. As for me, I don't mind whatever you choose as long as it's intentional. :-p

-----

1 point by jazzdev 5071 days ago | link

Yeah, \\ means \\. It's \n \r \t and \" that are treated specially.

Though I realized Jarc needs a way to enter non-printable characters, so I've added

  \f
  \a
  \e
  \0*oo*
  \x*hh*
  \u*hhhh*
None of those interfere with regular expressions. Though I still don't have an intuitive way to put \e in a string. You can do \x5ce now (in Jarc 16) but that's ugly. I guess \\ needs to be just \ when it's followed by n r t f a e " 0 x or h. That's getting a bit complex, but I guess it's intuitive. Or maybe I should just add a regular expression literal with / delimiters like Perl has.

-----