[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION Writeup

Status:       MINUMUM proposal accepted 4/1/92

Issue: EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION

Forum: Cleanup

References: OPEN, WITH-OPEN-FILE, LOAD, COMPILE-FILE, STREAM-EXTERNAL-FORMAT

Category: EXTEND

Edit history: 10-Jan-92, Version 1 by Masa Ida

14-Jan-92, Version 2 ibid.

(correct a typo. add Editorial Impact field. Add Discussion.)

1-Apr-92, Version 3 by Barrett

(compile-file-pathname, similarity of constants constraint)

2-Apr-92, Version 4 by Barrett (amendments from meeting)

Problem Description:

OPEN and WITH-OPEN-FILE have :EXTERNAL-FORMAT keyword

to specify the external format of files, but other file

connecting interfaces like LOAD have no such keyword.

As a result uniform handling of external formats are

impossible with the current draft.

Proposal (EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:MINIMUM);

Add the :EXTERNAL-FORMAT keyword to LOAD and COMPILE-FILE.

The default value is :DEFAULT as in OPEN. This argument specifies the

character representation scheme to be used by LOAD and COMPILE-FILE

when reading a source file, in the same manner as for OPEN.

This changes the syntax descriptions to

Compile-file input-pathname &key :output-file :verbose

:print :external-format

Load filename &key :verbose :print :if-does-not-exist

:external-format

Add to the descriptions of COMPILE-FILE and LOAD a cross reference to

(or copy of) the description of the :EXTERNAL-FORMAT argument for OPEN.

The :EXTERNAL-FORMAT argument is ignored by LOAD when opening a

compiled file. Instead, COMPILE-FILE and LOAD must cooperate (using

some implementation-dependent mechanism) in such a way that similarity

of constants is maintained across the interface between these two

functions.

Editorial Impact:

Trivial. If STREAM-EXTERNAL-FORMAT description will refer

the usage of :EXTERNAL-FORMAT in the future, editorial consideration

will be needed.

Test Case:

(LOAD "MY-PROG.LISP" :EXTERNAL-FORMAT :NIHONGO-EUC)

will load the file MY-PROG.LISP which contains nihongo-euc

coded characters defined by UI-OSF joint japanization definition.

(COMPILE-FILE "YY.CL")

will compile the file YY.CL with the default understanding.

Rationale:

Uniform handling of external formats are enabled by

adopting this proposal.

Current Practice:

There is no way to specify the coding scheme for

loading/compiling files.

Several Japanese commercial CL implementations use

this scheme.

Cost to Implementors:

If implementation supports :default only, the cost is negligible.

Cost to Users:

The existing japanized software with their own tricks for

converting the codes must rewrite the interface to the

system supplied one to have a portability.

Cost of Non-Adoption:

Incompatibility with the Jeida Guideline draft.

Benefits:

Performance up.

Compatible definition.

Aesthetics:

unified syntax.

Proposal (EXTERNAL-FORMAT-FOR-EVERY-FILE-CONNECTION:JEIDA-GUIDELINE);

Only :DEFAULT is defined for the value of :EXTERNAL-FORMAT now.

Other possible selections are not defined.

Add the following selections for :external-format value.

:nihongo-jis file contains JIS X0202 encoding JIS characters.

:nihongo-euc file contains nihongo-euc defined by

the joint convention defined by UI-OSF.

:nihongo-ms file contains Microsoft Kanji Code.

Editorial Impact:

Trivial. If STREAM-EXTERNAL-FORMAT description will refer

the usage of :EXTERNAL-FORMAT in the future, editorial consideration

will be needed.

Test Case:

See the Test Case for MINIMUM

Rationale:

Every practical conversion scheme is provided with this definition.

Current Practice:

Users write their own codes for conversion. Or

Several CL cannot handle japanese characters.

Cost to Implementors:

Requiers the supporting mechanisms/libraries for japanese

character handling.

Cost to Users:

Cost of Non-Adoption:

Incompatibility with the Jeida Guideline draft.

Benefits:

By adopting this proposal, implementations can have a portable

way for japanization.

Aesthetics:

If there is consideration for other nations,

say, we can add :arabic-XXX, :chinese-XXX, ...

Discussion:

Masa Ida recomended to have the MINIMUM proposal.

The proposal JEIDA-GUIDELINE seems to be too sudden for X3J13

and may require more detailed definition.

The proposal JEIDA-GUIDELINE seems to be not needed for USA domestic

Applications.

Date: Mon, 13 Jan 92 11:16:40 EST

From: kab@cambridge.apple.com (Kim Barrett)

I don't yet have an informed opinion on the proposal (after the above

bug is fixed), but my initial reaction is that this certainly seems

plausible. I couldn't think of any operators besides the two mentioned

that implicitly call OPEN.

Date: Mon, 13 Jan 1992 16:37-0500

From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

I do believe this is an important issue. I think it's nice for us to

try to cater to the legitimate technical needs of the international

community in order to better position CL for acceptance in the

international arena, both in the standards arena and in the commercial

arena. I hope that at the appropriate time we will give it due

consideration.

My personal opinion is that the proposal looks solid (modulo the

obvious typo--missing "not"--mentioned by Kim Barrett) and worth doing,

both for general consistency and because I can easily see where the

absence of this feature would lead to some serious problems.

From: Larry Masinter <masinter@parc.xerox.com>

Date: Mon, 13 Jan 1992 15:49:14 PST

I like the :MINIMUM proposal, but I would be wary of including the

JEIDA guideline without also including other values for

:EXTERNAL-FORMAT.

There is apprently good progress in the ISO 10646 standard. (The DIS-2

ISO 10646 was supposed to be issued January 1992 for a 4-month

vote...)

Even if we listed interpretations for :external-format that included

JIS, EUC and Microsoft Kanji codes, it would seem to be important to

include a better reference for those coding schemes, since they tend

to get revised from time to time.

It might be that the standard should not include these keywords any

more than a listing of features, but that some other informal or

formal consortium of implementors could keep a registry of keyword

assignments.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.