Why are byte ports "ports" as such?
Ben Goetter
(13 Apr 2006 17:54 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(13 Apr 2006 18:04 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(13 Apr 2006 21:41 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(14 Apr 2006 12:49 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(14 Apr 2006 13:37 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(13 Apr 2006 22:03 UTC)
|
||
Re: Why are byte ports "ports" as such?
Ben Goetter
(14 Apr 2006 01:02 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(14 Apr 2006 01:52 UTC)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such?
Thomas Bushnell BSG
(24 May 2006 16:26 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(24 May 2006 17:18 UTC)
|
||
Re: Why are byte ports "ports" as such?
Marc Feeley
(24 May 2006 18:11 UTC)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(24 May 2006 16:06 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: Why are byte ports "ports" as such? Marcin 'Qrczak' Kowalczyk (24 May 2006 16:17 UTC)
|
||
Re: Why are byte ports "ports" as such?
John Cowan
(14 Apr 2006 12:26 UTC)
|
Thomas Bushnell BSG <xxxxxx@becket.net> writes: >> Then it's impossible to implement a UTF-8 encoder. There is an >> infinite number of potential characters, and there is no way to >> examine what a given character means. > > What exactly makes it impossible? There are an infinity of possible > integers, and this hasn't hampered the implementation of <. Integers support arithmetic. Individual bits or larger digits of an integer can be counted and examined. You can index dictionaries by integers. Any reasonable function on integers can be expressed by composing primitive operations. What operations would your characters support? I guess that operations similar to today's strings, i.e. determining the length, extracing individual code points, and some way to build them from code points (e.g. making a singleton from the given code point and appending a code point to a character, assuming that characters are immutable). With some rules of normalization; if NFC and NFD are indistinguishable, then extracting individual code points would not necessarily yield code points used to construct a character. But wouldn't it be simpler to just use strings of code points for what you would use characters? Strings of code points are needed anyway when we work on a lower level, e.g. when we care whether the output is NFC or NFD. So why don't just make a library which provides iteration over strings using substrings representing characters, normalization etc. - the same functionality, but without calling some groups of code points "characters"? >> established practice of using code points or even lower level code >> units as Scheme characters. > > There is no "established practice" of doing this. The established > practice is to pretend that code points and abstract characters are > the same. This is exactly what I said. The established practice is to work in terms of code points or even lower level. You want to call characters of this simplified view using the more formal term "code points", and to call some strings of well-formed sequences of combining characters "characters". Apart from changing names, what does it accomply? Changing practice just to have nicer procedure names is a weak excuse. -- __("< Marcin Kowalczyk \__/ xxxxxx@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/