[Top][All Lists]

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

Re: Creating a coding system

From: David Kastrup
Subject: Re: Creating a coding system
Date: Sun, 21 Dec 2014 20:46:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>>> From: David Kastrup <address@hidden>
>>> Cc: address@hidden,  address@hidden
>>> Date: Sat, 20 Dec 2014 21:11:49 +0100
>>> > I might be mistaken, but this doesn't look to me like a job for a
>>> > coding-system.  You are talking about parsing input into some abstract
>>> > notation,
>>> "parsing input" is sort of bombastic for interpreting a binary
>>> representation consisting of isolated minimal words.
>> Yes, but coding-systems machinery is not a general-purpose bytestream
>> conversion facility.  It was designed and implemented specifically for
>> converting between known families of encodings.  You might be able to
>> tweak it enough to do what you want, eventually, but it doesn't look
>> like a piece of cake to me.  Programming in CCL is like writing
>> assembly code in a restricted machine language, hardly something well
>> suited to converting one complex bytestream into another.
> Uh, CCL is _exactly_ suited to converting one complex bytestream into
> another.  It's overkill for converting regular character set to other
> regular character sets which is probably the reason it is phased out.
> But for this task it seems a reasonable match.
>>> Uh, there is no grammar involved here, no context, most certainly not
>>> a push-down stack or something.
>> But there's definitely some kind of "lexing", no?
> No.
>> You are talking about sequences of symbols, not about letters from
>> some alphabet.
> No, Midi contains nothing like symbols.  Just codes with byte or word
> sized parameters.  Converting the codes would be straightforward, but
> converting the parameters as well would make the tables too large.  CCL
> looks like it can come to the rescue for producing Lisp expressions with
> the full parameters for _one_ approach.
>> If you try representing each sequence as an encoding of a letter,
>> won't you get an enormously large alphabet?
> Which is exactly why CCL, which can do calculations like divide by 10
> with remainder, will be able to save a lot of space if one wants to
> arrive at decimal constants in a human-readable rendering of the
> parameters.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]