From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: PL support (was: Drop the Copyright Assignment requirement for Emacs) Date: Sat, 09 May 2020 08:50:45 -0700 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <87d07xamrg.fsf@ericabrahamsen.net> <878silajdl.fsf@ericabrahamsen.net> <87tv18pyh4.fsf@russet.org.uk> <83zhaih0oz.fsf@gnu.org> <83pnbegsvm.fsf@gnu.org> <83imh5hby1.fsf@gnu.org> <2e4e8ce9-d857-f3e3-31cf-a40dee67bd25@yandex.ru> <83y2q1dsvh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="60176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.24.0-1585 (build: 102400006) Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 17:54:01 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jXRnc-000FXD-Tl for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 17:54:00 +0200 Original-Received: from localhost ([::1]:48044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXRnb-0005Tu-Aw for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 11:53:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXRka-0002Pc-6i for emacs-devel@gnu.org; Sat, 09 May 2020 11:50:52 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:56602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXRkY-00025y-BF; Sat, 09 May 2020 11:50:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version: Subject:References:In-Reply-To:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=O/wAOzfqpuomT028MFZGDO/NAmoL6WE4dsXHgCCC91Y=; b=kYAJ/O/EqqqZovfUvAolG1wrf5 BNjHYTNS7V7vBZMqlFuGYaCT0t9Waygbim9nX5Nx5CahVmSq8EL/c25o8zkyye3PcB6bMkj8Ml5L3 nqfuQaLC1wr3jqlgp0N9qbeBc73hSfzLMJbR3fO5sS14RnChhQJX2h4y3f0c58z/8WDMnqjGW0b6U y6SS5yxwPTEPJ+jweHqBtoQivcrX45UCM5FN14ksuIu/vSijZ6uAcGgB8GKQKe4fkHYzWHO1KZtqS lZxYk5vJUDAcKn7ROUS/GoKOkHQfqr/Nc/IGR9llXr2axCmF4tMDyWtg0jEWuQvcqVXA+UwA+sWHZ rezXE1hw==; Original-Received: from [172.92.145.124] (helo=[192.168.86.155]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jXRkU-0007xI-82; Sat, 09 May 2020 08:50:46 -0700 In-Reply-To: <83y2q1dsvh.fsf@gnu.org> Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249481 Archived-At: On May 9, 2020 8:35:25 AM Eli Zaretskii wrote: >> From: João Távora >> Date: Sat, 9 May 2020 16:25:36 +0100 >> Cc: Eli Zaretskii , Stefan Monnier , >> emacs-devel >> >> I think Eli has indicated that LSP support in the core is desirable >> at some point > > Not only desirable: long overdue. Emacs must learn to use the latest > technologies of supporting programming languages based on real > parsing, because the time when it could be done with regular > expressions and similar techniques has come and gone. We cannot > enable significant new IDE-like features if we don't acquire these > technologies. > > Please someone start working on this ASAP. We sorely need that, just > look at the recent discussions on Reddit that underline these > deficiencies in Emacs. It's a hard problem. A mode based on a real parser must be fast, incremental, and robust against transient errors that arise in the normal course of editing. We'd also want the ability to parse complex languages (far beyond LALR) and incorporate out-of-band information in order to resolve semantic ambiguities --- e.g. the C++ template problem. On top of all that, the parser would need to be highly malleable to make it easy to adjust to slight differences in dialect as well as deal with multiple languages in a buffer. I've given the subject a bit of thought. One line of investigation consisted of doing GLR parses of each buffer, producing parse forests, and disambiguating the parse forests using semantic rules. The nice thing about GLR parsers is that they're closed under composition, so you can build arbitrary multi-modes. But this approach is, well, complicated. I'm not sure whether anyone's done it, even in research. (But I haven't searched the literature lately.) Robustness in the face of errors could be helped by something like http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.21.6885&rep=rep1&type=pdf One nice thing about using formal grammars is that you can analyze and transform them, e.g., using the autobracket transform in the previous paper, or even doing automatic semantic autocompletion. A much simpler approach I've also had in mind is providing a C-assisted incremental parser combinators facility to Lisp --- something like the venerable pyparsing. Parser combinators make it pretty easy to incorporate error recovery rules, and the C code can use approaches like current syntax-ppss to keep the parse up to date and maintain, cheaply, an AST.