Alan Manuel Gloria: > I propose that we start to consider getting things up to 1.x. I'm > sure a lot of people have allergies to stuff with version numbers > starting in zeroes.
Fair enough. I *do* want people to understand that this version is still a 0.X. In particular, although I do not *expect* any spec changes at this point, I'd really like to get a little more experience before we truly freeze the spec. > > Can we get a timeframe to target for a 1.x? Goals for 1.x? I assume > a few months at the minimum so that we can actually start to see how > it's like to work with sweet-expressions et al. I think that's exactly right. We need a few guinea pigs to write code and to see if there are any big problems. Sometimes things work on 5-line programs, and their problems only become apparent from real use. I think curly-infix and neoteric-expressions are fixed; I can't see how to make them better. I can imagine tweaks to sweet-expressions. In particular, does "!" as indent really work okay, is \\ the right symbol for GROUP/SPLIT, and is "$" worth it? I think the answer is "yes" to all, but experience is the best instructor. I've already written one program with sweet-expressions: "sweeten.sscm", which translates traditional s-expressions into sweet-expressions... and simultaneously demonstrates what it looks like. And I must say I am *extremely* satisfied. Code looks MUCH, MUCH better, and is truly far more readable. I think it's stunning how well it works. And I think you're at least the other guinea pig. Even if you can't post publicly the code you write using it, if you could write some code and report back "works well", "works well except...", or "send this turkey packing because...", that would be a big step. If anyone else would be willing to write some code using this, and posting their experiences, that would be AWESOME. It need not be lots, though that'd be nice. I *particularly* want to know if there are killer problems with the notations. New ideas are welcome too, though I think that door is closing. > What do we need for > an official 1.x, aside from some experience working with the syntax? > I assume that we would like to have a website on or before 1.x that > lets users sweeten, unsweeten, and run a scheme with > sweet-expressions. Yes, I think that's the main need. So here's my proposed "1.0 list": 1. More experience with syntax. I think need at least two developers to have developed code with it beyond a few short functions. I'm one, and you'll be the next. It'd be great if we can have more, though I think we only need two for version 1.0. 2. A little video tutorial. I plan to do that soon. 3. In-a-browser implementation of sweeten, unsweeten, and a sweet REPL. 4. More test cases... and make sure we pass them :-). I want it to be *shocking* if a guile user finds an error in our reader. 5. Formal spec. We have two older "spec" files to use as a starting point. 6. Further clean-up of kernel code. Some complexity we can't avoid, but it should be as obvious as possible that it's *right*. I'd like for it to match the formal spec as much as makes sense (e.g., key functions and key formal spec productions should match), again, so that we can increase confidence that our implementation is correct. Also, I want it to be maximally portable, not only between Schemes, but make it easier to port to non-Schemes by limiting functionality that's really Scheme-specific. 7. Fix bugs wherever they're identified. 8. Improve docs. Anything else? > To be honest, I think BiwaScheme is "not bad" - looking at the example > code, it seems that the terminal on biwascheme.org simply passes a > continuation to process each line entered into the terminal. I also started looking at BiwaScheme, but I was stymied by its hideously bad documentation. Eeeek. It also appeared that read-char and peek-char weren't implemented, which is rather a negative for us :-(. Yet I looked at a lot of Scheme-in-browser implementations, listed here: https://sourceforge.net/p/readable/wiki/Website/ BiWaScheme actually looks like a reasonably good implementation overall, but its terrible documentation made it unclear to me where to get started. > As a > simplifying assumption, for sweet-Biwa we might modify this terminal > so that it ends an expression on an empty line (the BiwaScheme.org > version counts the number of ( ) to see if they balance - if they do, > then it passes the expression to the eval). We can then wrap the > string into a special "portlike" object that is a mutable tuple of the > string and an index into it, and write my-peek-char and my-read-char > to manipulate that tuple. If BiwaScheme doesn't have cond-expand we > can just preprocess src/kernel.scm for it (that's why cond-expand is > specified the way it is: it is supposed to be useable only on the > top-level, unless you know that you are in a Scheme that allows it to > be used nested - and if you know, then you're already in a cond-expand > on the top-level). You're already doing a lot, but would you be willing to take a starting crack at that, for any one of those three cases (sweeten, unsweeten, and Scheme REPL)? I can help once something's started, and hopefully another lurker on the list will help too! --- David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
