From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: project.el semantics Date: Sun, 22 Nov 2015 13:27:20 -0800 Message-ID: References: <86pp1j4ejm.fsf@stephe-leake.org> <56415902.90103@yandex.ru> <86h9ktah9x.fsf@stephe-leake.org> <56429025.3070008@yandex.ru> <86r3jw4yrf.fsf@stephe-leake.org> <564340DC.5020008@yandex.ru> <86wptob2v6.fsf@stephe-leake.org> <5643CEAA.6000103@yandex.ru> <86si4bemyw.fsf@stephe-leake.org> <564478CA.20108@yandex.ru> <86y4e3c90y.fsf@stephe-leake.org> <56450CDB.9050604@yandex.ru> <564D3223.1050705@yandex.ru> <86h9kf655z.fsf@stephe-leake.org> <56515443.70408@yandex.ru> <5651597B.5090303@yandex.ru> <5651F7CC.1030503@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448227673 12199 80.91.229.3 (22 Nov 2015 21:27:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 21:27:53 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 22:27:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0cAc-0000vR-S8 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 22:27:39 +0100 Original-Received: from localhost ([::1]:57587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0cAX-0002q0-Qj for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 16:27:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0cAT-0002pd-SY for emacs-devel@gnu.org; Sun, 22 Nov 2015 16:27:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0cAP-0008IQ-Qs for emacs-devel@gnu.org; Sun, 22 Nov 2015 16:27:29 -0500 Original-Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:36434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0cAP-0008IB-JA for emacs-devel@gnu.org; Sun, 22 Nov 2015 16:27:25 -0500 Original-Received: by pacdm15 with SMTP id dm15so170693160pac.3 for ; Sun, 22 Nov 2015 13:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=JC79hmaNN4BJBBXLMhetu5ISBqT3YnbOz8nD88v8QJQ=; b=bI/LtDhwzrRbT6GE/QOC7q1Cx/9qxSJl2a9o5t7+tqhYhPVVj0bmTuGqNS/t1PDt63 aShbsmd5J/tDnySDI59QGtrH2E7BMS6wSzh9tX2P0JnwKxDRs0lgVIuysJX0Bru+QcqE 8/hg+8tqlFp/P8uNZkmvUVsJpZSI8B5D1c22ujfdpjnvPWtAb3/JK+Kmoo7Q1/tGWdyA hF/jAQNFzILsyZdDrLgkjWyMXSg2fd8XaLLXssaQapHHIFTG/Q6rYoO1AQ2uANL3g41p snOII7a3mY36ZzU9hB1uLTFRhPBB6L+/0e5V/eKTfOriJAJUJFAMZDzQfjwVhNNdZXrq MPfw== X-Received: by 10.66.221.163 with SMTP id qf3mr32246583pac.121.1448227644891; Sun, 22 Nov 2015 13:27:24 -0800 (PST) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id n6sm7679358pap.24.2015.11.22.13.27.23 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 22 Nov 2015 13:27:23 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id 67CBA10A8263D; Sun, 22 Nov 2015 13:27:22 -0800 (PST) In-Reply-To: (John Wiegley's message of "Sun, 22 Nov 2015 11:54:01 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Dmitry Gutov , Stephen Leake , emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195071 Archived-At: >>>>> John Wiegley writes: > I thank you for your nearly endless patience while we dance this dance. I > will write up a description of higher-level semantics later today, against > which we can look at the various API options. What is a "project"? A project, semantically, is a set of sets: {{A, ...}, {B, ...}, ...}, where each member set defines a "view" of the entities of the project. Example views: - All files related to the project, in any way - All files containing source code (i.e., no generated content) - All files under version control - All generated files and directories - The arguments one would provide to GNU find to produce a similar list of files to any of the above - The directories and files relating to the project, with some indication of whether those directories should be recursed (and how) - etc., etc. There are potentially infinitely many ways to view a project, depending on what the users wishes to do. Examples of such uses include: - Build a TAGS file - Run a query-replace operation - Populate a dired buffer with the project file paths - Run a find-grep on the project's contents - Provide data to a higher-level package like Projectile - Delete all generated files - Build an ignore list for dired-omit-files - etc., etc. The main question is, how do we determine this "set of sets", since the fully generated set is potentially infinite? To achieve this, we take the "project set" to be intensionally defined, and provide an API for querying along the multiple views. The data returned from these views should be generative (using stream.el), so that element-by-element actions do not require excess allocation up front. This API should be sufficient to define the set of utility functions that operate in terms of it, and of taking whatever actions we wish in relation to a "project". Having described it this way, it seems there at least three sub-languages involved: (1) A description language to define projects; (2) a query language to define the desired view of a project; and (3) a selection language to determine how the results of the query should be returned. In SQL terms, it might look like: SELECT (selection) FROM (definition) WHERE (query); For convenience, the DEFINITION can often be determined from context, such as by querying Git or VC. For convenience, the SELECTION can often be reduced to small set of options, such as "all file paths" or "files and directory roots". For convenience, the QUERY can be reduced to a set of possibilities, like "source code", or "ignored files", or "library files", etc. While the surface API might encode these conveniences as short-hands for what are likely to be common uses, the underlying API should allow the general form of a rich query. The project is, in a sense, a database of entities, and it's hard to pre-determine all possible useful queries of such data. How these conveniences are implemented is completely open; `cl-defgeneric' methods that encode the QUERY&SELECTION against an auto-determined DEFINITION is just fine, and is how project.el is written today. What is presently missing is the lower-level query API, and the freedom to specify the DEFINITION, QUERY and SELECTION in more flexible ways. *That said*, I'd be willing to postone such an API until a future version, since, from the user's perpective, it could be seen as an implementation detail behind the convenience APIs. So maybe this has come full circle, but if so, I hope it adds some clarity. John