[OT] Unicode fonts (was: Re: Hash composers and code blocks)
Mark J. Reed: > Aaron Sherman: >> Proposal: A sigil followed by [...] is always a composer for that type. >> >> %[...] - Hash. Unicode: ?...? >> @[...] - Array. Unicode: [...] >> ? - Seq. Unicode: ?...? >> &[...] - Code. Unicode: ?...? >> |[...] - Capture. Identical to \(...). Unicode: ?...? >> $[...] - Scalar. Identical to item(value). Unicode: ?...? >> #[...] - A comment. Just seeing if you're paying attention ;) > > Are those supposed to be question marks up there (meaning "up for > discussion"), or did something go awry in the email encoding (possibly > on my end)? It took me a while to find a font that displays them: Code2000. http://en.wikipedia.org/wiki/Code2000 (shareware) See also: http://en.wikipedia.org/wiki/Free_software_Unicode_fonts http://en.wikipedia.org/wiki/Unicode_typefaces http://www.alanwood.net/unicode/fonts_windows.html -- Affijn, Ruud "Gewoon is een tijger."
Updated: Re: Hash composers and code blocks
Aaron Sherman wrote:
(updated based on followup conversations)
Proposal: A sigil followed by [...] is always a composer for that type.
%[...]- Hash.
@[...]- Array.
&[...]- Code.
|[...]- Capture. Identical to \(...).
$[...]- Scalar. Like item(...), but forces copying even in argument
lists
Added after:
::[Type:...]
fglock pointed out that @(...), %(...) actually already do this.
I was going to modify this proposal around that, but then I looked at
the variations. I now contend that (...) has more of a "cast"
semantic than a "compose" semantic. If we wish to combine the two, then
we could, but that would require that &(...) take a block body, not an
expression (again, not what &(...) does now, at all).
In the end, I still think the bracket forms are a wonderfully simple
solution to the ambiguity problem, and I'm more convinced every time I
look at this that the ambiguity needs a fix. What's more, having one
syntax for composition of container and non-container types in free-form
data structures is tremendously appealing. We've thrown out ${...}, so
we could use that instead of brackets, but that's just one more
shift-key, and it doesn't seem to buy much. Am I wrong?
fglock also suggested that this might not be seen by the community as
"looking like perl." I'm not so sure that's the case, since we already
have @(...) and @{...}, but even if some do feel that way, I AM NOT
proposing that we eliminate any currently correct behavior. I am only
suggesting that we add "one more way to do it" for those of us who want
to dodge the ambiguity. Surely, that's not a big request?
To sum up:
(...) - cast expression ... to type implied by sigil
[...] - composition of type implied by sigil
Nice and uniform, no?
Re: Hash composers and code blocks
Mark J. Reed wrote: On 10/5/06, Aaron Sherman <[EMAIL PROTECTED]> wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...] - Hash. Unicode: ⦃...⦄ @[...] - Array. Unicode: [...] ? - Seq. Unicode: ⎣...⎤ &[...] - Code. Unicode: ⦕...⦖ |[...] - Capture. Identical to \(...). Unicode: ⦇...⦈ $[...] - Scalar. Identical to item(value). Unicode: ⦋...⦌ #[...] - A comment. Just seeing if you're paying attention ;) Are those supposed to be question marks up there (meaning "up for discussion"), or did something go awry in the email encoding (possibly on my end)? There is one occurance of ? in there (Seq has no sigil, and thus no [...] form). The rest are Unicode characters, and my headers did include: Content-Type: text/plain; charset=UTF-8; format=flowed so, I don't think there's a problem there... still, what Unicode characters are chosen (if any) is rather moot. The real issue is: do we want to have a disambiguated composer form, and if so is [...] the right choice?
Re: Hash composers and code blocks
On 10/5/06, Aaron Sherman <[EMAIL PROTECTED]> wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...] - Hash. Unicode: ⦃...⦄ @[...] - Array. Unicode: [...] ? - Seq. Unicode: ⎣...⎤ &[...] - Code. Unicode: ⦕...⦖ |[...] - Capture. Identical to \(...). Unicode: ⦇...⦈ $[...] - Scalar. Identical to item(value). Unicode: ⦋...⦌ #[...] - A comment. Just seeing if you're paying attention ;) Are those supposed to be question marks up there (meaning "up for discussion"), or did something go awry in the email encoding (possibly on my end)? -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Hash composers and code blocks
Aaron Sherman wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...]- Hash. Unicode: ⦃...⦄ @[...]- Array. Unicode: [...] ... I left out ::, which is probably a mistake. Part of the elegance of this, IMHO, is that it behaves the same for all sigils. The body of :: should probably be a capture whose invocant (required) is a type name: ::[Foo: 1,2,:x<3>,:y<4>] Which is identical to: Foo.new(1,2,:x<3>,:y<4>) Unicode for that seems like overkill, but if we needed it, ⦗...⦘ would suffice. Thus: ⦗Foo: 1,2,:x<3>,:y<4>⦘ That gives me the visual sense that something big and heavy is being created ;-)
