Arc Forum | Arc vectors?

Arc Forum

	Arc vectors?
	2 points by tc-rucho 5587 days ago \| 9 comments
	Hi people, I was wondering if Vectors are going to be part of the Arc definition or if that will have to be implementation-dependant and what would be the way to represent it. If somehow #(...) is not good for any reason, I think {...} would be a nice notation for vectors.

1 point by conanite 5587 days ago | link

Scheme uses #n( ... ), where n is the size of the vector.

You can see it when you create a tagged object (tagged objects are represented by a scheme vector)

  arc> (annotate 'foo 'bar)
  #3(tagged foo bar)
  arc> do
  #3(tagged mac #<procedure: do>)

But you're right of course, it doesn't have to be implementation-dependent, there are lots of other options.

The big question is whether vectors are really fundamental or "just an optimisation". Hint: the use of built-in representations for numbers and strings are already considered an unfortunate compromise for the sake of performance :)

<goes away to find reference ...>

-----

1 point by tc-rucho 5587 days ago | link

Yeah, maybe they are just an optimization but they are definitely going to be present in production implementations and I think they should be standarized beforehand, and since they are already available in the underlying mzscheme, I think it shouldn't be too problematic to get vectors in Arc.

Again, I suggest {...} for vectors, since they stand out (so to avoid confusing them with lists) and because they remind of array oriented languages.

  ({a b c d} 2) => c  ;; This couldn't be better :D

-----

2 points by conanite 5587 days ago | link

I'm sure there will be heated debates about the trade-offs between the "hundred-year" aspect of arc and the need to deploy reasonably fast applications. Here are some quotes from http://www.paulgraham.com/hundred.html

"Having strings in a language seems to be a case of premature optimization."

"Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient."

So arc already deviates from the ideal minimal language; it might well deviate some more, I don't know. In a perfect world, the underlying VM should be able to figure out the most efficient implementation for each particular list you want to represent, and we would never need to bother ourselves with such details.

For comparison, "primitive types" in java are a performance compromise that (a) seriously mess up the language, and (b) are less and less relevant with each iteration of Moore's law.

Notwithstanding any of the above, I have shamelessly used

  (mac fpush (thing place) ; a very primitive, naive, fast 'push
    `(assign ,place (cons ,thing ,place)))

because the standard 'push uses 'atomic-invoke internally which slows some things down intolerably. Hence ... heated debates.

-----

2 points by shader 5586 days ago | link

I always thought the universal symbols for arrays were [], and {} were for hash tables ;)

-----

1 point by conanite 5586 days ago | link

it's true that CatDancer's hash-table syntax uses {k1 v1 k2 v2} ... http://hacks.catdancer.ws/table-reader-writer.html ... but I'm sure it's hackable so you can use alternative delimiters :)

-----

2 points by shader 5586 days ago | link

The only problem with using standard array notation for arc is that [] are already tied up for anonymous functions.

However, I think that too much syntactic sugar like this will end up damaging arc. Partly due to aesthetic reasons, but mostly due to the fact that each user has a different view on aesthetics, and adding too much will just exacerbate the "everyone has their own version" problem.

-----

1 point by CatDancer 5582 days ago | link

hmm, come to think of it, I've never used my table literal syntax {...} myself in a program. I wrote it so that I could write out and read back tables, which I use all the time, but that would work just as well with some long syntax like (literal-table k1 v1 k2 v2 ...) which doesn't use up precious syntax characters like { or #{.

-----

1 point by tc-rucho 5586 days ago | link

How about #{...} for hash tables and {...} for vectors?

-----

1 point by palsecam 5577 days ago | link

Another interesting thread on the question: "How Arc should handle vectors" http://www.arclanguage.org/item?id=1672.

-----