Arc Forumnew | comments | leaders | submitlogin
Logical justification of polymorphism, particularly in the cases of + and *
6 points by vsingh 6131 days ago | 6 comments
Polymorphism is a useful idea, but shouldn't be used merely to reduce the number of unique identifiers in the language spec. In service of the goal of causing the language to relax to some kind of natural state, there ought to be well-founded reasoning behind the use of polymorphism in each particular case.

In #arc, we were discussing polymorphism in the function +. Currently, + can be used to either add numbers or concatenate lists. SEDfranke suggested that if we think of numbers as they were implemented in McCarthy's original Lisp - with n represented as a list of length n - then it makes some kind of sense that +, in addition to its basic functionality of concatenating lists, would also happen to add numbers. Thus our intuitive idea of the polymorphism of + is backed by logical reasoning.

If we choose to embrace this philosophy, we should take it to its logical conclusions. For example, * should compute the outer product of lists:

    (* '(1 2) '(3 4))
    ((1 3) (1 4) (2 3) (2 4))
Multiplying a list of length A with a list of length B would result in a list of length (* A B), and so if numbers were truly implemented in McCarthy fashion, the operation would actually compute the product of numbers in addition to the outer product of lists.

While we don't actually implement numbers in such an inefficient way, thinking about these issues as if we did turns out to be useful - a philosophy that pg espoused in one of his Arc essays. If we think of our language as a shadow of some Platonic ideal language, we've made our shadow just a little sharper.

In Python, when a hack conforms to the ideas surrounding the language, an elegant and organized hack, it is called 'Pythonic'. I humbly suggest that a hack that fits Arc, a messy, dirty, but mathematically clever and well-founded hack, be called 'Archonic'.

Is making * compute the outer product of lists an Archonic hack?

How else can we draw on foundational thinking to make Arc more interesting?



1 point by mdemare 6131 days ago | link

Never mind + and *, how should polymorphism work in general? Polymorphism means "several functions with the same name, dispatching on type" which implies some kind of objects.

Arc already supports a Javascript-like OO-system (probably every language with first-class functions does), maybe we should experiment with that? See if we can get Prototype running on Arc?

-----

1 point by are 6131 days ago | link

> Polymorphism means "several functions with the same name, dispatching on type" which implies some kind of objects.

I'm assuming that by "some kind of objects", you mean a user-extensible type system.

You can have multiple dispatch on function arguments (by type or even by instance) without providing user-extensible types, so it's not really "imply". Just sayin'...

-----

3 points by treeform 6131 days ago | link

i am all for stuff like this. Less symbols make it easy to remember!

-----

2 points by rkts 6131 days ago | link

And hard to understand.

-----

1 point by etfb 6131 days ago | link

The fundamental philosophy of Arc is that "hard to understand" is not an issue. It's a language for programmers who aren't afraid of learning hard things, and rarely have any trouble doing so. It's the anti-Java, if you like. So that's not really a good reason to discard the OP's idea.

-----

3 points by rkts 6131 days ago | link

I mean that it makes code hard to understand, not the language itself.

-----