From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jambunathan K Subject: Re: [RFC] Standardized code block keywords Date: Tue, 25 Oct 2011 12:54:51 +0530 Message-ID: <81ehy15y9o.fsf@gmail.com> References: <87pqhrih3s.fsf@gmail.com> <30891.1319141196@alphaville.dokosmarshall.org> <87fwinifqu.fsf@gmail.com> <32184.1319143892@alphaville.dokosmarshall.org> <808vofwf1w.fsf@somewhere.org> <87y5wfgwn7.fsf_-_@gmail.com> <87lise5muh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIbNm-0006h5-PU for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:25:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIbNl-0003kB-Jo for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:25:10 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:60151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIbNl-0003k3-ED for emacs-orgmode@gnu.org; Tue, 25 Oct 2011 03:25:09 -0400 Received: by ggnh4 with SMTP id h4so264472ggn.0 for ; Tue, 25 Oct 2011 00:25:09 -0700 (PDT) In-Reply-To: (Rainer M. Krug's message of "Tue, 25 Oct 2011 08:44:36 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer M Krug Cc: emacs-orgmode@gnu.org > #+object_begin var > x = 1 > y = 2 > #+end I was thinking on similar lines. This together with Nicolas's suggestion of "one name" will be wonderful. I think it is easier to explain what I think by means of an example. In case of lisp, the SAME variable name could either act as a function or a variable. The way the VARIABLE NAME is INTERPRETED, DEPENDS ON THE CONTEXT in which it needs to be interpreted. Similarly a VAR could be EVALLED or just be a QUOTED SYMBOL. Coming back to the above example - If the HANDLE for the above block (whatever you call it), appears as a PARAM OF BABEL CALL it would be interpreted as a param list. Think `apply' and `&rest args' in the elisp world. Another near equivalent would be COERCING or CASTING. In abstract terms, the above block could be treated as a TABLE. In some sense, a LIST or a LIST OF LIST could be coerced in to a TABLE. I consider babel to be a VM and an execution environment - i.e., as a scripting environment for Org. So definitely we can borrow ideas from the existing languages and extend it. In summary, what I am saying is EVERYTHING IS A BLOB. The way a BLOB is INTERPRETED depends on the CONTEXT in which interpretation happens. A BLOB in and of itself is but JUST A BLOB and has NO INHERENT meaning. I don't use babel myself so I may not be using the right set of words. Also it is not my intention to hijack the thread. Jambunathan K.