builtins.rst

Consider one single vat. There are objects in this vat. With the exception of some types, listed below, all objects are made of pure S code. The difference between a builtin type and an object made from S code is not visible from within the object space; for all objects, only message passing can be used to communicate and no object introspection is possible.

Note that "type" simply means "a template for an object." There is no visible difference between a function which returns an object and a type, nor is there any typechecking per se.

Here are some builtin types. This list is not yet exhaustive, but it won't get much longer. Types without literal syntax have a + next to them, and have quasiliteral syntax instead.

• int
• float
• str: Unicode strings.
• bytes+: Bytestrings. bytes is important because it is the type of objects which are used as identifiers and message names.
• list: An immutable ordered sequence. Performance is not specified.
• set: An immutable unordered unique collection.
• dict: An immutable hash table.
• hash+: Cryptographic (and non-cryptographic) hash functions.
• crypt+: Encryption primitives.
• regex+: Regular expressions.
• filepath+: Paths on the virtual filesystem. (More VFS discussion later.)

Discussion

• I'd like to have a numeric tower. The benefits are just too great, and the downsides are negligible. I think that 99% of complaints are solved by having both / and // for division.
• Ugh, strings suck so hard. Unicode is essential these days, but Unicode source sucks from a readability and security standpoint. Message passing by attribute needs to desugar cleanly and predictably, so message names should be bytes, riiight?
• Regexes are popular literal objects in several popular languages (Perl, Lua, ES). I'm not a fan. Opinions?
  • Resolved: Regexes will be available with QL syntax.
• XML literals in ES are actually really cool, but at the same time, people swear that ES supports JSON literals. Wonder if we should even bother with either?
  • Resolved: XML and JSON will be standard library objects.
• Should all builtin objects have literal syntax?
  • Resolved: No.

corbin-wishlist.rst

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." ~ Buckminster Fuller

• Semantics
  • Any semantics would be nice. Any at all. This should be simpler than, not more complex than, Python.
  • Modules and packages need to be saner than Python's.
    • Go back and read through Erlang and E's modules and see how they're handled.
• Syntax
  • We definitely want inline PEG compound statements. What should they be called? "parser", "grammar", "ometa", "peg"...
  • Modules should only have one single canonical import name.
  • Ejectors: Explicitly-passed delimited continuations. This is a little iffy because they have to be explicitly introduced into every frame...
• Types
  • A filepath type would be superb, especially if it can encapsulate all of the nastiness that one has to put up with when Win32 and OSX enter the mix.
  • Interfaces?
• Networking
  • Adoption of tubes
• Questions to Unask: These questions shouldn't be askable in GF
  • "How do I write a plugin loader?"
  • "How do I write an IRC bot?"
• Improvements: The answers to these questions should be a lot better in GF than in Python
  • "How can I iterate through a list and get l[x], l[x+1], etc. on each iteration?"
• Examples
  • Twisted's examples
  • Ostiary
  • Erlang examples?
  • http://paste.pound-python.org/show/33657/ should be shredded by the compiler

old_rationale.txt

GREYFACE is a variant of Python without the interesting or fun
parts. GREYFACE is for people who think programming is Serious
Business.
**** No classes, just objects
The confusion produced by the differences between classes and
instances of classes is needless. GREYFACE removes it. If you want
more than one instance of an object, write a function or method that
creates it.
**** Objects don't expose their internals
Monkey patching is too exciting, so GREYFACE prohibits it.
**** Modules are immutable, Exocet-style
**** Immutable containers by default
Lists, dicts, and sets shouldn't be modifiable unless you specifically ask for it.
**** Interfaces and guard (aka annotation) syntax
**** 'let'/'var' for variable declaration - no more 'global'/'nonlocal'
**** No callback bullshit, promises built in
Promises convert to the values they resolve to. 'when'/'catch' make
avoiding the pyramid of doom easier.
**** Quasiliterals, for easy structured management of string formats
**** OMeta syntax included for easy parser building

**** ... and no blocking IO. event loop built in

*** Design issues
**** Prevent pickle by default, provide uncall-based opt-in for serialization
**** Generators? No generators?
**** ITERATORS OMG
***** internal vs external iteration: Python uses external, E uses internal
***** GREYFACE: external plus OMeta
**** use (do:) for SeqExpr
**** {} for maps/sets
**** list/dict comprehensions (damn the consistency issues)
**** ometa syntax
**** 'object' for object literals, or just 'def'?
**** preserve 'to'/'method'/'match' for now

rationale.txt

GREYFACE, a language for distributed systems

Syntax

Lexical conventions are very close to Python. The biggest visible differences are:

Variables

GREYFACE distinguishes between variable declaration and assignment, using ‘var x = …’ and ‘x = …’ for each. Additionally, read-only names can be declared using ‘def x = ….’.

decide if anything other than functions/comprehensions introduce scope

Literals

GREYFACE has no literal syntax for mutable objects. […] produces immutables lists (similar to tuples), {k:v, … } produces immutable ordered maps, and {x, y, ….} produces immutable ordered sets. Each of these types implement a ‘diverge’ method to get a mutable object of the same contents. Use of immutable lists replaces tuples: comma is not an operator in GREYFACE.

Objects

GREYFACE does not provide classes, using the ‘object’ keyword to create an individual object instead; creation of multiple objects of the same kind is done by creating an object in a function.

Methods

decide on keyword for methods

decide if E’s ‘to’/’method’ distinction is valuable

Concurrency

All code runs in the context of some event loop. Multiple event loops can run in a single OS process but their objects are isolated from each other in “vats”, a la Erlang processes. Ony immutable data can be sent between vats.

Module system

GREYFACE distinguishes between modules as containers of code that can be loaded and modules as namespaces for objects, and provides an API for inspecting the dependencies and exports of a module without executing the code in it. A default module loading context is provided but you can construct your own.

When a module is compiled, all ‘import’ statements (whether in functions or at toplevel scope) are collected to produce a list of names the module depends on. An ‘export’ statement, if present, can be inspected before load; additionally, it will limit the names provided by the resultant module object.

develop good names for ‘module before eval’ and ‘module object produced by eval’