true, i'm not sure why it escaped my mind. probably for a couple reasons. i use Vim, which i'm very happy with and whose editing power i'm not going to be sacrificing anytime soon. i was speaking from the perspective of a common beginner. and also i just didn't like DrScheme when i opened it up. its UI and graphics could use a lot of work
however that's just nitpicky, and DrScheme fits what beginners need. how reasonable would writing an arc language thing for it be? still, if someone had to choose between creating a DrScheme language thing and an Eclipse plugin, i think Eclipse would be the best choice
i'm sure it is very good, i was just talking about the graphical aspects of it. maybe you're referring to my mention of Vim, but i wasn't comparing. Vim is IDE-wise completely lacking, but that's something that doesn't bother me, especially due to its superior-to-all-others editing model. and the reason i say Eclipse would be a better choice is just because it's substantially prettier and more familiar
For editing text Vi and Emacs are preferred by quite a few hackers.
However for editing Scheme, DrScheme is the best choice.
Not because it is "graphical", but simply because it was designed with one purpose only: writing Scheme code.
It has all the standard stuff (such as: to show the documentation on an identifier just press F1), but
it also contain the Scheme specific stuff, that you
won't notice until you try some advanced Scheming.
Among the most impressive features is how precise the error messages are reported. This goes for both standard errors, but not the least when macros are involved. If you compare the error reports you get from a few errorneous macros in DrScheme and in a standard Scheme implementation, you'll see that you can save a lot of time if you use DrScheme.
And while at, don't forget try the macro stepper...
i like drscheme in general. there is one problem with it that made it simply unusable by me. when you hit run in drscheme to reevaluate your definitions, it obliterates my entire history in the REPL. i need to have that stuff around to retry expressions.
I'd tend to agree with your vision, almkglor. It is more generic than the other way around : the former can be modelized with the latter, but the opposite is not true. I think Arc should remain generic and thus leave us the choice.
The problem is that Arc is not currently generic enough to allow both models. Only generic functions can be implemented with the primitives we're given - the core language has to be modified to allow arbitrary attachments.
A wiki would be nice too. And I don't find currying that useful.
As for arrays, what do you think of Lua's system for arrays ? In Lua, there is no explicit array (or lists), only hash tables. However, tables can be used efficiently as arrays : a table actually consists in two fields, one for numerical indices, the other one for "regular" keys.
As long as you use numerical keys, data is actually stored in an array, so there is no performance (or memory) penalty, and since this is only an implementation issue, there is no need to add explicitly vector manipulation functions. The bonus is that, if you use a very sparse array (e.g., only positions 1, 10 and 1000000, which would lead to 999997 unused positions), you get back to the hash system. It is a little slower than separating hashes / arrays, but it saves axioms.
i love Lua's tables. after using them, other languages feel abstruse in that department, with all these alternatives that are in my mind conceptually and functionally the same thing: (key,value) pairs
[edit]it should be noted that Lua is fast, like the fastest scripting language fast
For quick prototyping I can see how Lua's tables would be extremely useful. I've been trying to think of a way to combine lisp macros with Lua tables to see how that turns out.
Less opaque error messages ! This is so painfull to have a message with no line. This is particullary boring since messages are somewhat cryptic as they can be the consequence of an unwanted macro-expansion...
Well, I was thinking that attachments would help by allowing you to attach arbitrary data to arbitrary objects ^^. e.g. line numbers to symbols and lists, so your own custom built macros can report errors at linenumbers.
That looks like a bug dealing with newlines under windows. You could try (do (readine) (readline)) to fix the problem in a first time. I don't know how it could be fixed, but maybe someone else will have an idea...
I'm not sure what you mean, do you change those in the Arc source code? I'm sort of new to all of this, just downloaded arc2 a few days ago and got this error in mzscheme on my Mac and FreeBSD box:
compile: bad syntax; function application is not allowed, because no #%app syntax transformer is bound in: (quote nil)
=== context ===
~/arc2/ac.scm:960:0: aload1
That's what my post intends to "fix", assuming that this is a problem for other people. (Fix is quoted because I don't know what functionality this would break)
The very latest mzschemes—those even more recent than 372—have switched to immutable lists instead of mutable ones; i.e. (set-car! my-lst) and the like no longer work. However, you can get mutable lists with the mcons, mcar, and mcdr operators, and this is what sacado was referring to.
