Arc Forumnew | comments | leaders | submitlogin
2 points by tokipin 6124 days ago | link | parent

> > Simplification!? You seem confused. We have two concepts here. Using one symbol for two concepts does not combine two concepts into one.

i don't think these are distinct concepts. to me they are the exact same thing except in one case we're attaching a name to what we're making, and in the other we aren't. i can see how people familiar with lisp might see essentially 'lambda' and 'set' in the forms, but on the surface 'fn' and 'def' are very similar

i see the need for say, 'and' and the anaphoric 'aand', but to me def is so redundant with fn i actually do use that (= name (fn (x) ...)) form someone mentioned here

> > Again, overloading should be used sparingly, and only when the concepts are related in a certain way that I won't bother trying to articulate right now.

i agree, but again i don't think this is an inappropriate case. what i would like to see in Arc is something that Lua does in various places. the best example is its tables, which are simultaneously arrays, hash tables, and with its metatable system, any other structure you can think of from multiple-inheritance objects to arbitrarily-linked lists. and they act respectively depending on how they're used. eg if you use a table as an array it will iterate fast. the result is that the programmer is relieved of the details of choosing and using structures, and can instead focus on actually using them

is Lua's implementation of tables more sophisticated than arrays, hash tables, etc would have been individually? definitely. but it relieves the programmer of a lot of thought that is able to focus on something else. tables are definitely simpler than if their functionality was spread out, yet no functionality is lost compared to such a model. in fact, functionality is gained through the flexibility

by upping the sophistication underneath, a language can become simpler. if you only rely on the sort of simplicity brought about by a pure axiomatic approach, you get a sort of "assembly" simplicity. is MOV DX,8 simple? yes, but for naught

(not to blitzkrieg with text, but i thought i would explain the philosophy in one place)

> > for certain things like varargs

full varargs would be the only alteration

> > Doesn't that hurt your eyes?

yes, which is why i proposed another syntax. someone may be able to come up with something better. i use full varargs commonly so it wouldn't be easy for me to let go of the current syntax either



2 points by eds 6123 days ago | link

It is true though that whenever you overload an operator you depend on the programmer understanding more about a single operation. Thus by definition overloading increases the complexity of a language.

Please see (and refute if you like) my comment at http://arclanguage.org/item?id=5213 .

There is some significant complexity in setting a variable. Note the current existence of four (or more) different forms of 'fn: 'fn (anonymous), 'afn (capturing 'self as a local name), 'rfn (using a user defined local name), and 'def (using a user defined global name). All these forms exist for the purpose of creating functions, but they each has a different way of setting varaibles.

How do you capture that complexity if you want to start combining them into a single operation? Do you just ignore everything except 'fn and 'def and say the user can type the extra character for 'afn and 'rfn? That seems rather inconsistent.

-----

1 point by tokipin 6123 days ago | link

> > It is true though that whenever you overload an operator you depend on the programmer understanding more about a single operation. Thus by definition overloading increases the complexity of a language.

that's if we're looking at it from the perspective of the operator. but if we look at it from the perspective of an expression, i think it is simpler. to illustrate: one of the nice examples on the front page of ruby-lang.org is the following (keeping their comments):

  # Ruby knows what you
  # mean, even if you
  # want to do math on
  # an entire Array
  cities  = %w[ London
                Oslo
                Paris
                Amsterdam
                Berlin ]
  visited = %w[Berlin Oslo]
 
  puts "I still need " +
       "to visit the " +
       "following cities:",
       cities - visited
if we look at it from the perspective of the operators, we see we've overloaded + and - for non-numeric types. however, if we look at it from the perspective of the programmer as they are writing those lines, we see that the programmer just wants to say "remove the cities i've visited from the cities i have to visit," and "cities - visited" is almost a direct translation of that. it makes sense. the fact that that operator happens to be overloaded from another domain is irrelevant. the context secures the role of the operator

-----

1 point by Jesin 6118 days ago | link

There is no syntax for varargs. Destructuring argument lists are very simple and easy to understand once you understand the structure of Lisp code. What you're proposing is taking away the ability to manipulate s-expressions as they are just to free up another name that would rarely be used anyway.

-----

1 point by tokipin 6117 days ago | link

yes, i thought of it that way, but what about the dot operator? (def fun (a . b) ...) isn't called like this: (fun (1 . 2 3))

and the optional args parameter. (def fun (a (o b)) ...) isn't called like this: (fun (1 (o 2)))

and i don't see how changing the single case of varargs takes away the ability to manipulate expressions as they are. it alters it for that one case

-----