Very minor nitpick: "nex3". The hyphen is only in my URL because nex3.com was taken :-p.
Also, I don't like overriding isa; it's just necessary sometimes because the standard libs aren't really geared towards duck typing. I much prefer overriding basic functions and having more complex functions assume those base functions will work. This is really what duck typing (as I understand it) is all about.
^^; lol. I think I've been rather consistently calling you nex-3 with a hyphen O.O;
The problem, I suppose, is the rather inconsistent formalization/nonformalization of type classes/interfaces/hindley-milner typesystem. In Ruby it's informal - you just say this or that object has this or that function which will just work, in the expected manner. In Haskell and Java it's formal - you say this type provides this type class or presents this interface, and must therefore have this or that function which must work, in the expected manner.
annotated types are kinda like a formal type class, except existing type classes are not trivially extendable except informally (via redef).
Yeah, I think that's right. And I think Arc should go the path of informality, for a couple reasons. First, it's dynamically typed, and duck typing (or informal typing) has historically worked well with dynamically-typed languages (with Ruby, Python, and maybe Smalltalk). CLOS also tends to that side of the spectrum, although I'm not sure how explicitly it embraces duck typing.
Second, and I think more importantly, duck typing gives the programmer more power, in exchange for more opportunity to screw stuff up. This is very much in line with Arc's philosophy.
Using formal interfaces, both the people writing the polymorphic code and the people writing the polymorphic objects have to explicitly code polymorphically. Using informal interfaces, only the people writing polymorphic objects have to be explicit. The other people can* be aware of the polymorphism, which allows powerful stuff like Ruby's Enumerable module, but as long as the objects behave correctly ("quack like a duck"), you can use pass them to code that doesn't expect them at all and they'll still work.
* I know less about Smalltalk than I want to, so I don't know how much it makes use of duck typing.
Yeah, I saw that, too. I agree it looks cool, but I'm a little skeptical because it's so much less concise than standard regular expressions. Maybe this is really a good thing, I dunno.
A distinction between regexen and strings is actually very handy. I've done a fair bit of coding in Ruby, where this distinction is present, and a fair bit in Emacs Lisp, where it's not.
There are really two places where it's really important. First, if regexen are strings, then you have to double-escape everything. /\.foo/ becomes "\\.foo". /"([^"]|\\"|\\\\)+"/ becomes "\"([^\"]|\\\\"|\\\\\\\\)+\"". Which is preferable?
Second, it's very often useful to treat strings as auto-escaped regexps. For instance,
a_string.split("\D+")
is actually valid Ruby. It's equivalent to
a_string.split("D+")
because D isn't an escape char, which will split the string on the literal string "D+". For example
"BAD++".split("D+") #=> ["BA", "+"]
Now, I'm not convinced that regexen are necessary for nearly as many string operations as they're typically used for. But I think no matter how powerful a standard string library a language has, they'll still be useful sometimes, and then it's a great boon to have literal syntax for them.
Ok, so what it comes down to, is that you don't want escapes to be processed. Wouldn't providing a non-escapable string be far more general, then?
Since '\D+' clashes with quote, maybe /\D+/ is a good choice for the non-escapable string syntax. Only problem is that using it in other places might trigger some reactions as the slashes make everybody think of it as "regex syntax".
Escaping isn't the only thing. Duck typing is also a good reason to differentiate regular expressions and strings. foo.gsub("()", "nil") is distinct from foo.gsub(/()/, "nil"), and both are useful enough to make both usable. There are lots of similar issues - for instance, it would be very useful to make (/foo/ str) return some sort of match data, but that wouldn't be possible if regexps and strings were the same type.
Now we're getting somewhere :) For this argument to really convince me, though, Arc needs better support for user defined types. It should be possible to write special cases of existing functions without touching the core definition. Some core functions use case forms or similar to treat data types differently. Extending those is not really supported. PG has said a couple of times;
"We believe Lisp should let you define new types that are treated just like the built-in types-- just as it lets you define new functions that are treated just like the built-in functions."
Using annotate and rep doesn't feel "just like built-in types" quite yet.
This is largely a library issue - Arc could certainly do with better support for string ops, regexen, and especially datetime manipulation. But here's what I came up with (note that date-days is pretty inaccurate most of the time):
I think you've highlighted at least one gap in Arc's arsenal. Using Arc2:
arc> (ssplit " foo bar ")
Error: "reference to undefined identifier: _ssplit"
You needed to use ssplit, but Arc doesn't have it.
I don't think the importance of string ops should be underestimated. Strings ops are just as essential as numerical ops. A language that cannot effortlessly manipulate strings is a low-level language in my book. If people are supposed to be testing Arc by using it instead of the languages they were using, Arc needs string ops. Can't they be easily lifted from mzscheme?
Remember the thread on implementing Eliza in Lisp and Ruby? No one posted an Arc version.
Oh, sorry, I should have specified: I used Anarki-specific stuff in several places. Mostly the date-manipulation, but also ssplit (I actually hadn't realized that wasn't in arc2. Yikes). Using Anarki, it should work, though.
I totally agree that strings ops are important. If I recall, PG has also said something to this effect, so I wouldn't be surprised if more of them crop up in the next few releases.
I'm on Emacs 23.0.60.2, and I haven't seen anything like this. Could you be a little more specific, so I can run tests? Are you saying that you have text in a .arc buffer, you kill it, and you can't yank it into other buffers?
No, I'm simply selecting text with the mouse in an Arc buffer and trying to paste with the middle-button in a non-emacs window such as this text area.
I've narrowed the problem down to the filename extension. Here's the test:
brian@airstream:~/temp$ cat > temp.arc
hello, world
<ctrl>-d
emacs temp.arc
Then select some text with the mouse and try and paste in a non-emacs window using the middle button. I can do this with everything but files ending in .arc !
brian@airstream:~/temp$ emacs --version
GNU Emacs 23.0.60.2
I just killed my .emacs file as a test and I get the same results, so you should be able to duplicate that if you're on Linux.
With no .emacs file, I see the following message when loading temp.arc:
File mode specification error: (error "Buffer format not recognized")
I expect that's related. Maybe we can get pg to use another extension like .arclisp :)
So it's not sufficient to add the new arc.el, you have to remove the existing association also? I would think that once a match is found in the auto-mode-alist, it wouldn't consider the other entries.
BTW I started a thread on gnu.emacs.help, but if the above fixes it, it's moot.
