[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

updated srfi-109 - cleaning up discussion items

This page is part of the web mail archives of SRFI 109 from before July 7th, 2015. The new archives for SRFI 109 contain all messages, not just those from before July 7th, 2015.



I put an updated version of SRFI-109 here:
http://per.bothner.com/tmp/srfi-109/srfi-109.html

Before I ask the editors to update srfi.schemers.org,
I'd like a see if anyone has any options on some open
"Discussion" item, before I remove them.  See the draft
for context:

(1) "Discussion: It may be useful to allow an option to use a user-defined token, following a marker character - for example!"

I'm leaning towards dropping this, though I might keep a mention
as a possible future or implementation extension.

(1a) If someone has a preferred syntax for such an extension, that would
be useful to know.

(2) "Discussion: How about initial and final newlines?"

Not sure what the right answer is here.  The Kawa implementation
includes the initial newline in the result string; however that feels
wrong.  I.e.

(define onetwothree &{
     &|one two three
     &|uno dos tres
})

This seems like the natural way to write a 2-line string;
having to add an intial line-continuation marker &- seems
ugly.

Perhaps we can change the rule for &| - it deletes any
prior whitespace in that line. It *also* deletes the prior
newline if this is an initial newline.

(4) "Discussion: The above example is a bit ugly; it might be reasonable
to allow comments before the line-start marker:"

What do people think?  It makes the parsing a little more complicated,
but it seems useful.  And would we allow multi-line nested comments?

(define abc &{
  &| line1
  #|there is some special about this,
  so we need a multi-line comment |# &| line2
  &| line3})

This looks complicated. My inclination is to drop this
for now; it could be a feature of a future extension.

(5) "Discussion: Similar to Scheme character literals, a single-character
could name that character."

I.e. "&" followed by a single character followed by ";"
is equivalent to that literal character.  Is this convenient
enough to make up for adding yet more weird syntax?

(6)  "Discussion: Should we also support the standard string
single-character slash escapes in some form?"

I.e. &\n for newline.

(7) "Discussion: It may be reasonable to move format support to a
separate SRFI, where we could also cover string localization."

I think we certainly want to defer string localization (I don't
have time to deal with it right now), and I think we want to
make format specifiers an optional feature.  I'm not sure
whether and how to mention these optional/future features.
I think it makes sense to mention then in the context of a
rationale, to point to future directions.
--
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/