Arc Forumnew | comments | leaders | submitlogin
Question about "subclassing" lists
2 points by lacker 6136 days ago | 8 comments
I want to make a list that behaves exactly like a list in every way, but it counts how many times it has been mutated by scar/scdr/sref/=. (Or has some other sort of hook on being set.) I know how I would do this in an object-oriented language, but I haven't gotten enough Arc skills yet to figure this out.

Is making wrappers for scar / scdr / sref the arcish way to do this? Or is there some less invasive way I am overlooking.



4 points by almkglor 6136 days ago | link

yes, make wrappers. Might probably want to include wrappers for pr and prn too.

If you're using nex-3's arc-wiki.git (also called the "Anarki") there is a 'redef form which allows you to wrap easily.

Also, on arc-wiki there are two implementations of the same way to add a bit of OO in Arc, in lib/settable-fn.arc and lib/settable-fn2.arc. See also my series of "Create your own collection":

http://arclanguage.org/item?id=3698

http://arclanguage.org/item?id=3762

http://arclanguage.org/item?id=3858

edit: ps: some arc built-in features - function argument destructuring comes to mind - won't use the Arc redefined 'car 'cdr etc, but will use the underlying mzscheme methods, I think. Caveat Emptor!

edit2: this was my original suggestion:

http://arclanguage.org/item?id=3595

-----

1 point by lacker 6136 days ago | link

Mmm interesting series, I'll have to look it over. Thanks for the pointers!

-----

1 point by almkglor 6136 days ago | link

A bit more of some history, and why there are two implementations of what is essentially the same add-on to Arc:

My implementation (lib/settable-fn.arc) is first described here: http://arclanguage.org/item?id=3595

nex-3's alternative (lib/settable-fn2.arc) is similar to absz's suggestion here: http://arclanguage.org/item?id=3723

The difference lies mostly in what the use of the type in 'annotate is. nex-3 views this type as the "real" type, with any "claimed" (user-interface) type ducked by overloading 'isa. I view this type as the "claimed" (user-interface) type, with the "real" type being the underlying implementation (usually a function) for this.

-----

2 points by nex3 6136 days ago | link

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.

-----

2 points by almkglor 6136 days ago | link

^^; 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).

-----

4 points by nex3 6136 days ago | link

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.

-----

2 points by almkglor 6136 days ago | link

Here's another interesting bit: car and cdr could be modified into settable-fn's and their defset's could be completely removed from arc.arc ^^. Also, it should be possible to additionally modify compose to work on the '= attachments ^^.

-----

2 points by gaah 6136 days ago | link

Just saying, I've looked at Factor (http://www.factorcode.org/) and I like what little I've seen of its OO mechanism. For example, when you call add (which adds the top element of the stack to the end of a sequence underneath), it ends up calling whatever add method the sequence defines.

In Arc, this would translate into the ability to define your own sequence type, and you could have your own definitions for operations like cut within the type definition.

-----