Well, Arc does have 'iflet, 'whenlet, etc (which are generalizations of 'aif, 'awhen, etc). As for why, I dunno, it just seems cleaner to me to, whenever you have an anaphoric macro, always have the corresponding explicit macro. It's more flexible if you do need or want to name your variables, it allows for nesting, etc.
I suppose that's true. And obviously, one could create awhile from whilet. But from a language design perspective, shouldn't there be the entire set of anaphoric operations?
(I was going to complain how whilet doesn't make sense, and isn't at all like iflet or whenlet, but then I realized whilet isn't "while t", it's "while-let" with the overlapping "le" compressed into "whilet". Well, chalk one up for pg et al. Cool name.)
Cute, but what if I wanted to use a non-atomic expression as the transforming function, or wanted to destructure the result of the function application? For example:
; this won't work, because it's not intra-symbol
arc> (dfn head ([coerce _ 'cons]:(h . tl)) h)
#<procedure: head>
arc> (head "foo")
#\f
IMO, it's generally bad to use ssyntax as anything other than an abbreviation, rather than true syntax, because as true syntax it is somewhat lacking: it can only be used as a unary or binary operator on atoms, and atoms are severely lacking in expressivity. Hence the dual nature of lisp code, which is made up of both atoms and lists. Of course, this doesn't eliminate the usefulness of macro-specific ssyntax in general, but it does make applying it "properly" (ie: as an abbreviation only) much more tedious.
I also have other reasons I dislike the notion of macro-specific ssyntax. It makes lisp code less homogenous, requires the user to remember more, and most of all binds us to the notion of ssyntax, which I find ugly in the first place - I'd rather have real syntax, implemented in the reader as opposed to the compiler/macroexpander. That way I could use the syntax anywhere with uniform meaning, and always as an abbreviation for something that I could write more explicitly.
The dot ssyntax in this case is just what the caller would have to do if the callee expected a pre-testified arg:
(some testify.ch chars)
So the choice of dot instead of colon might be better for consistency - it looks like it's just inlining existing code.
I like it less this way, personally - it looks like "testify" is somehow part of the param name, whereas with "testify:test" the two parts seem more distinct, that "testify" is something you apply to "test" before proceeding with the function. But maybe that's just subjective.
This has been discussed before. As far as I know, there is no solution to this short of making making arc an interpreter rather than an Arc-to-Scheme compiler, since mzscheme does not provide this underlying functionality.
Interesting. I remember arc2-anarki doing something very similar to this, but I don't think it went nearly this far - I think it just precompiled arc.arc to scheme code. I may take a look at seeing whether I can incorporate some of these speed improvements into arc3-anarki, but I'd rather not rely on hardcoding what files get loaded at startup, especially since anarki modifies libs.arc to autoload things in load/, which is quite useful; nor would I like to introduce reliance on Perl.
Personally I just keep an arc session running at all times from within emacs, which I keep running forever, so this doesn't impact me much, but I can see how it would be necessary to use arc for any sort of scripting. Unfortunately I'm returning to college soon, so I don't know whether I'll be able to get around to working on this.
Your choice, but I noticed the Anarki arc.sh startup script is bash-dependant, which is actually less widespread than Perl. Not totally sure, but the xBSD doesn't have it by default, where they have Perl. Perl is everywhere (even on Windows, see ActivePerl), seriously. Similarly, nearly Linux distro have it by default, where, same thing, some doesn't have bash (I'm sure of this, because I got bad surprises because of this in the past, although don't remember which ones. Can check if you want). Bash is a big fat cow.
Personal opinion, but a shell-script bash-dependant is just killing the shell-script idea. I code shell scripts when I need to be really sure any Unix will make it run, and this implies making it strictly Posix-sh compatible.
> I'd rather not rely on hardcoding what files get loaded at startup
Yes this is a big sucking point. But there is a workaround:...
> especially since anarki modifies libs.arc to autoload things in load/
... then makes it modify as(-fast).scm instead :-P. Or even libs.arc, that just would contains autoloaded stuff (and not the "core" libs).
> be necessary to use arc for any sort of scripting
Yep, but not only. Not only at all. This is related to my way of working, but I'll expose it nevertheless so that people can understand my need for fast app startups, because I know a lot of people like me. I, of course, can understand the "eternal session" stuff, I sincerely find it smart, but really, I know very few people that can stick with it (I can't). I mean, for what I know, you're really not the majority.
I'm actually OK with a script taking a long time (I sometimes like scripts to take time, it gives me the impression it's doing a lot of work and that I'm smart, I'm making the computer do the stuff :-D + allow me to pause for a second => think before typing). It's not OK when I'm in an trial/error process, but even there it's not so bad if I loose some time. Always pleasant to see the computer work, even for nothing.
But I need to spawn/terminate, spawn/terminate processes, and this is have to be quick. Because I've always at least 2 or 3 virtual desktops (eeePC, so it's not "real" vdesktops, I need nearly one vdesktop by app on this tiny screen. Change vdesktop by window, same thing), and needing to find the one in which I started the process just plainly sucks my balls (seriously; even if it takes 2 secs: useless stuff, waste of time). Say for a terminal, I just hit ctrl-shift-enter, a new xterm is spawn in 0.1 sec and I can do what I have to do right now. Same for my web browser, which is Conkeror (or Chrome on Windows but same here, because it starts very quickly), and can be launched in daemon mode so that when you call it, it's there in < 1 sec (and this is why I can't consider the fat Firefox). Same for everything, or should be. For instance, I actually plan to learn vim because Emacs is too long to start. I plan to drop bash, because with the smart completion feature, it's not instant to start and for a shell this is just a sin.
I'm a big procrastinator, and when I want to do some work, this is not often, and if the computer makes it difficult (slow to start), well I come back to procrastinate. Seriously. Even 1 sec can suffise. And this bugs me a lot, because computers nowadays, WTH they've got GHz of power, this should not happen.
I insistate on all this not because I think this is the right way, but because you (I mean, not you rntz personally, I mean people in general) are crazy to ignore this.
Yes, 0.1 sec makes a difference. I'm sure you know about the Google experiment to try to load x * 2 instead of x (don't remember the exact numbers) results by page, the load time increase was something as insignifiant as +0.1 sec, and they actually loose a real % of customers. (If you don't know about this XP, tell me, will go seek for the link, it's very very interesting). People - just - respond - to - speed. I already said that, but Google made his fucking huge empire based merely on this single point. And they continue to expand their empire applying this recipe (Chrome, Google OS which, I bet everything on this, will be 10x faster to start than Ubuntu, GMail on mobile that just indicates "Download GMail for your mobile - it's blazing fast", etc.)
So, but if you think Google is crap, you're crazy to ignore the speed issues.
FTR, if an app can't be fast, good solutions include applications that would not allow multiple-instances, but will come back in focus when called again. Another good thing is, for terminal, tilda/yakuake. Another interesting idea is a client/server idea, where the client is lightweight where the server, launched as a daemon, is long to start (the evsrv started with this idea).
Last point, eternal session is good, but if this means you keep your personal computer on for days, you're just killing the planet, and this obviously sucks. There is this old maxim "Don't waste, even cheap ressources like computer power/electricity, but to not waste human brain power". Gosh I was reading lately how Amazon was applying this, to the point where they removed the light bulbs from their snack distributors, because they're basically useless. Same thing, Amazon is a giant now, so don't think this is stupid (funny story, Amazon also communicated lately on how 200ms (!) of extra latency makes them loose lots of money).
> Your choice, but I noticed the Anarki arc.sh startup script is bash-dependant, which is actually less widespread than Perl.
Good catch. I've changed arc.sh so that it should be POSIX sh compliant, but I'm unsure precisely what this requires and don't have the patience to devour the entire spec at the moment. I've tested it against bash and dash thus far. You can give it a look over at http://github.com/nex3/arc/blob/master/arc.sh if you want.
> Last point, eternal session is good, but if this means you keep your personal
computer on for days, you're just killing the planet, and this obviously sucks.
I'd be interested to see an actual comparison of the time it takes to parse some example files with the two different versions of 'whitespace?. Why use microbenchmarks when you can test on real-world examples?
> One difference: 'faster-in returns the found value, rather than 't.
What if that value is nil? That makes for a nasty corner case.
What if that value is nil? That makes for a nasty corner case.
oops, yes, you're right, good point
Why use microbenchmarks
using parser.arc to index tokens from arc.arc is the benchmark I use most often for tuning rainbow performance. I wanted to present the issue with as few extraneous details as possible.
Micro benchmarks can be misleading sometimes. Most of the time I get different timings for the same microbenchmark when I eval it a few times so it's really difficult to see if they really do their job when the timings are too close unless some full blown benchmark is performed on some real data.
Sorry I don't come back on the "want to see if it works on the wild before". I'll certainly show the source, even if it doesn't (work on the wild), but please wait.
Plus, hmmm, did you even bother trying it? You may have chosen another username, but:
arc> (user->repl* "rntz")
nil
If you have chosen another username, OK, no problem (but I can't guess). If you've not tried it, your choice, but then I'll parse your request as "Gosh palsecam is such a moron, an REPL on the browser has no future[1], performance/privacy issue, blahblahblah, but I'll be glad to steal his code for another more useful purpose that I'll not communicate about".
I am, at least I hope, certainly wrong on my analysis, but sorry, that's how I read your message.
And obviously, I don't like to be taken for a moron. And obviously, I don't like this kind of "stealing".
------
1: I'm sure some people think this. They might be right, but this kind of reasoning also lead to "GMail/... has no future", which was proved to be wrong.
I don't know if I'll seriously keep on working on the evsrv, but I can think of lots of good features that being web-based would enabled.
rntz, if you think this is a stupid idea, I have no problem with this, but then tell us about the (better) idea for which you'd like to use the code.
It's true I don't (well, didn't) have an account on the eval server. I didn't really feel the need to try it, not because I think it's crap, but because... well, it's a persistent REPL on the web. That's most of what I need to know, really, and if I ever need a persistent web-based REPL I'll know where to go - I trust it to be everything you say it is (and now that I've looked at it, it is; and it's swanky to boot). Just because I don't yet have a use for a thing doesn't mean I think it's crap. Hell, I don't yet have a "real" use for Arc itself beyond just playing with it as a sort of language sandbox - I haven't even tried firing up the webserver that comes with it! Does that mean I think arc or the arc webserver is crap? Hell no.
I have no intention of stealing your code. If you don't want to share your code, then don't; I tend to assume that Arc-related stuff will be open-source simply because it's common. And if you do share your code, I won't use it for some private purpose that "I'll not communicate about"; I'd share it back. That's how open source works.
The reason why I asked to see the source, despite you noting that you didn't intend to release it until testing it in the wild, was because I imagined (as CatDancer seems to have surmised) that the reason you didn't release it was because you weren't satisfied with its quality yet; hence the comment about "even if it has bugs or scalability issues or whatever".
The reason why I want to see your code is not, then, because I think you've done a bad job - how could I? As you noted, I hadn't even tried it when I made the post. Rather, I'd like to see it because in order to implement it, you have to have done some cool stuff (for example, AJAX, and some way of maintaining a persistent REPL) in arc that I would find instructive to read and possibly useful in the future. I don't ask with a purpose already in mind, but rather to learn; that's why I'm using Arc in the first place.
> Does that mean I think [...] the arc webserver is crap? Hell no
Actually, on some points it is (IMHO of course) ;-D
> I won't use it for some private purpose that "I'll not communicate about"; I'd share it back. That's how open source works.
Sadly everyone is not as honest as you :-/ I've met some people not understanding what FOSS is about, and being big bitches about it, so I'm now more suspicious than I used to be.
But this is no excuse, I was not right to emit judgements about you based on my past experiences.
> weren't satisfied with its quality yet
Yep, was/is the case, see last item on the TODO list (in evsrv.arc)
> some cool stuff (for example, AJAX
Actually, nothing cool or magic about Ajax. It's just sugar (here).
> some way of maintaining a persistent REPL)
More magic here :-) Although it is just because of MzScheme being a very good language, and having namespaces and sandboxes.
> I don't ask with a purpose already in mind, but rather to learn
The noblest of all purposes ;-)
Once again sorry for misinterpreted and being quite rude with you.
I think I may be able to clear up a bit of confusion here.
All (almost all?) of the code related to Arc so far has been released as open source by various authors, including rntz's extensive work with Anarki.
Thus when code hasn't been released, it's been because the author doesn't think it's good enough yet, instead of because the author wants to keep it proprietary.
So when one of us sees something cool, it's not uncommon for us to say, "oooh, we'd like to see the source to that!" Not as a request to give away something proprietary, but to say that if someone has code that they'll be making open source anyway, to encourage them to go ahead and release it, because it looks cool.
I'm pretty sure it was a statement of curiosity. I'd venture to say that that's the intention most of us would have in asking to see the source. (Hell, I'd be interested in seeing it.) You're probably reading too much into this.
(Plus, it's not really "stealing" if you willingly share the code.)
1. I don't know how you'd do graphics with arc in general, but if you need to access mzscheme, anarki can do so very easily. If you want to access a scheme function named 'foo, just write ($ foo), or abbreviated, $.foo.
$ git clone git://github.com/nex3/arc.git
$ cd arc
$ ./arc.sh
Welcome to MzScheme v4.2.1 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
Use (quit) or ^D to quit, (tl) to return here after an interrupt.
arc>
(This is assuming you're on Linux. I don't know how one would go about setting up anarki on Windows or OS X.)
2. If I understand it correctly, mzc doesn't compile to native code; it just wraps everything up in a neat executable containing the mzscheme binary and the byte-compiled scheme code. There was some discussion earlier about getting mzc to work with arc: http://arclanguage.org/item?id=10157.
3. I haven't looked at picolisp. I do not think that a C implementation/hooks are particularly a long-term goal of arc, especially considering Arc is intended to be the "100-year language", although design decision are of course pg and rtm's domain. However, arc is built on top of mzscheme, and mzcheme has a C FFI I believe, so setting up arc to hook into C should not be impossible.
