Arc Forumnew | comments | leaders | submit | nex3's commentslogin
2 points by nex3 5637 days ago | link | parent | on: New user: some general Arc questions

I'm sort of around-ish. I don't really do anything with Arc anymore, but I occasionally browse the forums (e.g. now). I'll certainly reply to any direct questions.

-----

2 points by nex3 5638 days ago | link | parent | on: Public Arc Git Repositories

For GitHub repos, you have to request public-push access specifically. If you're setting up a repo on your own, it's not an issue of configuration, but of how you serve it (git init --shared just affects the Unix permissions). "git daemon" comes with git and can be configured to allow public push by mucking with the configuration or starting it using "git daemon --enable=recieve-pack".

-----

1 point by nlavine 5637 days ago | link

How do you request public push access?

-----

1 point by nex3 5637 days ago | link

I went to #github on irc.freenode.net and asked defunkt. I'm not sure how often he's on these days, though, so email might be a better bet.

-----

2 points by nex3 5825 days ago | link | parent | on: Suggestion for two core features

I don't like this because then you have inconsistent behavior between types. It feels like you're saying, "If you can find something useful to do on function call, do that... otherwise just run is." Why wouldn't

  ((table) (table))
work?

-----

6 points by nex3 5825 days ago | link | parent | on: Suggestion for two core features

2 can be pretty easily accomplished using defcall from Anarki:

  (defcall int (i fn)
    (reduce (fn (f fs) f:fs) (n-of i cdr)))

-----

4 points by nex3 5825 days ago | link

Oops, stupid mistake. That should actually be

  (defcall int (i f)
    (reduce (fn (f fs) f:fs) (n-of i f)))

-----

1 point by eds 5823 days ago | link

This works, but do note that 'compose can take multiple arguments as in http://arclanguage.org/item?id=6121.

-----

7 points by nex3 5857 days ago | link | parent | on: much much better arc logo

The first thing I thought when I saw that was "snake?" Then "bouncing pac man?"

-----

2 points by tjr 5856 days ago | link

The first thing I thought of was that it spelled out "Arc", since this is a thread about Arc logos, and all... :-)

-----

2 points by nex3 5856 days ago | link

Ah, but I read from the "New Comments" view. I noticed the drawing long before I realized what thread it was in.

-----

3 points by nex3 5858 days ago | link | parent | on: Moved Anarki to GitHub

Done. Three more and folks'll have to start asking on #github.

-----

1 point by sacado 5855 days ago | link

Received it. Thanks.

-----

3 points by nex3 5858 days ago | link | parent | on: Moved Anarki to GitHub

Sent.

-----

1 point by almkglor 5858 days ago | link

Thanks. Will sign up later, have to go to work ^^

-----


There will never be a language where everything can be done in a few lines. There are just some concepts that take more than a few lines to express even in the most concise languages (see APL and descendants).

Also, as I mentioned elsewhere (http://www.arclanguage.org/item?id=4864), a properly-designed type system can do amazing things for increasing the conciseness of a language. For example, take Ruby's Enumerable mixin. This relies on an implicit has-a relationship (that the mixed-in class will define an #each method) to automatically make practically every list operation you could ever want - map, fold, zip - work on any type that it would make sense for.

In short, a well-designed type system means that objects that can act in the same way - like lists and arrays, or strings and input ports - can be manipulated with the same code. This ends up significantly decreasing the code size overall, since each function that operates on multiple types only has to be written once, rather than once for each type it uses.

-----

2 points by absz 5859 days ago | link

To be pedantic, it was proven that any program can be expressed in one line of APL (two if you need I/O).

In any case, I agree wholeheartedly: classes, if used properly, are an incredibly good way to streamline code. (Don't use them for everything, though. Then you get Java.) Ruby's mixins are actually very, very convenient, and seem to me to mesh well with Arc's approach: anything that can be cared and cdred can be mapped, too, and Arc doesn't care. But I feel like referring to this style as has-a is slightly weird, and it threw me off for quite a while. An object doesn't have-an Enumerable, it is-an Enumerable. On the other hand, an object does have-an #each method, so it does make some sort of sense.

Another advantage of combining mixins/has-a and Arc is that we get implicit mixins. In Ruby, you need to define #each and you need to include Enumerable to get all the Enumerable methods. But in Arc, since there are only functions, defining each would allow you to pass your object to all Enumerable functions (or their equivalent) without having to (include-mixin 'Enumerable 'MyType).

-----

3 points by almkglor 5859 days ago | link

My main objection is the current state of arc.arc : Every iteration construct works with lists or strings, but it won't work well with something that has 'car and 'cdr (they check by using 'acons and 'alist, which use (is (type foo) 'cons) - meaning I had to hack into 'acons and 'alist. For that matter I had to hack into 'isa too)

Generally is-a means "object is this and only this", meaning single inheritance, which was really my meaning. But a scanner isn't a cons (it's a subset of cons; it will fail on scar and scdr). It does has-a 'car and has-a 'cdr.

-----

2 points by Jesin 5849 days ago | link

I think the reason you keep saying has-a is that you're using conses as an example. A cons does has-a car and has-a cdr, but this is too restrictive. For example, say you wanted to make a type that acts like a list, that is, it supports map, each, reduce, all, rev, some, len, nthcdr, and so on.

  arc> (= a (my-listtype 'foo nil t 'bar))
  (foo nil t bar)
  arc> (car a)  ; has-a car
  foo
  arc> (cdr a)  ; has-a cdr
  (nil t bar)
  arc> (map no a)  ; has-a map (?!)
  (nil t nil nil)
  arc> (rev a)  ; has-a rev (?!)
  (bar t nil foo)
  arc> (some no a)  ; has-a some (?!)
  t
  arc> (all no a)  ; has-a all (?!)
  nil
See what I mean? (Note: I fully agree that it would be really cool if the above actually worked, I'm just arguing that the name has-a makes no sense here.)

-----

1 point by almkglor 5849 days ago | link

has-a scanner interface just means that: it has-a car and has-a cdr. 'map et al. now require an object which has-a scanner interface, and will simply use basic 'car and 'cdr operations to work. This supports genericity: just write 'map et al once, then any new type you create just needs to give 'car and 'cdr, and say it has-a scanner interface, and the existing map will work.

Now suppose we have another type, which has-a 'collide function, which handles the events where it is collided with in the game space. A ship has-a collide function, and the basic collission detection code is something like this:

  (thread
    (while t
      ((afn (game-elements)
         (iflet (first . rest) game-elements
           (each e rest
             (when (overlapping first e)
               (collide first) (collide e))))
       game-elements)))
The above now works on ships. Now suppose we add a new type of game element: a missile. We simply define its 'collide function, and declare it as having that function; now it magically works without changing the collision-detecting code.

-----

1 point by nlavine 5857 days ago | link

Agreed. This is exactly the problem that should be fixed. Your way would do it, although there are also some others.

Ironically, one great way is just to do no safety checks at all - the opposite of typing. I agree that we need something else, though.

-----

1 point by absz 5858 days ago | link

Right. I concur--it's just the name that I felt was slightly odd. The approach is a good one.

-----

4 points by nex3 5859 days ago | link | parent | on: Predicates: `is...' versus `...?'

I don't like this. I'd prefer to allow the question mark to be at the end of any predicate. It's pretty simple to define your own type predicates if you need them, but it's not possible to define other question-marked predicates if the syntax is already taken up.

-----


Oh please no! Static typing and Lisp - especially a Lisp like Arc that puts even more emphasis on being as dynamic as possible - don't mix. If we want performance improvements like this, that's what type annotations are for. Those work fine in CL for gaining performance, and integrate well into dynamic languages.

If we add Haskell's type system, we'll just end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell. That's not what anyone wants.

-----

3 points by almkglor 5859 days ago | link

Err. The idea is that these are the "type annotations" you are looking for. I never said anything about making this mandatory; it's merely the implementation layer for type annotations.

-----

More