On 05-09-12 14:12, David A. Wheeler wrote:
svanleent:
From a pragmatic side, wouldn't it be better to just have a marker like
#!curly-infix. The number 105 doesn't say much when reading the code,
which is the whole reason for the existence of curly-infixing.
There are advantages either direction. I agree with you on the advantage of
#!curly-infix, which was an alternative recommendation. However, John Cowan strongly
argues that the advantage of #!srfi-105 is that it tells you "where to go for more
information", as well as being more general.
I believe it is information versus information. I believe strongly that
a notion of #!curly-infix would be more readable than #!srfi-105. The
latter doesn't explain at all why the file looks drastically different,
whereas a notion of #!curly-infix (or #!sweet-scheme, #!scheme for the
same reason) is more understandable. However, as you say, it doesn't say
anything about the specification being involved, so for that matter, I
believe the following could be applied: The guile parser could give us
the literal SRFI's being implemented and with a bit of help from Emacs
or whatever a developer prefers, it could become just as navigatable, to
the extend of opening up the right info/pdf file or browser URL. Here it
should be the tools to help us, and this requires an obvious effort.
The implementation could be implemented as an option passed to guile as
simple as guile --info-spec SCM-FILE1 ... SCM-FILE-N. The benefit is
that this could enable to have more readable names in other cases as
well (such as module inclusion, etc.)
I understand well that this involves an additional step, however, to my
mind, it makes coding much more elegant.
Also, a file extension might change the folding mode. This could by
something like .scmc (scheme-curly).
True. We use .sscm for "sweet-scheme", for example.
--- David A. Wheeler