Datetime literals: 

2006-05-17T
2006-05-17T13:10
2006-05-17T13:10Z
2006-05-17T11:10-02:00
2006-05-17T18:10+05:00

Op methods and Barenames: 

Operators will have to have method names a la __add__ in Python for +.
Javascript 2 will use + as method name, but that means + will be taken in that
scope, which is weird.

+ plus
- minus
* star
/ slash
& and
| pipe
% percent
^ hat
< less
> greater

For any that can be doubled, prepend "double". Examples: 

&& doubleand
|| doublepipe

Star is from Larry Wall's "STAR" language, and hat is from the Esperantoists'
name for the circumflex. Yes, they're cute. Programming languages can be cute.

Provide etc.

Barenames: 

To be only [a-z][A-Za-z]*, no underscores, certainly no hyphens although lisp
seems to be okay with them and if I'm worried about the minus problem I
probably have to get rid of the datetime native lexical datatype.

Er, actually, it will be [A-Za-z]+ because of prototype names, and new should
presumably enforce the capitalisation. That doesn't stop non-prototypes from
being given capital names though--not sure how that should be enforced, or even
whether it should be.

Still not sure about new. Perhaps there could be an operator for it that acts a
bit like a sigil? OR even just a sigil for it. &? !?

plus = { Plus! }

It could even be put in the assignment, like my quoted assign format: 

plus => Plus

But that looks like implies. The arrow could be the other way.

plus <= Plus

Heh, how about an empty Table...

plus = Plus()

Or, woah, since the constructor will be able to take args...

person = Person("John Cowan")

Whoo!

Oh yeah, flags too on the minus problem.

#!/usr/bin/env pluvo

% grep.lu - Grep Some Files
Author: Sean B. Palmer, inamidst.com

usage "grep.lu [options] <pattern> <filenames>"
options { 
   -h/--help  "Display a help message"
   -t/--test  "Perform builtin code tests"
}

grep = (filenames pattern) { 
   % "Grep through filenames for pattern"
   example { 
      grep(("pluvo://document/") "pqr")
      => "1. pqrst" 
   }

   for (fn) filenames { 
      for <$fn> { 
         if {/$pattern/ arg} { out arg }
      }
   }
}

main = (argv) {
   --help or {argv < 3} { help }
   --test { check grep; quit }
   grep {@args:2:} {@args:1}
}

script main

Here's the way we're leading up to doing factorial: 

factorial = (n) {
   n = { run n }
   if {n == 0} { return 1 }
   n * { factorial { n - 1 } }
}

This is rather like many of the builtin functions that evaluate codeblocks
given to them as arguments, and it's a pain to have to specify that you want to
evaluate them when they're almost always going to be evaluated. This could be
default, and then if you want a quoted argument you can have that through on
the argspec. That'll mean that env.evaluate will have to do the work there
though. At least it's something that can be done after coordination, and just
before the callable is called. Though evaluate doesn't have the argspec to play
with directly, it can just do function.get('argspec') and then inspect it that
way. In other words, it's after the coordinate/decline stage and hence should
probably be done outside of coordinate and back in evaluate, which is where the
arguments get munged.

Perhaps {arg} can specify a quoted arg on the argspec. So for example: 

mysay = (arg) { 
   say arg
}
mysay { 5 + 3 }
=> 8

but: 

mysay = ({arg}) {
   say arg
}
mysay { 5 + 3 }
=> [codeblock]

I think there's at least builtin that takes raw blocks... Oh, well, equals
certainly wants a raw block.

equals = (var argspec {block}) { ... }

On the other hand, that kinda wants all sorts of stuff, so its argspec would be
more like (var {arg}*). Postpending rather than prepending the * is a good idea
given regular expressions etc. And of course codeblocks in () don't get
expanded, otherwise ({arg}*) would not be possible itself.

For an example of self-modifying code, perhaps some that spellchecks itself or
something along those lines? It could use py.difflib.get_close_matches for the
checking feeding in current variable names.

-- 
Sean B. Palmer, inamidst.com