This page is part of the web mail archives of SRFI 49 from before July 7th, 2015. The new archives for SRFI 49 contain all messages, not just those from before July 7th, 2015.
Dear Bear, I won't comment much on your mail, as it seems to mostly be a troll. This said, your comment on Schemes with this syntax enabled by default needs a remark; the syntax is constructed in such a way as to be backward compatible with the normal S-expression-based syntax - I-expressions could be enabled by deffault without breaking any but a very small set of old code. Specifically, the only code that would break, would be code that had two consecutive topplevel expressions, with the second line indented more, as in (define foo bar) (define fie naja) To code like that clearly is not very usefull, and so isn't found in many progams (most progams I've seen have had all topplevel expressions non-indented). However, regardless of this, I _do_ agree withy you and don't think anything like this should be "enabled by default", there simply is no need for that as SRFI-7 gives a way for a Scheme program to specify its need for this or any other SRFI, and some implementors may shoose to implement this SRFI as a module in their module-system (my reference implementation for example, is a GNU Guile module), in which case their normal module import function can be called uppon to use this SRFI. The rest of your garbage, I've dumped in /dev/null... Best regards, Egil bear <bear@xxxxxxxxx> writes: > First, I should say upfront that I think indentation-sensitive > syntax is a Bad Idea. > > Second, I should say upfron that I think scheme is one of the > worst *POSSIBLE* languages to apply indentation-sensitive syntax > to. > > If this SRFI is implemented, I will stop using any scheme that > implements it and enables it by default. > > Okay? You understand where I'm at on this whole proposal, right? > > Now, understanding that this is a bad idea in the first place, > allowing mixed spaces and tabs is the worst possible way to do it. > Even the pythonistas, who have a language that indentation-sensitive > syntax (sorta) works for, have had no end of fights over tabs and > spaces, and they're now in the process of banning them. > > Understanding that it's the worst design for a bad idea, reading > a tab as equal to FOUR spaces is the worst possible number that > could have been plugged into this design. Standard editing software > assumes tabs are EIGHT spaces by default; two of your FOUR space > tabs will line up exactly with people's expectation of where a single > EIGHT space tab should be, and hence cock up their thinking about the > code as well as cocking up the code itself. > > I probably won't check back into this particular SRFI thread; I'll > just take it as a warning that there are idiots out there who would > do this, and implementation of it as a sign from God that the > implementor has in fact gone insane and that their scheme should be > avoided in the future. > > Bear > -- http://redhog.org GPG Public key: http://redhog.org/PGP%20Public%20key.asc Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!