Opened 7 years ago

Closed 5 years ago

#16 closed defect (fixed)

symbol escapes

Reported by: alexshinn Owned by: alexshinn
Priority: major Milestone:
Component: WG1 - Reader Syntax Keywords:
Cc:

Description (last modified by cowan)

[This ticket was originally about string escapes, but commenters have been talking about symbol escapes instead.]

R6RS provides character escapes in symbols of the form \xnnnn;, where nnnn is 1-5 hex digits. Do we accept this extension? Do we also allow |...| to escape a whole symbol or a part of one?

Change History (15)

comment:1 Changed 7 years ago by kumoyuki

The thing is that those escapes make the printable form of symbols *fugly*. At least in Larceny - and as I recall Will explaining it, the Larceny behavior is strongly implied (if not actually mandatory) by R6RS.

I think this area needs work.

comment:2 follow-up: Changed 7 years ago by cowan

Providing |...| escapes for symbols (but not allowing them to escape spaces) deals with much of that.

comment:3 in reply to: ↑ 2 Changed 7 years ago by arcfide

Replying to cowan:

Providing |...| escapes for symbols (but not allowing them to escape spaces) deals with much of that.

What do you mean by not allowing |...| to escape spaces?

comment:4 Changed 7 years ago by cowan

By "not escaping spaces" I mean that |foo bar| is invalid syntax rather than (as in PLT, Gauche, MIT, Gambit, Chicken, Kawa, SISC, Chez, Ikarus, Scheme 9, Scheme 7) the symbol whose string name is "foo bar". This prevents an unpaired | from turning the rest of the program into a giant symbol, and aids readability as explained in the R6RS rationale. If you want that symbol, write foo\x20;bar or foo\{20}bar or whatever we decide on for local escaping.

comment:5 Changed 7 years ago by arcfide

I think the general point of
is to avoid the need for \x20; in the first place.

comment:6 Changed 7 years ago by cowan

As far as I'm concerned, it's much more important to be able to import the identifier FOO from a case-preserving module into a case-folding one as |FOO| rather than \x46;\x4F;\x4F;.

comment:7 follow-up: Changed 7 years ago by cowan

  • Description modified (diff)
  • Summary changed from extended string escapes to symbol escapes

comment:8 Changed 7 years ago by arcfide

I would consider them the same basic issue. It's a literal block escape for scheme values. Why should we limit what goes between them? Arbitrarily limiting them to non space characters is just that, arbitrary. What about \x0;? TAB? I mean, a missing " will capture a whole bunch, and a missing | is no different.

comment:9 in reply to: ↑ 7 Changed 7 years ago by kumoyuki

Replying to cowan:

It seems that there is an unfortunate consequence of using Trac for the purpose of discussing language design issues. I am fine with the string escapes, but there is a side effect in another area - namely symbols, where the string escapes are less than pleasing.

comment:10 Changed 7 years ago by cowan

  • Resolution set to fixed
  • Status changed from new to closed

The WG voted to accept this feature.

comment:11 Changed 6 years ago by alexshinn

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:12 Changed 6 years ago by alexshinn

  • Owner alexshinn deleted
  • Status changed from reopened to assigned

comment:13 Changed 6 years ago by alexshinn

  • Status changed from assigned to decided

comment:14 Changed 6 years ago by alexshinn

  • Owner set to alexshinn
  • Status changed from decided to writing

comment:15 Changed 5 years ago by cowan

  • Resolution set to fixed
  • Status changed from writing to closed
Note: See TracTickets for help on using tickets.