Hm. Snif. How do I apply this patch? I said patch -p1 < patch, and only garbage was found. Then I said patch -u -p1 < patch and only garbage was found. Is there anything to be found in this patch that is not garbage? LOL.
%patch -p1 < unix-patch-2.txt
patch: Only garbage was found in the patch input.
But all this is assuming you want to copy my arborescence:
arc/
3.1/ # "my" version w/ patchs
3.1orig/ # "official", ORIGinal version
3.0/
...
Maybe you'd better look at the diff and manually apply the patch. A good way to start looking at Arc guts ;-)
This was how I expected interested people to use the diff. But using `patch' directly is a good solution too :-)
Maybe you changed the tuto since that, but if not, see: http://www.arclanguage.org/item?id=9875 (that was 47 ago, on a thread when you announced new features to arc3.tar, which was then "fairly recent").
> Official Arc exists to support one app: news.arc
To erikb: yes, don't forget this important point. Sometimes Arc failed on basic stuff, because news.arc/pg's stuff doesn't need it (yet). If you're not going to accept this fact, you'd better not use Arc (or you can do even better: actually improve it to suit your needs :-)).
There is a danger in designing a language based on one's own experience of programming. But it seems more dangerous to put stuff in that you've never needed because it's thought to be a good idea.
which is wise.
> If you were to write a language to support a single app, you wouldn't need fluff like being able to run from a different working directory. [or, as palsecam put it more eloquently, Lisps in general just consider the OS is crap, and they are too "pure" to talk with it.]
I don't think this is the same idea here.
"Mine" is: you are crazy to create a general-purpose language and completely ignore the rest and the world, i.e the OS and the other programs (not written in your language). (In Common Lisp defense, it was designed at a time the OSes were more diverse & their future uncertain, etc.).
And Arc, as we said, is not so designed to be of general purpose.
And I don't think "if you were to write a language to support a single app, you wouldn't need fluff like being able to run from a different working directory" is totally correct.
You can design a language for a single purpose that would include deep cooperation with the OS. E.g: purpose is to write a language to manage firewalling rules.
thx, will try this. But how do you yourself use arc?
(Yes, on UNIX. SuSE, Debian, Ubuntu, OS X. But on Windows I would have the same question, I guess. Because it is not described in the install or tutorial text)
And how do you start a script?
in python I just do this:
$ python myscript.py
and in php it is this:
$ php myscript.php
so I would expect this:
$ arc myscript.arc
I wrote a bash script that executes this mzscheme -m -f .... stuff. But still I can't start an arc script from my shell.
It is really strange, it is such a basic stuff, but I can't find it in the install/tutorial text. Maybe there is some way that the lisp or scheme usage in common differs from the usage of other languages like python or php?
> It is really strange, it is such a basic stuff. Maybe there is some way that the lisp or scheme usage in common differs from the usage of other languages like python or php?
Absolutely true. In short, Lisps in general just consider the OS is crap, and they are too "pure" to talk with it. Hence, no easy way to start a script. Hence (also), no popularity because the majority of people live in the real world and not in the ideal lambda calculus one ^^ (this is not that bad with MzScheme or say SBCL [Common Lisp implementation] to be honest)
> But how do you yourself use arc?
Mostly dealing with the fact that it fucks the Unix philosophy, but I patched it to be a little less stupid on that. Sorry, no time now, but I'll post the patch in the near future, although it is not as sufficient as I'd like yet.
To reply more directly: nearly exclusively from the REPL.
> I patched it to be a little less stupid on that. Sorry, no time now, but I'll post the patch in the near future, although it is not as sufficient as I'd like yet.
thx guys. I will read more on arcfn.com. I am very happy that there actually is more documentation!
And I am still interested to see more information here. Are there other people out there, who have invested some energy in enhancing the usability of arc? Please tell me more!
Take a look at anarki, a community-maintained fork of arc with a bunch of enhancements (I don't know if there's a simple list of changes anywhere) ... and rainbow (an arc interpreter in java; mostly the same as arc except for access to java libs; dunno if that counts as "enhancing usability" :))
> The syntax for this each you're trying to write is suspect
> perhaps you could consider something with a more regular syntax?
You're right. The more I think about it, the less I like this 'each idea.
> All this parsing / partial compilation smacks of over-engineering.
True, but this is also part of the fun here ;-)
> For all I know about Perl (which isn't much), it looks like its foreach works with explicit and implicit variables because you can consistently parse it -- you always have parentheses delimiting the array.
You are absolutely right here, and you made me realize I am actually trying to get something more dirty/complicated than in Perl, which is... really not a good sign :-D!
> Or you could rely on the Scheme reader recognizing curly-braces as parens
This is also an interesting option. Good to know.
> Sorry I don't have any better suggestions.
Gosh, that's already a bunch of good ideas! Thanks!
Your 'every example is very very attractive. I think I'll adopt it at this point:
1. It does the job without problematic cases, like there would be in what I describe:
(with (lst '(1 2 3)
v 3)
[...]
(myidealeach v lst (prn v))) ; <-- v mistaken for the seq to traverse here,
; because it is defined
2. OK, it adds some syntax and this is bad, but for the common case where I'd like an implicit '_ variable, it's as short as possible!
3. For the other cases, the extra "in" is not so heavy, and in a way it makes the expression more readable!
Thanks a lot absz!
----
For the rest:
> anaphoric each
Yes, a good idea but I don't like to have two loop constructs where one could suffise. Currently, I'm using something like that (I have a 'each_) but this sucks IMO.
However, interesting that you choose to use 'it' and not '_'. It makes me realize, maybe it would be better if there was only one of the 2, there are a bit redundant aren't they?
(aif (car a) (prn _))
; I like this, because "_" is more visible than "it", less likely
; to be confused with a "normal" variable, and less english-centric
Or:
([* it it] 2) ; hmmm don't like that so much actually
This is pure personal taste however.
In the same way, this is also personal taste, but I mention this because an American/British people may not think about this kind of stuff.
I prefer "list?" over "alist" because anyone used to the latin alphabet will quickly understand what it does (and even this is not the majority of people...).
True story, I didn't understand what "acons", "alist" mean when I first looked at Arc (I'm French), while the Scheme way to name predicates was obvious at first sight.
> CL's loop
Ouch I'd really not copy 'loop too much however.
In a way, it is a good construct, I mean it is very powerful, but I can never remember of the syntax to do basic things, and this is why I prefer the Arc way here.
'loop is really a DSL in itself.
As for the it/_ question: I hadn't noticed until writing my post that _ and it (and self in afn) were serving similar purposes; I don't really know which one I like more, though that's not something I care heavily about. (My feeling about the English-centricity problem is that if everything else in the language is already in English---if, each, and, etc.---then changing it to _ probably wouldn't make a huge difference.)
As for the function-naming issue: I also prefer the Scheme naming convention, though not for multiple-language reasons (I'm an American [mais je peux parler Français]); that's an aspect I hadn't thought of. (The a-predicate versus anaphoric thing is already annoying.) Internationalization of programming languages is a hard problem that I don't think anybody's tried to tackle, and I'm not sure how tractable it is---it would be interesting to see a language or framework which tried to explore that design space. The obvious approach is something like
(mac si (c v f) `(if ,c ,v ,f))
(= chaque each)
; etc.
The downside is that this only internationalizes the core; any library still has to support these synonyms or have a translator, and so I'm not sure how big the eventual gain is. (I think AppleScript had this once, but since applications didn't support this, that feature died.)
In my opinion (and I've barely used CL), loop is a brilliant piece of code because it's a great little DSL for iteration; at the same time, also having simpler alternatives, e.g.each, available is really handy because that way you don't need to know everything loop can do all the time.
> then changing it to _ probably wouldn't make a huge difference
I also don't think it would be a huge difference for non-english programmers, although it may be a little win. But for my case, I don't prefer "_" just because of that. I'd say, the main reason is that "_" is more easily recognized by my parser (aka brain) as a special variable than "it" because it is an uncommon glyph. "it" gets lost in the flow of the program.
> I'm an American [mais je peux parler Français]
Now, that is not common and that is cool. I mean, not that you know how to speak French, but that you know how to speak a foreign language.
Those who know no foreign language knows nothing of their mother tongue. -- Goethe
It's not a coincidence that Larry Wall (Perl creator) studied linguistics...
> that's an aspect I hadn't thought of
Well in this case I can go to sleep happy, knowing I made you aware of something new ;-)
> a-predicate versus anaphoric thing is already annoying.
Yes! When I realized 'acons & the like were predicates, well I thought 'afn was, too...
> loop is a brilliant piece of code because it's a great little DSL for iteration; at the same time, also having simpler alternatives, e.g. each, available is really handy
Totally agreed. 'loop is something great to have as a library or something, but if it's the only way you have to do basic iteration, well, it sucks IMO. Because in top of knowing CL you have to know the 'loop stuff, which is completely different. Gosh, writing this message I realize I don't even remember how to iterate over a list while printing its elements. But yes, 'loop is extremely powerful.
Anyway, thanks once again absz, your message was really interesting to read!
Really nice that it now works with the latest version! Always problematic to depend on old stuff IMHO.
Tested on Debian (Squeeze) with MzScheme 4.1.4 (the one in the official repositories), no problem :-)
Note: don't use 'mzscheme -m -f as.scm' but just 'mzscheme -f as.scm' instead (see "how-to-run-news").
For information, the 'coerce / 2.0 integer is fixed by defining an Arc integer (exint) as (and (integer? x) (exact? x)). The bug with dotted lists in quasiquote is fixed using a new small function 'imap, that is like 'map but "don't demand '()-terminated list".
I find them quite useful for my irc bot, although I do run into the problem of not being able to @-substitute a simple variable unless it's going to be followed by something not permissible in a symbol. In particular, colons will be parsed as part of the symbol, which is a PITA. There is a workaround for this, but it's ugly:
