a_strange_guy

15년 전discuss

I thought we were talking about "adding methods" to collection-like things so that they look as if they were built-in. And this was what the article was about: That it gets complex (and impossible) if you want to solve it for the general case.

It wasn't abut type-safety, just about complexity.

The problems in Scala arise, because you have to extort yourself if you want to "add a method" in the privileged position after the dot. You have to to resort to implicit conversions which are a non-composible feature. To fake composibility the author has to wade through huge piles of complexity.

These problems don't arise in Dylan at all, because there is no privileged argument position (the receiver) and you can just define methods for anything without conversions to wrappers or monkey-patching. Namespacing is done via the module system and lexical scope.

A collection-like thing in Dylan is any object where someone has implemented the required methods (first and foremost: forward-iteration-protocol). All those methods can be implemented without having access to the definition of the objects class or type, so things like native arrays (with only .length indexing and value setting as operations, akin to Java arrays) can be made collection-like.

Then you can just define your own methods for collections like filter-map, which will then work for thoose native Arrays.

If you only use the minimal collection protocol:

    define method filter-map(coll, pred :: <function>, transform :: <function>)
      let <ret-type> = type-for-copy(coll); // analogous to CanBuildFrom
      let new-coll :: <ret-type> = make(<ret-type>); // analogous to Builder
      let (init, limit, next, end?, key, elt) =
                       forward-iteration-protocol(coll);
      for (state = init then next(coll, state),
           until: end?(coll, state, limit))
        let e = elt(coll, state);
        if(pred(e))
          add!(new-coll, e));
        end if;
      end for;
      new-coll;
    end method upcase;

If map and choose (filter) are already defined (And yes; they are in terms of the collection protocol):

    define method filter-map(coll, pred :: <function>, transform :: <function>)
      map(transform, choose(pred, coll));
    end method filter-map;

Yes, I don't really like the API-design of forward-iteration-protocol. It works like iterators in Java, but is designed to not need allocation for simple indexable collections like lists and vectors etc.

a_strange_guy

15년 전discuss

I'm not Parent, but I think that this is his implementation: https://github.com/nickik/Persistent-Vector-in-Dylan/blob/ma... The last part (line 222+) is what defines it as a sequence in Dylan.

Dylan (and other multi-dispatch languages) don't have the problem of "adding methods to objects/classes", because methods are standalone entities (first-class, whereas in Scala the are not) that exist independently of the data they operate on.

so you can just "add" a method to something by defining it:

    define method upcase(s :: String) => (ret :: String)
      // code here
    end method upcase;

    "abc".upcase // => "ABC"
    // is just sugar for
    upcase("abc") // => "ABC"

so you could define 'forward-iteration-protocol (a method that returns 8 values) on anything in Dylan (built-in or not) to make it a "Sequence".

a_strange_guy

15년 전discuss

Well that is the beauty of it. In Scala methods/functions that come after the dot are privileged. In a language with multiple dispatch they are not.

So CL solves the problem without adding more complexity, whereas in Scala you have to extort yourself to shoehorn some functionality after the dot.

a_strange_guy

15년 전discuss

Of those Languages you listed, many don't have implemented function closures correctly.

Python doesn't allow you to mutate variables from enclosing scopes (by default, at least).

Ruby's blocks aren't first-class, they have to be converted to a Proc object first (and argument passing works differently than for methods).

Smalltalk blocks don't have to be able to call themselves recursively by the ANSI standard (most implementations allow that, but eg. Squeak/Pharo does not by default).

C on OSX doesn't have GC, so you have to manually specify which variables you want to capture (and how).

JavaScript was originally supposed to be Scheme, and thus has implemented lexical closures better than most other languages. ('this' however... don't want to talk about that train wreck)

a_strange_guy

15년 전discuss

this:

    func global(some_arg_to_close_over Bar) {
    	func walk_tree(node Node) {
            ...
            walk_tree(left(node))
            walk_tree(right(node))
    	}
    	walk_tree(something)
    }

a_strange_guy

15년 전discuss

This is what they want:

    func outer(a int) {
        func inner_helper(b int) {
            ...
        }
    }

Pascal allowed nested functions 40 years ago...

a_strange_guy

15년 전discuss

(1) MLs allow to nest named functions. Go only allows named global functions, and lacks a feature that Pascal had.

(2) Someone has to do cleanup anyhow. Either the caller or callee. (I am no expert in calling conventions) Anyhow, isn't this practically free, because the stack is in the L1 cache?

(3) To implement lightweight threads (ala. Erlang, Go, Stackless) you already can't allocate your activation records on the C-stack. So the main cost for call/cc is already paid for. Besides, Go lacks any form of non-local jumps, so escape continuations alone (setjmp/longjmp) would already be an improvement.

a_strange_guy

15년 전discuss

Scala is actually a really bad name for trying to google it. http://en.wikipedia.org/wiki/Scala

a_strange_guy

15년 전discuss

You don't typecheck macros since they run at compile time. You typecheck the expanded code instead.

a_strange_guy

16년 전discuss

What I still don't get is why inheritance in OO-languages is always the heavyweight version, namely subclassing.

Imho every class definition in Java-like OO languages should create two types: A (by default) public interface and a (by default) private class.

When you want to inherit from something you should then be able to choose if you want to inherit only the interface or inherit from the full class. Every good design already separates interface from implementation, so why isn't it enforced at the object system layer?

comments