- cdr-discuss - mailman3.common-lisp.net

[cdr-discuss] Proposed :TRUNCATE keyword for OPEN
by Richard M Kreuter 24 Dec '07

24 Dec '07

Hello, I'd like to submit the following as a CDR document. Any comments? Thank you, RmK Issue: OPEN-TRUNCATE References: CLtL1 pp 418 through 422, dpANS3 pp 21-34 through 21-36, accessible online at http://www.lisp.org/HyperSpec/Body/fun_open.html Related Issues: None. Category: Addition. Problem description: Common Lisp offers no explicit way to truncate an existing file when the file is opened. Interoperability of conforming Common Lisp programs with software systems that prefer or require truncating openings is hindered by the lack of an explicit way to request such openings. Proposal (OPEN-TRUNCATE:NEW-IF-EXISTS-ACTION): Amend the text of OPEN (Function) in the Arguments and Values section to replace the IF-EXISTS description with the text, IF-EXISTS--one of :error, :new-version, :rename, :rename-and-delete, :overwrite, :append, :truncate, :supersede, or ‘nil’. The default is :new-version if the version component of FILESPEC is :newest, or :error otherwise. and to add the following text in the Description section between the descriptions of :APPEND and :SUPERSEDE :truncate Output operations on the stream destructively modify the existing file. If DIRECTION is :io the file is opened in a bidirectional mode that allows both reading and writing. The file pointer is initially positioned at the beginning of the file and the file is truncated back to length zero when it is opened. Examples: ;; Recall that the consequences of calls to OPEN permitted to vary ;; considerably. In the following comments, "same file" and "different ;; file" assume a notion of file identity independent of file contents ;; or file names, which may not be applicable on all file systems, and ;; which cannot be distintinguished in conforming Common Lisp programs, ;; but which can nonetheless affect the correct operation of programs. (with-open-file (f "test" :direction :output) (write-line "some text" f)) "some text" ;; A successful :OVERWRITE opening returns a stream associated with the ;; file named by the defaulted argument to OPEN, and so after the stream ;; is closed, the file named by the defaulted argument to OPEN is the ;; "same file" as the file so named before the opening. (with-open-file (f "test" :direction :output :if-exists :overwrite) (values (truename f) (file-length f))) => #P"/home/me/test" => 9 ;; Under this proposal, a successful :TRUNCATE opening will return a ;; stream associated with the file named by the defaulted argument to ;; OPEN and empty the file during the opening operation. Consequently, ;; when the stream is closed, the file named by the defaulted argument ;; to OPEN will be the "same file" as the file so named before the ;; opening. (with-open-file (f "test" :direction :output :if-exists :truncate) (values (truename f) (file-length f)))) => #P"/home/me/test" => 0 ;; A successful :SUPERSEDE opening returns a stream that might or might ;; not be associated with a file named by the defaulted argument to ;; OPEN, and in the former case, the file associated with the stream ;; might be created and arranged to replace the existing file at the ;; time the stream is created, and so not be the "same file" as the one ;; that existed before OPEN was called. (with-open-file (f "test" :direction :output :if-exists :supersede) (values (truename f) (file-length f))) => #P"/home/me/test" => 0 or => #P"/home/me/test-temp-12345" => 0 Rationale: On some file systems, the customary way to open an existing file for output or input and output preserves the association between the name used to open the file and the identity of the file, but permits destructive modification of the file's contents. Common Lisp specifies two IF-EXISTS actions (:OVERWRITE and :APPEND) whose specification map straightforwardly to the identity preserving file openings on such file systems, but lacks an IF-EXISTS action that calls for truncation of an existing file's contents at the time the file is opened. Additionally, on some file systems, there are several distinctions between opening a file in a truncating manner and replacing an existing file with a new one, which can make a replacing opening inadequate for certain programs: (1) Under Unix, replacing one file with another "breaks" any hard links to the replaced file, while a truncating open maintains the association between the file and its names. (It is unknown whether other file systems have supported hard links with these particular semantics.) (2) Again under Unix, the circumstances under which a program may replace one file with another are different from those where it may destructively modify an existing file (permissions on the directory versus permissions on the file). Other systems may exhibit similar access control semantics. (3) Under Unix, but probably other systems as well, it can be impractical or impossible for a program to ensure that a new file's metadata is equivalent to that of the file to be replaced. It's unclear how much work the Lisp implementation may be expected to carry out to ensure that a new file's metadata resembles that of the file to be replaced. While hard links, access controls and file metadata are file system details outside the scope of ANSI Common Lisp, programs must sometimes interoperate with software that involve these details, and so prefer or require expressly truncating openings. Current practice: No current (ca. 2007) implementation of which this author is aware supports a :TRUNCATE IF-EXISTS action. The MIT Lisp Machine manual circa 1984 documents a :TRUNCATE argument for IF-EXISTS, so presumably truncating openings were implementable on many file systems then (the MIT Lisp Machine at that time accessed files on LMFS, ITS, TOPS-20, VMS, Multics and Unix). http://common-lisp.net/project/bknr/static/lmman/files.xml#Opening%20and%20… Cost to implementors: For implementations that already perform a truncating opening under some IF-EXISTS keyword, probably trivial. For implementations that don't yet offer any way to truncate a file at open time, the code for a truncating opening will probably resemble that of :OVERWRITE or :APPEND. Cost to Users: None. This is an upwardly compatible change. Cost of non-adoption: Programs that intentionally or accidentally rely on some implementations' truncating openings will remain non-portable to other implementations. Performance impact: Probably none. Benefits: Programs that need file truncation will be able to request it explicitly. Aesthetics: Some users might employ one or another IF-EXISTS action to effect tuncation on some implementations; under this proposal, such users will be able to say what they mean. Notes: Implementations of the interface described in this document are encouraged to ensure that the symbol :CDR-4 occurs in the *FEATURES* list when the Lisp environment is configured to behave as described in this document. As implementors already have license to vary from the specification of any OPEN option, and to signal an error if the implementation cannot handle some OPEN option as specified, adding a new IF-EXISTS action doesn't formally limit conforming implementations.

4 4

[cdr-discuss] re: Some changes to the Common Lisp Document Repository.
by Nick Levine 11 Dec '07

11 Dec '07

By the way, CDR-4 was due for finalization on November 1. Nothing's been announced about that though. - nick

2 1

re: [cdr-discuss] A proposed convention for *FEATURES*
by Nick Levine 24 Aug '07

24 Aug '07

Some comments on this proposal: 1. Ought this proposal to be a CDR? At present #+(not cdr-42) ...doesn't necessarily tell us anything - it could just mean that your proposal hasn't been adopted. But suppose this proposal is CDR number 5 (as of 2007-08-24 this is the next in the sequence) and so requires the feature keyword :cdr-5. Then #+(and cdr-5 (not cdr-42)) ...implies that your proposal is in effect and therefore that the absense of :cdr-42 on *features* means that this implementation isn't conforming to CDR-42. 2. Names beginning with "CDR-" You suggest: programmers are discouraged from adding keyword symbols to *FEATURES* whose names begin with "CDR-" except as part of implementations of interfaces described in CDR documents. Given that you only specify use of keywords beginning with CDR-<nn>, I'm curious to know why you restricted keyword use to anything beginning with CDR-. Grasping at straws, I wonder whether the implementors of a lisp which employed cdr-consing would want to announce this to their users by means of the :CDR-CONS feature (the presence of which would conflict with your suggestion). 3. Read-time conditionals only? You haven't proposed a means of determining after read-time (for example: during load of a pre-compiled system, or at runtime) which CDRs are in effect. I think this weakens your proposal. On the other hand, the solution (defun featurep) is fairly clear and has previously been documented "elsewhere": http://clrfi.alu.org/clrfi/clrfi-1-featurep Should this be revisited and proposed as a CDR? 4. Minor typo I don't know about your reader,, but mine really enjoys complaining about "too many commas". (See under "Esthetics") - nick

2 1

[cdr-discuss] A proposed convention for *FEATURES*
by Richard M Kreuter 22 Aug '07

22 Aug '07

Hello, After some discussion on comp.lang.lisp a few weeks ago, I asked Pascal Costanza whether a CDR document could specify that implementations of the document's interface should push features to advertise purported conformance with the CDR document. He encouraged me to send a draft here for comment. The writeup is in apprxomately the form of the cl-cleanup committee's issues, since I expect everybody will be familiar with that structure, though it doesnt actually propose any changes to ANSI. I'll mark it up in LaTeX later, if people think it's worth submitting to the editors. Comments? -- RmK * Issue CDR-FEATURES-CONVENTION * References Pitman, K.M. (1991). Issue COMMON-FEATURES. Issue 56, X3J13, ANSI. http://www.lisp.org/HyperSpec/Issues/iss056-writeup.html Pitman, K. and Chapman, K., editors (1994). Information Technology Programming Language Common Lisp. Number 2261994 in INCITS. ANSI. Rhodes, Christope. (2004). "Maintaining Portable Lisp Programs" http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/features.pdf * Related Issues ANSI Issue 56, more or less. * Category Recommendation ; "Recommendation wasn't a category in the cl-cleanup ;committee, but the CDR process isn't really the same ;thing. * Problem Description A document in the Common Lisp Document Repository (CDR) may describe programmers' interfaces or propose emendations or extensions to the ANSI Common Lisp standard. Such a document should specify one or more features so that programs may easily distinguish environments that may be expected to conform to the document's specification. * Proposal We propose a convention for naming symbols meant to be included in *FEATURES* for the purpose of advertising purported conformance with a CDR document's specifications, and encourage CDR document authors, Common Lisp implementors, and library authors to follow such conventions when providing purported implementations of such specifications. CDR documents that describe programmers' interfaces should enumerate a set of symbols in the KEYWORD package whose names begin with a prefix consisting of the string "CDR-" followed by the decimal representation of the number of the CDR document with no leading zeroes. If the CDR document defines only one level of conformance with the document's specifications (e.g., the document specifies no subsets), then the enumeration of keyword symbols should contain the symbol whose name is the prefix. If the CDR document defines levels of conformance of its total specification (such as subsets, or even mutually incompatible interfaces), then for each defined level of conformance, the enumeration of keyword symbols should should contain a symbol whose name begins with the prefix, followed by a hyphen, followed by some descriptive name for the subset. Implementors of an interface described in a CDR document that enumerates a set of keyword symbols as above should ensure that the appropriate symbols occur in the *FEATURES* list when the Lisp environment has been configured to behave in conformance with the specification. Configuring the Lisp environment might involve loading files, invoking functions, etc.; or the environment may conform to the specification when the host Lisp is initialized, in which case the implementation should include the appropriate symbols in *FEATURES* as early as initialization time. If, after configuring the Lisp environment to conform to the CDR document's specification, it should be possible to reconfigure the Lisp environment to fail to conform to the specification, whether the corresponding symbol remains in the *FEATURES* list after so reconfiguring is not defined by this proposal, but may be defined by a CDR document or an implementation of a CDR document's interface. Implementations of Lisps that provide non-standard lettercase customs in their symbol names are permitted to vary the lettercase of the names of the enumerated keyword symbols as necessary to furnish the appropriate effects on those implementations. Finally, programmers are discouraged from adding keyword symbols to *FEATURES* whose names begin with "CDR-" except as part of implementations of interfaces described in CDR documents. * Examples ** Example 1 Suppose CDR document number 42 defines no subsets of its specification; in this case, the document might include text such as the following: "Implementations of the interface described in this document should ensure that the symbol :CDR-42 occurs in the *FEATURES* list when the Lisp environment is configured to behave as described in this document." Next, suppose that Lisp implementation BAR only conforms in case the user calls the function ENABLE-CDR-42-API, and that Lisp implementation QUUX only conforms in case a particular file is loaded. In this case, a program that can work only in environments conforming to CDR 42's specification might begin with #+(and bar (not cdr-42)) (eval-when (:compile-toplevel :load-toplevel) (enable-cdr-42-api)) #+(and quux (not cdr-42)) (eval-when (:compile-toplevel :load-toplevel) (load "sys:source;cdr-42")) ;; If, after all that, CDR-42 still isn't present, bail out. #-cdr-42 (eval-when (:compile-toplevel :load-toplevel) (error "Can't run this program in a non-CDR-42 environment.")) ** Example 2 Suppose that CDR 704 defines two subsets of its specification, called "BASIC" and "BELLS-N-WHISTLES"; in this case the document might include text such as the following: "Implementations of the interface identified in this document as BASIC should ensure the symbol :CDR-704-BASIC occurs in the *FEATURES* list when the Lisp environment is configured to behave in conformance with the BASIC interface. Implementations of the interface identified in this document as BELLS-N-WHISTLES should ensure that the symbol CDR-704-BELLS-N-WHISTLES occur in the *FEATURES* list when the Lisp environment is configured to behave in conformance with the BELLS-N-WHISTLES interface." Now suppose a program needs a function FROB that's in BELLS-N-WHISTLES but not in BASIC, but that can be defined portably (albeit perhaps not maximally efficiently), given BASIC. Then the program might begin with #+(and cdr-704-basic (not cdr-704-bells-n-whistles)) (eval-when (:compile-toplevel :load-toplevel) (defun frob ...)) #-cdr-704-basic (eval-when (:compile-toplevel :load-toplevel) (error "Can't run this program without BASIC CDR 704~ compliance.")) * Rationale Since CDR documents are not constrained to describe only those interfaces that can be implemented in portable Common Lisp, an individual document may define what is in effect a new dialect that's slightly different from ANSI Common Lisp. Thus, by the logic of ANSI Issue 56, "Users need this to get a foothold as they try to port between dialects in transition." In particular, it is not possible in general to programmatically investigate the semantics of a new dialect. For example, a CDR document might specify some behavior for an operator that has undefined consequences in ANSI Common Lisp; a program that exercised the operator to test for conformance with the CDR document might crash a Lisp implementation that conforms to ANSI but not to the CDR document's specification. Even for interfaces that could be programmatically detected safely (interfaces that can be implemented in "modules" or "libraries"), it may nonetheless be desirable to distinguish the environment's purported conformance to an interface from the presence of a particular implementation of the interface. For example, it may be desirable from time to time for one library to supersede another while providing an upwardly compatible interface (perhaps modulo package names), or for an implementor to provide an implementation of an interface with extensions or optimizations that can't be written portably. In such cases, it may be difficult to detect all the ways that the environment might conform to the interface, and so an advertisement by the provider of the interface should simplify programs that depend on the interface. * Current practice As of Aug 2007, no existing CDR document does as this document describes. It is unlikely that anyone is already using keywords of the form :CDR-<NN> in their *FEATURES*. * Cost to Implementors Negligible. CDR document authors are encouraged to add a bit of boilerplate to their documents, and authors of programs that purport to conform to CDR document standards will have to arrange to push some symbols onto *FEATURES*. * Cost to Users Negligible, if any. * Cost of non-adoption It can be difficult to take advantage of interfaces described in the Common Lisp Document Repository, even when these interfaces are implemented. * Performance Impact None. * Benefits The CDR project might be more effective at spurring progress in Common Lisp. Users who desire to write programs that produce equivalent results and observable side effects on a subset of possible implementations might face an easier task if implementations advertised their purported conformance with defined, if non-ANSI, interfaces. * Esthetics It's slightly ugly to call for symbols such :CDR-<nn>-FOO-BAR-BAZ to be members of *FEATURES*, but alternatives are bad or worse. Specifically,, it's inconvenient to use read-time conditionals to check for anything other than the presence of keyword symbols in *FEATURES*, and it seemed like overkill to call for a package (say, "CDR") solely for the names of CDR document interfaces. * Notes Rhodes (2004) provides many examples of the pitfalls of read-time feature conditionals as a means for maintaining portable programs; this document does not dispute any of Rhodes's observations or suggestions. However, while Rhodes suggests various ways to organize implementation-specific code to minimize the use of read-time conditionals, it is hoped that the conventions detailed above will promote convergence of implementations in areas ANSI leaves implementation-specific or does not address, thereby reducing the amount of such implementation-specific code in programs intended for use in different Lisp environments. Note that this document does not constrain CDR documents from calling for elements of *FEATURES* other than those that follow the conventions proposed here, nor constrain implementors from providing symbols other than ones that follow the conventions proposed here. * Discussion It is not intended that identifiers of the form CDR-<NN> supplant descriptive, mnemonic names for interfaces, libraries, packages, systems, etc.

1 0

[cdr-discuss] Riepilogo posta spam
by Sistema antispam Iseo S. 30 Mar '07

30 Mar '07

Junk Box Summary for: cdr-discuss(a)common-lisp.net The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 30 days. To retrieve any of these messages, visit your Junk Box at: <http://10.1.1.2> Login using your standard username/password combination. Junk Box Summary --------------------------------------------------------------------- cyofocxplm(a)instlab.com Enrique said these are the best --------------------------------------------------------------------- Junk blocking by MailFrontier, Inc.

1 0

[cdr-discuss] Bank of America Corporation Update
by Bank of America Corporation 28 Jan '07

28 Jan '07

1 0

[cdr-discuss] Added a recommendation for alternative document formats
by Pascal Costanza 22 Jan '07

22 Jan '07

Hi everyone, Due to some feedback on the CDR process, we added a recommendation in the CDR manual to provide documents in alternative formats, like HTML and plain text. Some people prefer to read HTML or plain text, and these formats may also be more accessible to blind and visually impaired users. This addition is made to CDR 4 (without adding a new version of the document) and to the CDR site itself. Cheers, Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium

1 0

[cdr-discuss] http://scryed.org/fan/images/images/Mailer.php
by http＠common-lisp.net 23 Dec '06

23 Dec '06

1 0

[cdr-discuss] Various extensions proposed by vendors
by Marco Antoniotti (temporaneo) 15 Dec '06

15 Dec '06

Hi I just got the periodic newsletter from Franz and there is an interesting (and very useful) function defined that I have been using, with different name and slightly different semantics: READ- LINE-INTO. I would propose to publish it as a CDR, if the folks at Franz agree. Note that, AFAIU, a portable implementation is not quite possible. Cheers -- Marco

4 6

[cdr-discuss] CDR 3
by Gary King 15 Dec '06

15 Dec '06

I just want to say that even though, I haven't really had time to digest what Christophe has written, I think it looks great! I really like that you've been able to extend the "normal" CL sequence facilities so that you can use "regular" Lisp code with all kinds of new sequence types. That feels like a big win over having to rewrite everything with generic functions. -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

1 0