{"id":1242,"date":"2010-12-19T21:51:06","date_gmt":"2010-12-20T02:51:06","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/?p=1242"},"modified":"2010-12-19T21:51:06","modified_gmt":"2010-12-20T02:51:06","slug":"apex-my-editor-project","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2010\/12\/19\/apex-my-editor-project\/","title":{"rendered":"Apex: My Editor Project"},"content":{"rendered":"

Lots of people were intrigued by my reference to my editor project. So I’m sharing the current language design with you folks. I’m calling it Apex<\/em>, as a homage to the brilliant Acme, which is the editor that comes closest to what I’d like to be able to use.<\/p>\n

So. The language for Apex is sort of a combination of TECO<\/a> and Sam<\/a>. Once the basic system is working, I’m planning on a UI that’s modeled on Acme<\/a>. For now, I’m going to focus on the language.<\/p>\n

<\/p>\n

Goals<\/h3>\n

It’s always good to be clear about what you’re trying to do. So for the Apex command language, my goals are:<\/p>\n

    \n
  1. Conciseness<\/b>: since I’m planning on using this for all of my everyday programming, it’s really important for it to be concise. It doesn’t matter if it’s easy to read if I need to type something like forall match in regexp.match(\"foo\") do match.replace(\"bar\") end<\/code>. It’s just too damned much typing for an everyday task. In what I describe below, a global search and replace is g\/foo\/,{r'bar'}<\/code>.<\/li>\n
  2. Consistency<\/b>: everything works in roughly the same way. Everything can succeed or fail, and all of the semantics are based around that idea. Everything that takes parameters takes parameters in the same way. If something works in one context, it’ll work in another. <\/li>\n
  3. Clarity<\/b>: if you look at the code fragments below, this one takes a bit of explanation. The conciseness of the syntax means that to someone who isn’t familiar with the language, it’s going to be absolutely impossible to read. But the way that things work is straightforward, and so once you understand the basic \tideas of the syntax, you can easily read a program. It’s not like TECO where you need to know the specific command in order to have a clue of what it does. And the parser can look at an entire program, and tell you before executing any of it whether it’s got a syntax error.<\/li>\n<\/ol>\n

    Syntax<\/h3>\n

    The syntax for commands is: <\/p>\n

    \nstmt: sub | command\n\nsub: 'sub'  sub_params FUN_IDENT sub_params '{' command '}'\n\nsub_params : '(' ( VAR_IDENT ( ',' VAR_IDENT )*  )?  ')'\n\ncommand : choice_command ( '?' simple_command ':' simple_command )\n\nchoice_command : seq_command ('^' seq_command)*\n\nseq_command : simple_command ( '&' simple_command )*\n\nsimple_command : atomic_command\n               | '[' command ']'\n\n\natomic_command: ( params )? command_name ( post_params )?\n\t      |  params '!' VAR_IDENT\n\npost_params: post_param (',' post_param)*\n\npost_param: QUOTED_STRING\n          | PATTERN\n          | block\n          | '$(' expr ')'\n\nparams\t: NUMERIC_LITERAL\n        | '(' ( expr ( ',' expr )* )? ')'\n\nquoted_param: QUOTE_CHAR  ( NON_QUOTE_CHAR )* QUOTE_CHAR\n            | '(' expr ')'\n\n\nexpr : NUMERIC_LITERAL\n     | QUOTED_STRING\n     | funcall\n     | block\n     | command\n     | VAR_IDENT\n\n\nfuncall: params FUN_IDENT ( quoted_param )?\n\nblock : '{' ( '|'  VAR_IDENT (',' VAR_IDENT)*  '|' )?\n            command '}'\n\nFUN_IDENT = '@' [A-Za-z_+-*\/=!%^&><]+\n\nVAR_IDENT = '$' [A-Za-z_]+\n<\/pre>\n
    Commands<\/h3>\n
     This is a language focused on text editing, so the core of it is built around buffers. All of the language constructs implicitly work on a buffer. Within the buffer, you have a focus<\/em>. The focus is the current location of the cursor. The interesting bit, though, is that the cursor isn’t necessarily between<\/em> two characters. It can span over a range of text, all of which is under the cursor. In other words, the the currently selected range of text and the cursor are the same thing.<\/p>\n
     Commands all work in terms of either moving the cursor, or modifying the contents of the cursor. Most commands have a long name, and a short abbreviated name.<\/p>\n
    \n
    Cursor Motion<\/b><\/dt>\n
    \n
    \n
    Pattern Search<\/b>: s+\/pattern\/<\/code><\/dt>\n
     Moves the cursor so that it covers the next instance of the pattern in the current buffer. Returns the start position of the match. There’s also a “s-” version, which looks for the previous instance of the match.<\/dd>\n
     move<\/b>: number<\/em> m unit<\/em><\/code><\/dt>\n
     Moves the cursor by a specified distance. The units are c<\/code> (for characters), l<\/code> (for lines), or p<\/code> (for pages). So 3ml<\/code> means “move the cursor” forward three lines. Returns the start position of the cursor after the move.<\/dd>\n
     jump<\/b>: number<\/em> j unit<\/em><\/code><\/dt>\n
     Jumps the cursor to a specific position. The units are the same as for the m<\/code> command, where “character” units specify column numbers. Returns the <\/dd>\n
    extend<\/b>: e motion-command<\/em><\/code> <\/dt>\n
     Extend cursor. The cursor is extended by the effect of the following command. So, for example, since 3mc<\/code> is a command that means “move the cursor forward three characters, 3emc<\/code> is a command that means “extend the cursor forward by three characters – it moves the end-point of the cursor forward by three, without changing thestart. -3eml<\/code> adds the previous three lines to the cursor. es+\/foo\/<\/code> extends the cursor to include the next match for “foo”.<\/dd>\n
    pick<\/b>: (expr, expr)p<\/code><\/dt>\n
     Selects a range of text as the current cursor. Each \texpression is interpreted as a location.  (3lj,4pj)p<\/code> covers the range from the \tbeginning of the third line, to the end of the fourth page. \t(s+\/foo\/, s+\/bar\/)p<\/code> covers the range from the beginning of the first match of “foo” to the end of the first match of “bar”.<\/dd>\n
    selectall<\/b>: *<\/code><\/dt>\n
     Makes the current cursor cover the entire buffer.<\/dd>\n<\/dl>\n<\/dd>\n
    Edits<\/b><\/dt>\n
    \n
    \n
    delete<\/b>: d<\/code><\/dt>\n
     Delete the contents of the cursor. If it’s followed by a variable name, then the deleted text is inserted into that variable.<\/dd>\n
    copy<\/b>: c$var<\/code><\/dt>\n
     Copy the contents of the selection into a variable.<\/dd>\n
    insert<\/b>: i'text'<\/code> <\/dt>\n
     Inserts text before<\/em> the cursor. The quote character can actually be any character: the first character after an i<\/code> is the delimiter, and the insert string runs to the next instance of that delimiter.<\/dd>\n
    append<\/b>: a'text'<\/code><\/dt>\n
     Appends text after<\/em> the cursor. Quotes work just like\ti<\/code>.<\/dd>\n
    replace<\/b>: r'text'<\/code><\/dt>\n
     Replaces the current contents of the cursor with the new
    \n\ttext.<\/dd>\n<\/dl>\n<\/dd>\n
    Control Flow<\/b><\/dt>\n
    \n
    \n
    global<\/b>: g\/pattern\/,block<\/code><\/dt>\n
     A simple loop construct. For each match of the pattern within the current cursor, execute the block. So, for example, to do a global search and replace of foo with bar, * g\/foo\/,{r'bar'}<\/code>.<\/dd>\n
    stmt ^ stmt<\/code><\/dt>\n
     Choice\/logical or statement: any statement can either succeed or fail. ^<\/code> allows you to combine statements so that the second one only executes if the first one fails. The statement\tas a whole succeeds if either the first or second statement succeeds. Ret turns the value of the statement that succeeds.<\/dd>\n
    stmt & stmt<\/code><\/dt>\n
     Sequencing\/logical and. The second statement will only be executed if the first one succeeds, and the entire statement succeeds only if both succeed. Returns the value of the second statement.<\/dd>\n
    ( stmt )<\/code><\/dt>\n
     Should be obvious, eh?<\/dd>\n
     stmt1 ? stmt2 : stmt3<\/code><\/dt>\n
    If-then-else. A simple if-then without an else is just a ,<\/code> sequence. You can get an if-then-else effect\twithout this, but it’s tricky enough to justify adding this.<\/dd>\n
    loop<\/b>: l{block}<\/code><\/dt>\n
     A general loop. Executes the block over and over as long as it succeeds.<\/dd>\n
    execute<\/b>: x block<\/em><\/code><\/dt>\n
     Executes the block on the current cursor. The contents of the current cursor becomes the target buffer of the body of the block, and the cursor is set to position 0 of that target buffer.  <\/dd>\n<\/dl>\n<\/dd>\n
    Variables<\/b><\/dt>\n
    \n
    \n
    $ident<\/code><\/dt>\n
     Any symbol starting with a $<\/code> is a variable. In an expression, a variable name evaluates to its value.<\/dd>\n
    set!<\/b>: expr!$ident<\/code><\/dt>\n
     Assign the result of executing the preceeding expression to a variable. If the variable is already defined in this scope, or in any enclosing scope, update it; otherwise, create a new local variable.<\/dd>\n<\/dl>\n<\/dd>\n
    External Interaction<\/b><\/dt>\n
    \n
    \n
    <'shellcommand'<\/code><\/dt>\n
    Execute shellcommand<\/code> in an external shell, and\tinsert the standard out from the command into the position at the start of the current cursor; then set the cursor to cover the inserted text.<\/dd>\n
    <<'shellcommand'<\/code><\/dt>\n
    Some as the < command, except that it also inserts the contents of stderr from the shell command.<\/dd>\n
    |'shellcommand'<\/code><\/dt>\n
    Execute shellcommand<\/code>, with the current cursor as its standard input, and replace the contents of the cursor with the standard output.<\/dd>\n
    ||'shellcommand'<\/code><\/dt>\n
    Same as |<\/code>, except that it also inserts the contents of stderr.<\/dd>\n<\/dl>\n<\/dd>\n
    I\/O<\/b><\/dt>\n
    \n
    \n
    write<\/b>: w<\/code><\/dt>\n
     Write the current buffer out to a file. If no filename is specified, then use the buffer’s associated filename. If a filename is specified, then write it to that file, and update the buffer’s filename to match the written name.<\/dd>\n
    open<\/b>: o'filename'<\/code><\/dt>\n
     Open a file in a new buffer.<\/dd>\n
    revert<\/b>: v<\/code><\/dt>\n
     Discard all changes to this buffer.<\/dd>\n<\/dl>\n<\/dd>\n<\/dl>\n
    Expressions<\/h3>\n
     In general, any command is also usable an expression. Every command returns a value: motion commands return the new cursor position; edit commands return any deleted text, or the size of the change.<\/p>\n
     Control statements don’t depend on true and false values; instead,  they’re defined in terms of success and failure. Any statement can succeed or fail.<\/p>\n
     Arithmetic is done using built-in functions.<\/p>\n
    Blocks<\/h3>\n
     A lot of statements take block<\/em> parameters. A block is an executable code fragment. Blocks are enclosed in braces. They always implicitly take the current cursor as a parameter. In the case of the “x” and “g” commands, the block is executed using the current selection as if it were the entire buffer. In addition to the selection, a block can take additional parameters. They’re written   by enclosing them in “|”s at the beginning of the block. For example,  you could define a block that returned the sum of its parameters by writing:<\/p>\n
    \n  {|$x, $y| ($x,$y)@+ }\n<\/pre>\n
     Parameters for a block preceed<\/em> its call. So to invoke the block above, you could use: (3,2)x{|$x,$y| ($x,$y)@+)}<\/block>, which would then return 5.<\/p>\n
     Blocks are lexically scoped; a block declared inside of another block can access variables from that enclosing block.  <\/p>\n
     You can declare named subroutine. A named subroutine is mostly syntactic sugar  for a block. The main difference is that if you go to the trouble of creating a named subroutine, then you can declare both prefix and postfix parameters.  The names of named subroutines always start with an “@” symbols. A named subroutine just associates a  global name with a block. <\/p>\n
    \n  fun ($x) @fact {($x,0)@= ? {1} : { ($x, ($x,1)@-@fact)@* }\n<\/pre>\n
     When calling a block, the parameters preceed it. So to get the  factorial of 10, you’d write 10@fact<\/code>.<\/p>\n
     For numeric arguments to commands, you can just put the expression before the command instead of a number. For example, to move to line fact(4), you’d write: 4@fact jl<\/code>. For string parameters that appear in quoted positions, if you use an “$()” instead of a quote character, then the contents are evaluated as an expression, and the result is used as the string parameter value. So to insert the string<\/em> “5@fact”, you could write i'5@fact'<\/code>. To insert the result of evaluating it, you’d write “i$(5@fact)<\/code>“.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Lots of people were intrigued by my reference to my editor project. So I’m sharing the current language design with you folks. I’m calling it Apex, as a homage to the brilliant Acme, which is the editor that comes closest to what I’d like to be able to use. So. The language for Apex is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[54],"tags":[103,146,190,226,242],"class_list":["post-1242","post","type-post","status-publish","format-standard","hentry","category-programming","tag-apex","tag-editor","tag-language","tag-sam","tag-teco"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-k2","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/1242","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=1242"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/1242\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=1242"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=1242"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=1242"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}