The Arc Forum has worked on-and-off for me for a while now, have either of you had that issue? Anyways, I'll repost what I was trying to say: What I mean is that it should be possible to determine what a variable refers to just by using the source code. Using lexically-scoped functions, this is possible. But globals are dynamic (they might be overwritten later) so this is not possible. What I mean is that if you have this piece of code: ; library1 (def foo (x) (+ x 5)) (def bar (x) (foo x)) ; library2 (import library1) (def foo (x) (+ x 10)) (bar 15) That last call to "bar" should return 20, not 25. Because it uses the "foo" that's defined *in its lexical scope*. What I am describing is this: http://c2.com/cgi/wiki?HyperStaticGlobalEnvironment --- "If what you want is first-class namespace support [...]" No. I don't care whether the namespaces are first-class or not. In my view of lexical global scope, everything is evaluated in one giant namespace. But because of lexical scoping, it all works out. This technique is equally applicable in static languages like Racket that don't have (easy access to) first-class namespaces and dynamic vau-based languages that have first-class environments. --- "[...] or selective importing, that's different." Selective importing is *useful* and is possible in my lexically-scoped system. But it isn't *necessary* to make variables lexical.
> The Arc Forum has worked on-and-off for me for a while now, have > either of you had that issue? Absolutely; I'm glad I'm not the only one. Couple of times I've bugged PG to say the site was down when it wasn't. I suspect now that PG has its requests/ip* on a hair trigger to maximize resources to HN. But I was also suspicious it might be something about my router at home, so good to know. Many's the time I've had to ssh in to my server and paste in a comment over a text-mode browser. Not a good time. http://knowyourmeme.com/memes/super-cool-ski-instructor
> ; library1 > (def foo (x) (+ x 5)) > (def bar (x) (foo x)) > > ; library2 > (import library1) > (def foo (x) (+ x 10)) > (bar 15) > > That last call to "bar" should return 20, not 25. Because it uses the > "foo" that's defined *in its lexical scope*. Ah, I see. What if there's no bar defined in library1? What if it's coming from yet another library?
If "bar" isn't defined it throws the usual "undefined variable" error. If it's defined in a different library, whichever one defines it last "wins". But unlike in Arc where it would overwrite the previous value, it simply shadows it. That's where selective imports are useful. In fact, here's a copy-paste of my current notes: --- Nulan uses a Hyper Static Global Environment (http://c2.com/cgi/wiki?HyperStaticGlobalEnvironment) I prefer to just call it "lexical scope". In this thread (http://lambda-the-ultimate.org/node/3991#comment-60418) some questions were raised about how well a namespace system handles various semi-contrived situations. Let's see how well Nulan does. --- > Two libraries are released that, for whatever reason, use the same namespace > and have name collisions. Both libraries are for some reason amazingly > useful, and I'd like to use both in an application. How does the namespace > system handle this? (import library1) (import library2) ... And if library2 overwrites something in library1 that you want to use, you can do... (import library1) (exclude {foo bar qux} (import library2)) And now you're using library1's version of foo, bar, and qux. --- > Now I'm writing a piece of code that uses two libraries, each of which use > different, incompatible versions of some third library, causing namespace > collisions between the two versions. How does the namespace system handle > this? (import library1) (import library2) ... --- > At some point, two popular libraries with related functionality get tired of > duplicating effort, so they collaborate to produce a third library providing > the best of the shared features. To avoid unnecessarily breaking client code > with the new versions, they'd like the new library to be able to occupy both > original namespaces, or otherwise be easily substituted in. How would the > namespace system handle this? (import library3) ... --- > Another popular library has some developers leave over a dispute regarding > open-source licensing (apparently, the license text of the original library > ended sentences with prepositions and there was no consensus on relicensing > to "correct the grammar") and produce their own reimplementation of the > shared library. They'd like it to be a drop-in replacement for the other. > The interface and functionality is the same, backed up by a huge suite of > unit tests checking for identical behavior between corresponding functions. > An application I'm working on uses two libraries, one of which requires the > replacement library. The other library has no opinion on preposition > placement, and uses the original basically by default, but could work with > the replacement. Does the namespace system give me any means to easily > reconcile this? # library1 (import replacement) ... # library2 (import original) # this could instead import replacement ... # application (import library1) (import library2) ... --- > That is, importing a package should only introduce the names that library > explicitly exports. This prevents you from importing the package's > dependencies, and avoids unnecessary conflict. Unnecessary due to lexical global scope, but not hard to add in to the namespace system if desired. --- > Additionally, you should be able to control the names you import (i.e. via > 'import org.blog.whatever as W' or 'import foo (x y z)' such that someone > adding a new export to an existing library will not affect the meaning of > the code that uses it. Usually unnecessary, but if needed you can do: (include {foo bar qux} (import library)) You can also rename exports from the library: (include {foo = bar qux = corge} (import library)) The above imports foo/qux but renames them to bar/corge. The renaming is lexical: in the library, the names are unchanged.
*Totally* post this comment when you get a chance.
> Nulan uses a Hyper Static Global Environment > (http://c2.com/cgi/wiki?HyperStaticGlobalEnvironment) > > I prefer to just call it "lexical scope". I dunno, that terminology might be hindering you in getting the point across, if Ross and I are anything to go by..
I don't think so. I think it's correct and accurate. From working with Nulan, I've come to the conclusion that there's no difference between the global scope and function scope. The only difference is that function variables are private to the function. But it's easy to create non-function variables that are private. So I see the distinction between private/public as being orthogonal to the distinction between lexical/dynamic. And from what I can see, the current dynamic global scopes found in most languages behave basically exactly like how function scope used to behave in dynamically-scoped Lisps. So I think calling it "dynamic globals" is correct. And the global scope I'm describing behaves exactly like the lexical scope of functions, so I think calling it "lexical globals" is correct. In particular, with "lexical globals" things can only depend upon variables that are defined before the point that uses them: it's possible to determine from the source code what a variable refers to. Isn't that the definition of lexical? Whereas "dynamic scope" means that what the variables refer to changes depending on the runtime.
> I don't think so. I think it's correct and accurate. Notice that I didn't disagree with you. I can't because I don't understand what you're saying (haven't digested your mail yet). Even if the terminology is correct, using it without clarifying how it's correct hinders understanding. So in the normal scheme of things you'd have to describe it and name it at the end. And then we'd talk about it again and you'd have to go through the same lengthy explanation again for somebody who didn't see the original. Names don't always make sense; they're sensitive to initial conditions; we gotta pick our battles.
Sure. But what would you suggest I call it if not "lexical globals"? Especially because "lexical globals" has an analog with "lexical functions". As for having to explain things again... isn't that what forums and such are for? A collection of thoughts that later people can return to to gain knowledge that was posted in the past? I do plan to spruce things up and post something that explains all this in a hopefully understandable manner. But you're right of course that right now, most people see "lexical" and "global" as opposites because they think in terms of "lexical functions" which exclusively use local variables. Overcoming that hurdle will be hard, but I think it's useful to split the concepts of local/global and lexical/dynamic, even if it goes against the traditions. As for describing it and naming it at the end... that's a good technique, I'll try to keep that in mind. It may be difficult if I have to actually refer to the concept multiple times, but I'll try to figure something out.
> Sure. But what would you suggest I call it if not "lexical globals"? Ross's phrasing "module local" seemed crystal clear, speaking for myself. I'm starting to see your framework for these names, and it is indeed a nice consistent framework. It would be very valuable in a large blog post or a book, even.
I think the issue with "module local" is that the word "module" isn't particularly well defined. Some people think that namespace == module. Other people might say that file == module. Or folder == module. So now you have to define what a module *is*. For the people who think namespace == module, they'll get tripped up when I talk about evaluating everything in a giant global namespace. For the people who think file == module, they'll get tripped up when I explain that Nulan doesn't have late binding. And uh, I don't really know what to say about people who think folder == module. Anyways, that terminology is fine as long as you define what a module is. --- As for consistency, thanks. I value consistency. So I try to think in consistent ways. And yes, I plan to put up a fairly long post about this later. Not a book, though, I'm not a fan of wasting paper. Nor charging people to read something that should be available for free.
> Anyways, that terminology is fine as long as you define what a module is. Apples to apples, without accompanying clarification in either case, it seems less of a hindrance. But you should get more sample points :)
> Not a book, though, I'm not a fan of wasting paper. Nor > charging people to read something that should be available for free. Will we stop having books when everything's read on a flexible e-ink display? Are free pdfs of books not books? :) I was just thinking about this yesterday. Subjectively a 'book' for me has to do neither with medium nor, immediately, with length. It's more about a commitment to finish something when I start reading it. In practice it does have to do with length. You start out reading somebody and they make enough of an impression on you that you're willing to invest attention on longer posts, where the payoff is less immediately apparent. Things like blog posts titled "mystery machine bus". Somewhere on that fuzzy continuum it stops being a 'post' and becomes a 'book'. But perhaps these labels will fade over time.
Considering we've used the word "book" exclusively for paper-bound... well... books... Before books we would have used the word "scroll" or "parchment" or "manuscript" or similar. "Manuscript" in particular is quite general: it simply means something that is manually written. But sure, if you want you can call all written material (whether digital or not) a "book". I won't fight you on that one.
Actually scrolls were called books too, back in the day. The invention of the folio was a major breakthrough.
Really? I didn't know that. In any case, we *do* need a word to describe "lengthy amounts of written material" and I suppose book is as good a word as any.
> I see the distinction between private/public as being orthogonal to the
> distinction between lexical/dynamic.
Completely agree. A languages textbook I once read distinguished between variable scope and lifetime, which I think covers these axes.
> In particular, with "lexical globals" things can only depend upon
> variables that are defined before the point that uses them: it's
> possible to determine from the source code what a variable refers to.
> Isn't that the definition of lexical? Whereas "dynamic scope" means
> that what the variables refer to changes depending on the runtime.
I think the word 'lexical' shortcircuits my brain because I expect block delimiters to say where the 'lexical' ends. That might be the case for others as well. Relying on ordering of top-level forms for a variable definition seems different enough from scanning unindented lines that it seems worth having different names.
More specifically to my own idiosyncratic opinions, I think relying on ordering of top-level forms is a terrible idea. I *like* being able to do this in wart:
def (foo x)
Global.x
<- Global (table)
"I think the word 'lexical' shortcircuits my brain because I expect block delimiters to say where the 'lexical' ends. That might be the case for others as well. Relying on ordering of top-level forms for a variable definition seems different enough from scanning unindented lines that it seems worth having different names." Okay, fair enough, though I don't really know of a better word. Static globals, maybe? That emphasizes the fact that they don't change, which isn't *quite* correct because they can change... but if it helps you to understand, then great. --- Racket uses an interesting hybrid where *inside* a module the variables are dynamic, but outside of a module they're lexical. That would let you use your example while still retaining all the advantages of lexical scope. Personally I don't like that, but it doesn't *necessarily* conflict with lexical scope. It does mean you need to define what a lexical scope *is*. Nulan basically uses the idea that, each top-level form creates a new lexical scope. Racket says that an entire module creates a new lexical scope. You could also potentially say that multiple files would create a new lexical scope, etc. On the extreme end, you could say that "every file ever" creates a new lexical scope. Which, incidentally, is the strategy that Arc and JavaScript have, and is equivalent to dynamic scope. So what we're really discussing is how fine-grained the global scope should be. Arc/JavaScript say that the global scope should be all-encompassing. Racket says the scope should be limited to a module. Nulan says the scope should be limited to a top-level form. Functions let you restrict the scope even further by introducing private local variables, etc.
> Racket uses an interesting hybrid where *inside* a module the > variables are dynamic, but outside of a module they're lexical. That > would let you use your example while still retaining all the > advantages of lexical scope. I didn't know this! I've also had a *lot* of trouble grokking racket modules.
Racket's namespace system is *almost* perfect: you don't need to prefix any names. It's lexical, so there's no issues with overwriting things. You can selectively choose which names to import and which to export. There's not *that* much boilerplate, etc. My problems with Racket's namespaces... by default they export nothing so you have to say this: (provide (all-defined-out)) Ew boilerplate. Also, you can't assign to a variable that's defined in another module. In other words, if a module defines a variable "foo", you can't do (set! foo ...) instead, you have to jump through some hoops and such. Also, I found it incredibly hard to write modules that "inverted control". Normally you have a module that imports another module. This creates a nested hierarchy: your module can use the stuff that you import, but the imported module can't use your stuff. In other words, it's hard to create circular modules, or modules that can rely on what imported them. Also Racket's modules (like most things in Racket) have this very rigid and constrained flavor to them. I prefer dynamic and flexible things, which is why I love Arc. So I think if you basically took Racket's namespaces, simplified them, fixed a couple issues, and made them more dynamicy, they'd be basically perfect.
> http://lambda-the-ultimate.org/node/3991#comment-60418 Oh, that thread is *awesome*, thanks. It's helped enrich some questions I've had for a couple of years: http://arclanguage.org/item?id=12777
Pauan, when you show code examples that demonstrate how you'd deal with certain library dependency corner cases in Nulan, are you considering that the application developer can't go in and change the code of the existing libraries? If they could, they could simply rename variables and it wouldn't really matter what namespace features the language provided. For instance, when they say "two libraries ... use the same namespace," I assume the code can't look like "(import library1) (import library2)" because the libraries don't have those two separate names. I'm the one who told you about the wonderfulness of hyper-static global environments, but I think lexical scope is too vague. If you consider the whole program to be a single expression where each top-level form is nested inside all the ones above, then hyper-static scope might become the same thing as lexical scope, but I think that crosses a line of intuition. --- Pauan: "*[...] it's possible to determine from the source code what a variable refers to. Isn't that the definition of lexical?*" I would call that "static" scope. Maybe even "hyper-static" just to make it clear where we got the idea for this particular kind of static scope. --- Pauan: "*[...]I think it's useful to split the concepts of local/global and lexical/dynamic, even if it goes against the traditions.*" You're still alluding to the common definitions of those words; I don't see any other justification for using those particular words rather than coining new ones. Since you are making a point related to the common definitions, but you're intentionally overloading the terms in order to make that point, it's probably best to make that explicit at least once per thread. (If you can manage to describe it in terms of a link to a previous description, that's okay, but don't expect the reader to carefully read every single thing behind that link either.) --- "*I see the distinction between private/public as being orthogonal to the distinction between lexical/dynamic.*" I don't see lexical and dynamic as being opposites. The two kinds of locality are neither exhaustive nor mutually exclusive, and when "dynamic" means "usage and definition sites not statically matchable," they're not even descriptions in the same category. --- "*Racket uses an interesting hybrid where* inside *a module the variables are dynamic, but outside of a module they're lexical.*" I still don't understand this at all, sorry. XD
"Pauan, when you show code examples that demonstrate how you'd deal with certain library dependency corner cases in Nulan, are you considering that the application developer can't go in and change the code of the existing libraries?" Yes, definitely. --- "For instance, when they say "two libraries ... use the same namespace," I assume the code can't look like "(import library1) (import library2)" because the libraries don't have those two separate names." That's the point of lexical scoping: they can use the same names and not collide with eachother. --- "I'm the one who told you about the wonderfulness of hyper-static global environments [...]" Yeah you probably did. I end up frequently dismissing your ideas only to come around to them (much) later. --- "[...] but I think lexical scope is too vague." Yes as I discussed earlier, "lexical scope" can mean multiple things. Racket's modules have lexical scope but the scope is defined at the module level. Hyper-static global environments (like in Nulan) have lexical scope at the expression level. I think Racket's modules are perfectly fine, excluding a few issues, so I don't see a problem with calling it "lexical scope". The point isn't which particular lexical scope strategy you use, the point is that you use lexical scope *at all*. Using any lexical scope is probably better than dynamic scope. I do prefer Nulan's hyper-static global scope though. --- "If you consider the whole program to be a single expression where each top-level form is nested inside all the ones above, then hyper-static scope might become the same thing as lexical scope, but I think that crosses a line of intuition." I see hyper-static global scope as being a particular *kind* of lexical scope. I think the only requirement of lexical scope is that it is possible to determine from the source code what the variables refer to. After all, that's why it's called *lexical* scope: lexical is referring to the source code. --- "I would call that "static" scope. Maybe even "hyper-static" just to make it clear where we got the idea for this particular kind of static scope." I discussed with akkartik earlier about calling them "static globals" but I dislike that because it makes it seem that the variables are immutable. And the phrase "lexical scope" already exists and already has the meaning we want: that variables can be inferred from the source code. In any case, I don't really care that much WHAT we call it, just so long as we can agree on what to call it. The phrase "lexical scope" already exists for functions, so I used that, but "static scope" is fine too, as long as its understood that the "staticness" refers to what the variables refer to, and not whether the variables are immutable or not. --- "You're still alluding to the common definitions of those words; I don't see any other justification for using those particular words rather than coining new ones." Ah yes, the good old tradition vs new words argument. As I pointed out a while back with Nulan, I'm fine with coining new words when I feel the existing words are lacking. The justification for using the phrase "lexical scope" is that it already has the meaning I want and it is well known. I'm fine with any suitable alternative: it's just words after all. --- "Since you are making a point related to the common definitions, but you're intentionally overloading the terms in order to make that point" I fail to see how I'm overloading it. I think that, like akkartik, you still think of "lexical scope" as pertaining *only* to functions. I think that's a bad way of looking at it. The strategy you use to lookup a variable is different from whether the variable is local or global. I'm simply taking the already-existing strategy of lexical scoped functions and applying it to global scope. I don't see that as overloading at all. --- "it's probably best to make that explicit at least once per thread. (If you can manage to describe it in terms of a link to a previous description, that's okay, but don't expect the reader to carefully read every single thing behind that link either.)" Sure. But I feel that no matter WHAT word I choose, there are going to be people who resist it because the idea ITSELF is somewhat new and unexplored (in mainstream languages). I'd rather just describe what it is and say, "this is lexical scope, and I'm calling it lexical scope because it behaves exactly like the lexical scope of functions". But as said, I don't care what we call it, as long as we can agree on what it is. And "hyper-static global environment" is too long for my tastes. --- "I don't see lexical and dynamic as being opposites. The two kinds of locality are neither exhaustive nor mutually exclusive, and when "dynamic" means "usage and definition sites not statically matchable," they're not even descriptions in the same category." I never said they were opposites, just that they aren't the same thing as private/public. There's probably tons of different ways of doing name resolution: natural languages like English use context and interaction to resolve ambiguity. --- "I still don't understand this at all, sorry. XD" To me, dynamic means that the variables are resolved according to their value at runtime. Lexical means that variables are resolved according to their location in the source code. In Racket, you can say this: (define (foo x) (bar x)) (define (bar x) (+ x 5)) Let's imagine that Racket evaluated everything in a single namespace, like Arc. You could have the definition of "bar" in a different file, loaded long after "foo" is defined, and yet "foo" will still use it. That's because "bar" is resolved at the time "foo" is *run*, not when "foo" is *defined*. Racket, however, doesn't evaluate everything in a single namespace. It creates a new namespace per module. But *inside* a module, you can still do the above and it'll work correctly: "foo" is referring to the variable "bar" that does not exist when "foo" is defined. Thus, in my viewpoint, it is dynamic. With hyper-static global environments, you would instead need to re-order it so "bar" occurs before "foo", which means that all the variables "foo" needs are available at the time "foo" is *defined*. I think that's perhaps the key difference between lexical and dynamic: lexical uses the environment at the time the function is defined, dynamic uses the environment at the time the function is run.
Hmm... thinking about it, we seem to have multiple definitions at play here: whether a variable is "lexically apparent in the source code" (whatever that means), and whether to use the variables at the time the function is defined. From an implementation standpoint, I prefer the latter, since that's how I would actually implement it (and how Nulan implements it). But from a theoretical standpoint, I wonder if the former is more correct. In any case, all this big semantic debate has shown is that we are severely lacking in precise and short words to use to describe these concepts. So we end up attaching multiple meanings to the same word, we end up "overloading words" as you said. Blah blah natural languages suck blah blah. To resolve this, I propose the following: * "lexical scope" means that the scope of a variable is apparent in the source code (capable of being resolved at compile-time, etc). * "static scope" means (at least conceptually) that the scope is the environment at the time that the function was defined. This is pretty much exactly the same as hyper-static global environment, except it's shorter and easier to say. It also opens up the distinction between lexical/static scope for functions. * "dynamic scope" means the scope is the environment at the time the function is run. Using those definitions, Nulan has static scope at both the global and function level. JavaScript has dynamic scope at both levels because of var hoisting (grrr var hoisting, grrr). Racket has lexical scope at the module level and static scope at the function level because "define" inside a function needs to occur at the top of the function's body, otherwise it would have lexical in both. (For akkartik's sake, I updated the log with rocketnia's post and my reply)
Unfortunately, rocketnia was left out of the loop of the conversations between myself and Akkartik. So I used Nuit to format our conversations into a threaded log format: http://dl.dropbox.com/u/355502/2012.11.11%20-%20Akkartik%2C%20Rocketia (see how easy that was? Nuit was MADE for this kinda text-heavy stuff!) I then wrote a simple Arc program to take that Nuit text and output it as HTML: http://dl.dropbox.com/u/355502/log-to-html And here is the result: http://dl.dropbox.com/u/355502/2012.11.11%20-%20Akkartik%2C%20Rocketnia.html I will try and keep it updated, and will post it onto the Arc Forum later so people can see the discussion.
That is sweet!
Wait, is it auto-updating?
Only because I manually update it. :P
Ah. Might be worth splitting the meta-discussion on nuit into a separate page :)
I dunno, I kinda like having it all in one thing. I mean, if we were posting on the Arc forum instead, it'd all be in one thread, right? We tend to discuss a variety of things not necessarily related to the first post in the thread. The point of it is to show other people our discussions so they can see the back-and-forth. I want it to feel like they were a part of this e-mail conversation.
Yeah you're right. I go back and forth on this. Perhaps one way to do it would be to keep the scope discussion separate with a 'meta parent' pointer to the super thread. Hmm, that feels a little bit like a map UI zooming in and out on different parts of a thread. I keep finding ways zoomable UIs could be useful for a variety of complex artifacts. I want a google maps UI for a codebase somehow, showing me the major components and how they fit together, then their inner detail, and on and on. But just static code in itself isn't that useful. I want to fit dynamic behaviors in somehow. How to have code and tests lie in the same map?
Okay, great idea, except this is just a fairly small e-mail conversation so I'm going to try to keep it simple. I'm not exactly building a full-fledged forum here, just shuffling some data from one format to another. As for code... I suppose the tests would depend on the code, thus they would be a level above the code in the map. But using that model, you're just creating a UI that lets you visualize the dependencies of the code. I think dependencies are super important, which is why I actually like the Nulan style of NOT having late binding: it makes the dependencies obvious in the source code: everything that depends on this function MUST be defined after the function exists.
Anyways, now you can just submit a link to the cleaned up html to the arc forum :) We just need to find a permalink for it.
The Arc Forum is still not working for me, so I'll have to do it later. It seems I'm able to get maybe 2-3 posts in per day. Also, you already got a permalink: http://dl.dropbox.com/u/355502/2012.11.11%20-%20Akkartik%2C%20Rocketnia.html Okay it's not THAT permanent, but it'll do for now, unless you know of a better hosting site other than Dropbox?
> Also, you already got a permalink: > http://dl.dropbox.com/u/355502/2012.11.11%20-%20Akkartik%2C%20Rocketnia.html > > Okay it's not THAT permanent, but it'll do for now, unless you know of > a better hosting site other than Dropbox? Yeah, I feel anal about making sure we *never* break links on the arc forum. I'm willing to trust dropbox as long as you don't think you might delete the file in future, say if you run out of space or something. It sucks that there's no imgur for html -- just upload and have it create a permalink for hosting it. If you want I can host it on my linode. It'll get my SLA for my own links, which is pretty damn perfect :)
Sure, I can understand that. I don't really care where it's uploaded, but since we're still talking on here, I'd like to update it for now.
> Sure, I can understand that. I don't really care where it's uploaded, > but since we're still talking on here, I'd like to update it for now. Of course.
> The Arc Forum is still not working for me, so I'll have to do it > later. It seems I'm able to get maybe 2-3 posts in per day. My sense is that it's not about posting frequency but loading frequency. Sometimes the site dies on me if I hit reload twice in 30 seconds. (I have to reload if the submit link expires. Argh!)
Yeah, definitely. But since I have to look up stuff in order to post, it tends to limit my post count to much lower than the loading frequency. I also tend to refresh fairly frequently to see if anybody posted anything new. I tried using RSS for that instead, but I found it wasn't as nice as using the Arc Forum directly (I normally love RSS and use it to check up on the webcomics I read). Maybe I should use RSS to detect when new posts come in, and then use the Arc Forum to actually read them.
I've never had trouble with reloading on the Arc Forum. *knocks on wood* Let me know when there's a stable URL, and I'll post it and reply to it. :)
Argh! :) Ok, conversation today trumps permalink tomorrow. I'm ok with you submitting if Pauan is.
Great idea, except since the Arc Forum isn't working for me, I won't be able to see the reply or give my own reply to it. I'm fine with waiting a day or two, this stuff isn't super critical or anything. Maybe we should start looking for an alternate forum site, unless these issues get fixed.
Eh, I guess the lurkers of this conversation can wait for now. (Sorry lurkers!) I have to go for a few hours anyway, so I'll just put my reply right here in this email thread.
> (For akkartik's sake, I updated the log with rocketnia's post and my reply) Thanks! I find myself wishing we could put Ross's long response in the 'namespace' section of the page rather than the 'meta' section. Maybe chop his email up into the short prolog in 'meta' and the rest in 'namespace'? I know it's a little weird, but it might be ok if you just move part of the email up to an ancestor in the thread. And if you link the parts together.. (I'm not actually expecting you to do this, just thinking aloud about how someone could maintain hygiene when managing a forum.)
I'm trying to run your arc program: $ git clone http://github.com/Pauan/ar $ cd ar $ wget http://dl.dropbox.com/u/355502/log-to-html -O render.arc $ chmod +x render.arc $ wget http://dl.dropbox.com/u/355502/2012.11.11%20-%20Akkartik%2C%20Rocketia -O lexical-global-scope $ render.arc lexical-global-scope > lexical-global-scope.html expected an indent of 0 but got 4 either of you had that issue? Anyways, I'll repost what I was trying (line 3, column 4) ^ Am I doing something wrong?
You definitely didn't do anything wrong, I just made some changes to the Nuit parser (and need to make changes to the spec) but haven't pushed them out yet. The quickest way for you to fix it is to go into lib/nuit/nuit-parse.arc. On line 200, change #\` to #\>
> Thanks! I find myself wishing we could put Ross's long response in the > 'namespace' section of the page rather than the 'meta' section. Here, I just tried it for myself (with a little support from Pauan)
Very nice, it's a lot less nested. At this point it's getting big enough to justify rewriting it, condensing it, simplifying it... man, trying to simulate a forum with e-mail and super-simple programs is pretty rough.
> I've never had trouble with reloading on the Arc Forum. *knocks on wood* My theory is that it might have to do with our styles of using the site. I've become more aware that my style of browsing is relatively profligate of bandwidth. I'm constantly closing and reopening tabs. This is true all over. One of the reasons I like vim over emacs is that emacs encourages less discipline with empty lines and with buffers. Similarly I tend to only have a couple of windows per workspace and not more than a couple of workspaces. I'm tempted to speculate that there's two kinds of computer users in this respect. Pauan, are you a 'vim' or 'emacs' user? :)
"I'm tempted to speculate that there's two kinds of computer users in this respect. Pauan, are you a 'vim' or 'emacs' user? :)" Neither: I use gedit. I'd probably choose Emacs though, not only because it is customizable via a Lisp, and not only because it has a strong tradition of liberal "do whatever you want" mindset, but also because I too have a massive tab issue. In fact, I currently have 32 documents open in gedit, and I've long wished for something like Tab Organizer to manage them. My philosophy is not to try to restrict things, but to figure out how to manage them better. I experimented with a tab management system that put hard limits on things: you can only have up to X tabs open at one time. But I found that was far too restrictive. So Tab Organizer focus on organizing your tabs so that you can have many open at one time, and then helps you to find the tabs that you're no longer interested in so you can close them. It's much more organic and free-flowing. It certainly hasn't stopped my huge tab proliferation, but it has made it much more pleasant. I don't think you can solve these issues at the memetic (or technical) level, I think if you wish to stop this hoarding behavior, you're going to have to change our genes: it's hardwired into us. So for now, I just accept that it's how I am, so I just try to make it easier to deal with.
> Neither: I use gedit. Au contrair; I think your description makes it clear you're an 'emacs' person (even if you don't use it) by my definitions. So we aren't similar at all in that respect. There goes my theory :)