In talking with a friend, I mentioned something mostly out of PAIP:
(parse
grammar:
"A simplified grammar of English."
( Sentence -> (NP VP) )
( NP -> (Article Noun) )
( VP -> (Verb NP) )
( Article -> the a )
( Verb -> eats drinks )
( Noun -> man woman dog blog )
sentence:
"The sentence to parse"
(A blog eats the man)
)
I'd like to make most of the parens be thin and dim, so they don't
stand out. Like that Shriram Krishnamurthi slide at ll1. Does anyone
know of a nice little (perhaps unicode) pair of letters that should
render like that, so I can use them instead of parens? It doesn't
need to be thin dim parens, that's just what I'm imagining right now;
you might think of something better.
(If you want to know why I'm asking, we're talking about stuff like
genetic algorithms, and I'm mentioning to him that we kind of program
in a way that makes the textual form look nice; and when you look at
the program, you're not absolutely sure if it's code, data or both.
Ascii art with bite?)
(Yes, this sort of stupidity concerns me.)
In article <····························@posting.google.com>,
Tayssir John Gabbour <···········@yahoo.com> wrote:
> I'd like to make most of the parens be thin and dim, so they don't
> stand out. Like that Shriram Krishnamurthi slide at ll1. Does anyone
> know of a nice little (perhaps unicode) pair of letters that should
> render like that, so I can use them instead of parens? It doesn't
> need to be thin dim parens, that's just what I'm imagining right now;
> you might think of something better.
>
> (If you want to know why I'm asking, we're talking about stuff like
> genetic algorithms, and I'm mentioning to him that we kind of program
> in a way that makes the textual form look nice; and when you look at
> the program, you're not absolutely sure if it's code, data or both.
> Ascii art with bite?)
>
> (Yes, this sort of stupidity concerns me.)
I don't know about thin, but I like mine dim, and I found this to do it:
http://www.davep.org/emacs/parenface.el
It gives parens their own face in emacs, which you can configure however
you like.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> wrote in message news:<······················@attbi_s04>...
> I don't know about thin, but I like mine dim, and I found this to do it:
>
> http://www.davep.org/emacs/parenface.el
>
> It gives parens their own face in emacs, which you can configure however
> you like.
Thanks! While I was thinking of sending the code thru email, I'll
definitely try this out for my own codin'.
Incidentally, a couple syllables from the unicode's Canadian aborigine
section look like good candidates. In fact, I once used to worry
about people going nuts with unicode support, but it would be pretty
fun to code in other languages. And you know, China's going to force
the issue eventually anyway.
Tayssir John Gabbour wrote:
>
> Brian Downing <·············@lavos.net> wrote in message news:<······················@attbi_s04>...
> > I don't know about thin, but I like mine dim, and I found this to do it:
> >
> > http://www.davep.org/emacs/parenface.el
> >
> > It gives parens their own face in emacs, which you can configure however
> > you like.
>
> Thanks! While I was thinking of sending the code thru email, I'll
> definitely try this out for my own codin'.
>
> Incidentally, a couple syllables from the unicode's Canadian aborigine
> section look like good candidates. In fact, I once used to worry
> about people going nuts with unicode support, but it would be pretty
> fun to code in other languages. And you know, China's going to force
> the issue eventually anyway.
We're getting there. Slowly. Moving a Lisp to Unicode is quite an
undertaking if you intend to do it right, because source code and data
are the same 'language' so you've got an entire toolchain that mostly
has to be built from scratch.
Bear
(currently elbows-deep in reimplementing unicode libraries
using C, so as to get machine code that I can put into a
compiler).
Ray Dillinger wrote:
> We're getting there. Slowly. Moving a Lisp to Unicode is quite an
> undertaking if you intend to do it right, because source code and data
> are the same 'language' so you've got an entire toolchain that mostly
> has to be built from scratch.
I must disagree. When Franz converted Allegro CL from an 8-bit character
system to one that could be configured (albeit globally) either with 8-bit
ASCII or 16-bit Unicode characters, it did not require rewriting the entire
tool change. There were issues here and there, but most things just work.
There is some nonobvious hair internally supporting Unicode (e.g. handling
the correspondence between upper- and lower-case chars while preserving
speed of the char/string comparison and predicate functions, but once the
compiler understands both formats of chars and strings, most code works
automatically.
Some additional work comes in supporting all the external formats needed
by non ISO8859 language scripts. While Unicode represents pretty much
everything in a nice, flat, 16-bit code (ignoring that Unicode has
actually recently overflowed 16 bits -- sigh!) and UTF-8, which is a
simple space-saving encoding of Unicode, most of the difficult languages
have one or more different variable-length encodings. For example,
Japanese has three popular non-Unicode-based encodings, and Lisp
applications may ultimately need to deal with each. (For example, my
Japanese wife regularly receives email in _four_ different encodings.)
In addition to having Lisp understand all these obscure encodings, there
is continual work (and customer support) helping users set up their tools
(e.g. Emacs, X, whatever) so that their displays have the proper fonts and
their input methods work. But this is a system configuration issue more
that a Lisp imlpementation issue. For example, CLIM tries to support
the Lisp Machine Hyper and Super modifiess in addition to the standard
Control and Meta key modifiers. This worked silently for many years
(although was only rarely used by anyone) with the Num Lock key being
remapped as the shift for Hyper. But this remapping interfered with
a certain standard input method for Russian characters which also
assigned some odd shift behavior to the Num Lock key -- so a patch was
needed for CLIM to keep it from acting on the Hyper key modifier.
To return to the original question, the brittleness of input methods and
display fonts is one reason I would caution against using characters from
some obscure font in order to improve visual typography. Few non-ISO-8859
fonts are standard across many platforms, and someone trying to read this
code or papers without all the obscure fonts installed (or with his
system improperly configured) will see garbage instead of the desired
slender parentheses.
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> To return to the original question, the brittleness of input methods and
> display fonts is one reason I would caution against using characters from
> some obscure font in order to improve visual typography. Few non-ISO-8859
> fonts are standard across many platforms, and someone trying to read this
> code or papers without all the obscure fonts installed (or with his
> system improperly configured) will see garbage instead of the desired
> slender parentheses.
With emacs, this is easily solved with something similar to the
following (which does display a left arrow instead of underline).
(defvar lse-assign-image
(find-image
(list
(list :type 'xbm
:width 7
:height 12
:ascent 91
:background nil
:foreground nil
:data (let* ((lines
(mapcar
(lambda (line)
(let ((vec (make-bool-vector (length line) nil)))
(do* ((bits (mapcar (lambda (char)
(string/= char "."))
(split-string line ""))
(cdr bits))
(bit (car bits) (car bits))
(i 0 (1+ i)))
((null bits) vec)
(aset vec i bit))))
(split-string ".......\n.......\n.......\n..**...\n.**....\n******.\n.**....\n..**...\n.......\n.......\n.......\n.......\n")))
(vec (make-vector (length lines) nil)))
(do ((lines lines (cdr lines))
(line (car lines) (car lines))
(i 0 (1+ i)))
((null lines) vec)
(aset vec i line))))))
"A left arrow glyph.")
(defun lse-underline-to-assign ()
"Replace all occurence of _ into left arrow (to be used once in lse-mode)."
(interactive)
(save-excursion
(save-restriction
(widen)
(goto-char (point-min))
(while (search-forward "_" nil t)
(delete-region (match-beginning 0) (match-end 0))
(insert-image lse-assign-image "_")))))
(defun lse-put-image (image pos &optional string area)
"Put image IMAGE in front of POS in the current buffer.
IMAGE must be an image created with `create-image' or `defimage'.
IMAGE is displayed by putting an overlay into the current buffer with a
`before-string' STRING that has a `display' property whose value is the
image. STRING is defaulted if you omit it.
POS may be an integer or marker.
AREA is where to display the image. AREA nil or omitted means
display it in the text area, a value of `left-margin' means
display it in the left marginal area, a value of `right-margin'
means display it in the right marginal area."
(unless string (setq string "x"))
(let ((buffer (current-buffer)))
(unless (eq (car-safe image) 'image)
(error "Not an image: %s" image))
(unless (or (null area) (memq area '(left-margin right-margin)))
(error "Invalid area %s" area))
(let (overlay
(curpos (point))
(prop (if (null area) image (list (list 'margin area) image))))
(setq string (copy-seq string))
(put-text-property 0 (length string) 'display prop string)
(insert string)
(setq overlay (make-overlay curpos (point) buffer))
(overlay-put overlay 'put-image t)
(overlay-put overlay 'evaporate t)
(overlay-put overlay 'intangible nil)
)))
(defun lse-assign ()
"Insert an assign operator (the ASCII code of the underline)
but adding an overlay on it with the `lse-assign-image' (a left arrow)."
(interactive)
(lse-put-image lse-assign-image (point) "_"))
(define-key lse-mode-map "_" 'lse-assign)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Ray Dillinger:
>> Moving a Lisp to Unicode is quite an undertaking if you intend to
>> do it right, because source code and data are the same 'language'
>> so you've got an entire toolchain that mostly has to be built
>> from scratch.
Steven M. Haflich:
> I must disagree. When Franz converted Allegro CL from an 8-bit
> character system to one that could be configured (albeit globally)
> either with 8-bit ASCII or 16-bit Unicode characters, it did not
> require rewriting the entire [toolchain]. There were issues here
> and there, but most things just work. There is some nonobvious
> hair internally supporting Unicode (e.g. handling the
> correspondence between upper- and lower-case chars while
> preserving speed of the char/string comparison and predicate
> functions, but once the compiler understands both formats of chars
> and strings, most code works automatically.
~ Support for 16-bit Unicode codepoints is, at best, imperfect and
partial support for Unicode. Unicode codepoints are 21 bits.
~ Simply doubling the size-per-character of a string is a poor way to
support Unicode strings. For many common uses it is inefficient.
If the entire codepoint space is supported, then it results in a
variable-length encoding for codepoints. In other words, good
Unicode support requires trickier changes to the representation of
strings than simply doubling the size of character elements (and
tricker than just "use UTF-8", too).
~ Wouldn't you agree that good Unicode support will include allowing
users to write identifier names using Unicode characters other than
those it has in common with ASCII? Yet if it does so, there is an
intricate problem of deciding when two differently encoded
identifiers are "the same" and of producing, from an identifier, the
name of the symbol it can denote. These issues effect not only
readers and run-time systems, but also compilers and linkers -- in
short "an entire toolchain".
Moreover, it is desirable to solve read/write equivalence for symbol
literals in an implementation-independent way so that
Unicode-supporting Schemes can exchange data. If Scheme were more
mature at this point in history, and thus had a binary standard,
we'd be facing an analogous problem for "mangled" identifiers fed to
tools such as system linkers.
~ You'd think that R5RS, since it _does_ take some care to be
"character set agnostic", could easily be extended to support
Unicode. Unfortunately, that's not the case. In spite of its
agnosticism, it imposes requirements that a Unicode-supporting
Scheme would not want to satisfy. It's not just the entire
toolchain, but the standard that defines its requirements, too.
> Some additional work comes in supporting all the external formats needed
> by non ISO8859 language scripts.
It's funny but _that_ problem is the one I would consider fairly
(tedious but) trivial.
> While Unicode represents pretty much everything in a nice, flat,
> 16-bit code (ignoring that Unicode has actually recently
> overflowed 16 bits -- sigh!)
Why should we ignore that? 16 bits is clearly not enough.
> and UTF-8, which is a simple space-saving encoding of Unicode,
"space-saving" (for some scripts but not others) and "time-consuming".
Scheme's should not use that encoding internally unless fast
string-processing and unbiased internationalizatin are non-goals.
> most of the difficult languages have one or more different
> variable-length encodings. For example, Japanese has three
> popular non-Unicode-based encodings, and Lisp applications may
> ultimately need to deal with each. (For example, my Japanese wife
> regularly receives email in _four_ different encodings.)
> In addition to having Lisp understand all these obscure encodings,
I may be over-reading you but it sounds as though you are saying by
implication that Scheme standards for internationalization of the
language should be designed in such a way that not only Unicode but
also all of those non-Unicode character sets are equally well
supported.
To a very limited extent that's probably true. For example, I believe
that R6RS can and should retain that level of "character set
agnosticism".
But in a broader sense it misses something important: while the
Revised Report may have originated in an environment in which
networking was in its childhood years, today it is a dominant
consideration. While R6RS can remain agnostic about character sets,
nevertheless, standards for interoperability covering extended
character sets will be necessary for communicating implementations.
Those interoperability standards, supporting at the very least the
reliable exchange of S-expressions between implementations, can not
afford to be agnostic about character sets. Were they to go that
route, the Scheme community would be, in effect, taking on the task of
"Out-Unicoding the Unicode Consortium" -- defining a union character
set where the consortium has declined to do so.
-t
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Some additional work comes in supporting all the external formats needed
> by non ISO8859 language scripts. While Unicode represents pretty much
> everything in a nice, flat, 16-bit code (ignoring that Unicode has
> actually recently overflowed 16 bits -- sigh!) and UTF-8, which is a
> simple space-saving encoding of Unicode, most of the difficult languages
> have one or more different variable-length encodings. For example,
> Japanese has three popular non-Unicode-based encodings, and Lisp
> applications may ultimately need to deal with each. (For example, my
> Japanese wife regularly receives email in _four_ different encodings.)
The way you surely deal with this is to convert text in such encodings
into your internal representation at the earliest opportunity and out
of it again at the last. Code to convert from your internal string
representation to the various codecs isn't the most entertaining in
the world to write, but it's not hard.
Cheers,
mwh
--
I'm about to search Google for contract assassins to go to Iomega
and HP's programming groups and kill everyone there with some kind
of electrically charged rusty barbed thing.
-- http://bofhcam.org/journal/journal.html, 2002-01-08
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@posting.google.com>...
> In talking with a friend, I mentioned something mostly out of PAIP:
>
> (parse
> grammar:
> "A simplified grammar of English."
> ( Sentence -> (NP VP) )
> ( NP -> (Article Noun) )
> ( VP -> (Verb NP) )
> ( Article -> the a )
> ( Verb -> eats drinks )
> ( Noun -> man woman dog blog )
>
> sentence:
> "The sentence to parse"
> (A blog eats the man)
> )
Incidentally since this topic is active again, I did change this to
more normal code before sending it. It actually looks just like my
test harnesses (except my harnesses are in CL and so I'm not using the
colons), but I don't usually spend my time making things pretty to the
nth degree, unless I'm experimenting with actually writing a language.
And it could have used one set of parens around the grammar; who
really wants any lookahead?
If you're coding Scheme, and just want to make the parens a different
color, typeface, or size in Emacs, Quack's font-lock rules let you do
that:
http://www.neilvandyke.org/quack/
This feature is an artifact of Quack trying to be a half-butted
imitation of PLT DrScheme.
Neil
···········@yahoo.com (Tayssir John Gabbour) writes:
[...]
> I'd like to make most of the parens be thin and dim, so they don't
> stand out. Like that Shriram Krishnamurthi slide at ll1. Does anyone
> know of a nice little (perhaps unicode) pair of letters that should
> render like that, so I can use them instead of parens? It doesn't
> need to be thin dim parens, that's just what I'm imagining right now;
> you might think of something better.
[...]