Good call. Not necessarily want to use showpos.. its main advantage right now is that it nicely returns nil when I try to read any out-of-bound position.
I guess without showpos I could grab the appropriate rows from world and discard the first X and last Y positions.
From here on I adapted the function to the one I really needed (do something if one of the 8 neighbours of posx, posy is X). Because of that requirement it seemed easier to just gather the row - 1 and row + 1 and the row, col - 1 and row, col + 1, and join those in a list. This is what it ended up as:
(if (find X (flat:map [join (errsafe (world _))] (list (- row 1) (+ row 1) (- col 1) (+ col 1))))
; do stuff
)
That's true. Programming languages take years to evolve, not months. Moreover, Arc is in the language design phase. As of today, the syntax and the semantics of the language are more important than libraries. For example, I'd like to see something like Kenny Tilton's cells (http://github.com/stefano/cells-doc/) nicely integrated within the core language.
Is it in the language design phase? Does anyone know if this is in fact true, and if so, what is currently being designed? The impression I have is that it just sort of stopped.
I would suppose that since a) this language is not used in anything "important" yet, and b) it's open source; yes, it can be in the design phase. I should think that the design phase persists until, for some reason, the language becomes "formalized", or until it is impossible to change anything major without ruining things for a lot of people. At that point you can still "design" the language, but since it has a generally understood "style" and so forth, it won't be able to change too much unless you make a whole new language.
What do you want to be designed? One of the major problems about "designing" a new lisp is that, since anyone can "do it" in their spare time, they don't see the point. Maybe they're right. ^^
Sorry for all of the quotes; it looks kind of funny, I'm sure.
Ah.. but here PG is wondering into the opposite direction of what eekee is, if I understand correctly.. PG seems to be favoring the following distinction:
is .. checks if a is the same thing as b (like pointers referring to the same address in memory).
iso .. checks if the content at whatever a is pointing at is the same as whatever b is pointing at.
which is now violated by strings. I am not sure how numbers fit into this. In general I would favor the more commonly used 'has the same content as' to be is, and 'refers to the same entity' to be iso for brevity reasons.
But isn't iso short for isomorphic which, as I understand it, is the same as "these two things are equivalent" - which maps much more closely to "has the same content as," not "refers to the same entity"?
Which is a bit hard not to know.. I mean, in order to install Arc you have to install scheme.. and the install link right next to the tutorial link makes that clear.
Yes: a code-walker interpreter with dynamic lookup can implement lexical scope, provided you don't pass functions around (on the interpreted-language side).
If you do pass functions around though, you need to keep separate slightly-different versions of the environment variable, and attach those to the functions you pass around on the interpreted-language side.
Arc is desinged as a practical language, and as such it is not built on any pure primitives. PG had, at one point, taken such an approach, but abandoned it because of poor performance.
It calls many mzscheme functions to run, most of them not primitive. Primitives, as far as they exist, are defined in ac.scm. They are not simple, however- Instead, the emphasis is on keeping the language implementation simple and reasonably efficient.
> Arc is desinged as a practical language, and as such it is not built on any pure primitives. PG had, at one point, taken such an approach, but abandoned it because of poor performance.
Personally I'm retaking this approach, and doing some trickery on the scheme side to improve performance. So far what I've been doing is only slightly slower than Anarki (within sampling variation, although the average times are slightly higher).
also noticed that the difference isn't that large as the racing car seemed to suggest. Chrome's javascript has about the same performance as Opera's right now. We'll see how it develops.
Hah. someome made ruby run on v8 and made a small benchmark of it. Interesting:
I am not sure what the consequences are for possible implementations, but preferrably, I would want to be able to use regexps in (find or (keep, or (findsubseq just as easily as I would now use strings or functions
(keep odd (list 1 2 3 4))
(keep (reg /nan/) (list "banana" "bonobo" "bandanga"))
(findsubseq (reg /\d+:\d+/) "The current time is 10:00 am")
When looking at http://arcfn.com/doc/string.html , there is an aweful lot of restrictions on when we can use variables, or functions as arguments, so maybe a lot of the string operations in there become obsolete if there is a regexp engine in arc.
@rincewind - nice one. (apply + is indeed one of the most obvious improvements I should familiarize myself. Familiar with it in ruby (inject), but in combination with recursions, I fell back to the simpler (with. acons is a good pointer as well for me.
@drcode - solution: "try to take the average of each element in a list. If that doesn't work, return the element". Didn't know about avg, which is an obvious improvement. errsafe and or are whole new operators to me, which are going to be interesting to try and learn to use. Nice!.
@skenney26 - might still be a bit too difficult for me.. the function rec takes 3 arguments (an operator, a base whose purpose I'm not sure of, and the list). rec creates an internal function called 'r'. If xs is an atom (i.e., not a list) then 'r' returns (base xs), otherwise it maps, calling r recursively.
Ok. think I get what base is for :).. it allows you to modify the numbers before you subject them to f. Nice!
Actually, I'm with you on rec. Even after writing it my head was struggling to fully understand it. Complex recursion is tough to grasp; i wish there was a way of visualizing recursive calls that was similar to expanding a macro. Does anyone know if there's a way of doing that?
You can't use "foo(bar)" to call foo on bar in arc, you have to say "(foo bar)". Interpreting "dot((list 0 -1 1) 0.3 0.3)", Arc first evaluates 'dot (doing nothing) and then evaluates ((list 0 -1 1) 0.3 0.3), which calls the newly created list '(0 -1 1) on the two arguments 0.3 and 0.3, which in turn causes an error because it's trying to get the 0.3rd element from the list, which makes no sense. (Also it's been given two arguments when it expects only one.) This is a case of Arc not having very informative error messages.
Also, I think there's an error in the 'dot function, as you use a '+ where it will do nothing. Arc has no infix math, so what you want is something like this:
