Arc Forumnew | comments | leaders | submit | treef's commentslogin
8 points by treef 4705 days ago | link | parent | on: When is the next Arc-version coming out PG?

You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.


7 points by pg 4704 days ago | link

The main thing I wish someone would write is a profiler that (a) had sufficiently low overhead that it could run in production code and (b) could be installed without huge changes to ac.scm and/or the underlying MzScheme.


4 points by almkglor 4703 days ago | link

Oof. Tough. I and raymyers did some work back on a profiler when we were optimizing treeparse, but it didn't quite work well in my use-case.

Certainly it seems to involve deeper hackery skills than I seem to have right now ^^.

As an aside, it might be slightly easier to actually insert profiling code in arc2c. Each function has its own ID number in arc2c and all we need is some sort of index from ID number to original function name (given that a function in arc2c may be split by CPS conversion, so a function with a name may end up being split into several functions),


2 points by almkglor 4705 days ago | link

> You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.

Hear! Hear!


yes it is!


4 points by eds 4783 days ago | link

Please, lets not get into a "yes it is"/"no it isn't" argument here!

I am aware of some rather horrid languages that forced the use of meaningful indentation, but that doesn't make indentation evil in and of itself.

As for in Lisp, a number of people have tried to add it to Arc (including pg) without too much success. It seems that meaningful indentation lends itself much better to statement based languages than expression based ones.


3 points by treef 4783 days ago | link | parent | on: A wiki, in Arc: Arkani now on Anarki

but it is fun


classes/types? I thought arc is a language where every thing can be done in a few lines ... i cant see extra typing systems save all that much lines but just increase the complexity of the language.


4 points by nex3 4786 days ago | link

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 (, 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 4786 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 4786 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 4777 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
  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 (?!)
  arc> (all no a)  ; has-a all (?!)
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 4776 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:

    (while t
      ((afn (game-elements)
         (iflet (first . rest) game-elements
           (each e rest
             (when (overlapping first e)
               (collide first) (collide e))))
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 4784 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 4786 days ago | link

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


2 points by treef 4787 days ago | link | parent | on: Predicates: `is...' versus `...?'

i would like the * ? to be a name-marco that would expand to

   [(is (type _) '*]

   int? -> [(is (type _) 'int]
   (int? 3)


4 points by nex3 4786 days ago | link

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.


2 points by treef 4792 days ago | link | parent | on: Regular expressions

It also looks like its OO using Clos and it looks very un-arcish presenting the very hard problem with in CS - naming things - or in this case renaming things shorter.


1 point by treef 4793 days ago | link | parent | on: Arc: Table of Contents

is there any more purely arc blogs?


1 point by treef 4793 days ago | link | parent | on: Arc has no return statement?

i am learning how to write scheme compilers now it it looks like you just jump around your CCC's like GOTO labels - very fascinating and lower over head then functions calls (if you compile to machine level)


2 points by treef 4793 days ago | link | parent | on: FFI : a suggestion

There is plenty of scheme to c compilers. I would think that one could compile arc to c and have option to go lower level and code c like constructs in arc.

I much prefer pypy rpython approach though it uses rtype (like ctype) to ffi to c most of the time but during complication of rpython to c the rtypes get replace completely. I think pyrex is a bit of a dead end.


1 point by treef 4793 days ago | link | parent | on: Project Euler code repo in Arc

did you put this in the arc-wiki? I dont think i see it there! Any additional lib to arc is always good.