foo:bar
foo.i
foo!bar
(foo i) ; has potential problems with macro bashing though
Noncanonical but still cool stuff
given and givens
scanners
call* and defcall
I've also asked PG about strings-as-lists, which I think should be the way to go; he mentioned something vague about strings not wanting to be lists (I'll post it later when I have time). Somehow I have a gut feel that it's better that way, although we do need to have a separate character type.
> They were once but it turned out I never used this fact. The things you want to strings turn out to be different.
I don't quite understand what he was saying, I replied a follow-up on it asking him to clarify but he hasn't replied to it ^^. My assumption is it means "the things you want string to be" turn out to be different.
If a string was a linked list, the storage and processing overhead would be considerable compared to an array-based implementation with no tangible benefit - how often do you really perform a recursive process on a string or create a new string with the tail of an old string?
Probably some fuzzy thinking. 'for uses 'loop, and presumably pg was thinking that 'loop might change its characteristics (i.e. it might execute the init part more than once) in the future.
Really, there's a reason why a formal language spec (!= code) is useful...
It should be possible, in theory, to create a wrapper script that executes the arc code, but the problems are:
1. Arc-on-mzscheme startup time is slow
2. Arc-on-mzscheme doesn't support properly launching from any directory other than the installation directory.
If the above problems are fixed (or if problem 2 is fixed and you don't find problem 1 too much of a problem) we could simply use shift-V, select range, then shift-1 and type the script name.
I had been under the impression that it was supposed to last for one hundred years, not languish for one hundred years, but I suppose I might have misread something :/
arc> (= b (annotate 'bobo 23))
#3(tagged bobo 23)
arc> (* b 3)
Error: "*: expects type <number> as 1st argument, given: #3(tagged bobo 23); other arguments were: 3"
arc> (* (rep b) 3)
69
Above is Anarki, not sure about Arc2.
I'm surprised at the shortness of welder.
As an aside, I'm somewhat uncomfortable with f!show as being equivalent to f.show(), since to me ! == structure access. Still, it's perfectly valid Arc.
I'm missing something in your comment about tagged types - is rainbow doing it wrong? Arc internally uses a vector to represent tagged types afaik, but rainbow uses a custom "Tagged" class. The example you give behaves in the same way in rainbow.
> I'm surprised at the shortness of welder.
It might be cheating to use java's ui libraries - most of the hard stuff is really in there. But at least now there's a way to call all that library goodness right from arc. I'd like to abstract away everything that looks like java so that theoretically, and if we really had nothing better to do, the same arc ui library could be implemented in any other host language providing a ui.
> I'm somewhat uncomfortable with f!show as being equivalent to f.show()
I set up 'defcall so that for a java-object 'thing,
(thing 'method arg1 argn)
is equivalent to the java call
thing.method(arg1, argn);
It seemed the natural thing to do, but it's only the first version ...
> I'm missing something in your comment about tagged types - is rainbow doing it wrong? Arc internally uses a vector to represent tagged types afaik, but rainbow uses a custom "Tagged" class. The example you give behaves in the same way in rainbow.
No, I just got confused with the lack of 'rep in the call* test ^^ Sorry!
(thing!method arg1 argn) feels more natural to me, but I don't have any idea of any potential mismatch in the way java and arc works.
it's true, when you write it that way, it feels more natural. At a first glance though, this means (thing 'method) must return a method-invoker, which then gets invoked with zero or more arguments. It seems like this would add complexity - instead of calling the method, we call to get the invoker and then call it. The question, as always, is whether the increase in readability merits the increase in complexity ... we'll see what happens I suppose.
efficiency concerns! efficiency concerns! yeah yeah we don't care about efficiency, until it makes stuff 100x slower!
As an example, my ssyntaxes -hack severely slows down 'eval. And that's just part of the program. The slowdown appears to be from the arc compiler occasionally adding 'ar-eval at various points, apparently "just in case".
Possibly we can hack apart 'ac and fix the parts where 'ar-eval is randomly inserted, even though they are unnecessary (I think).
However the million dollar question of optimizing an Arc with a redefinable 'eval is the fact that Arc 'eval has TWO steps: compilation and then evaluation. Function definitions are always compiled.
For example:
; eval to make everything postfix
(redef eval (e)
(if (acons e)
(given fun (last e)
arg (cut body 0 -1)
(old `(,fun ,@arg)))
(old e)))
(t 0 5 if)
(nil 0 5 if)
But how do you handle functions?
(foo ((x)
(x
0
42
if)
fn)
set)
Do you implicitly insert 'eval to the function body, or not?
This is actually also the million-dollar semantic question. Right now, arc-eval is not inserted around function or macro bodies, so only top-level forms (those at the repl) are affected. But we can't insert it around bodies as is, because (1) Arc-side eval doesn't take an environment, but they need to pass an environment in, and (2) they don't evaluate things immediately, but instead they create the forms that will be evaluated. What is the best way to do things here? We have no other language to guide us, after all.
I'm curious: So arc-eval translates your arc code into scheme code and then passes it to scheme's eval? If so, would it be possible to print the scheme code to a file before it gets evaluated?
That could be accomplished by redefining 'arc-eval rather than 'eval. 'arc-eval is used internally for evaluating top-level forms but not really anything else since it isn't exposed to arc, whereas 'eval could be used by arbitrary arc code. If you want to redefine the top-level evaluation function, than maybe what you want is some way to influence the results of 'arc-eval.
I guess I misunderstood your intention. I thought you wanted to be able to redefine the existing toplevel used by the arc interpreter itself, not define a completely new toplevel to be used in user code... (and yes, the latter is quite trivial).
> I thought you wanted to be able to redefine the existing toplevel used by the arc interpreter itself
As opposed to emulating the existing toplevel in user code?
Allowing a redefinition of 'eval to work on the REPL will probably be OK, but still, there would be an impedance mismatch with functions that were defined before 'eval was redefined.
An interesting bit about 'givens is that it makes functional programming in an imperative style almost seamless:
(givens f (car n)
v f!v
_ (prn v) ; v isn't being set properly in some cases for some reason...
l (combinatorics f v)
_ (prn l) ; debugprint
(is l 'undef))
