Skip to content

Latest commit

 

History

History
171 lines (130 loc) · 5.32 KB

goals.org

File metadata and controls

171 lines (130 loc) · 5.32 KB

RIO PL GOALS

RIO Programming Language design

RPython Io-like language

Inspirations

simple syntax

actor-model/futures and coroutines

prototype-based object model

differential inheritance

first class, dynamic message sending

homoiconicity

Every expression is a message, every value is an object

but even simpler: one single attribution operator

how can one expect me to remember between , : and ::= which creates, updates and creates setter

Python

Style, favored idioms

Zen of Python as a design guide

Self-documented

Fine balance between pragmatism and conceptual purity

Modularity and scopping rules

*args, **kwargs

[2016-01-01 sex 15:14] Maybe just *args, converting both positional and keyword arguments into a table-like data structure.

Fish Shell

No hidden or “advanced” features

Discoverability

Maximum comfort out of the box

Operator shuffling

Expressivity

Smalltalk

Integrated, live scriptable environment

Lisp

[2016-01-01 sex 15:00]

Explicit laziness (‘quoting)

[2016-01-01 sex 15:00]

Alias to “Core message(…)”

Haskell

Kinda like Multimethods (see also) or overloading

Lua

[2016-01-01 sex 15:03]

“Table”-like data structure

[2016-01-01 sex 15:03]

But with another name? “table” brings up 2D at least.
Maybe our table should support multiple dimensions.
Also, all items should be indexed by both a numeric index and a hashable arbitrary optional “key”.

In a way, it’s kinda like Python’s OrderedDict.

Indexing should be 0-based.
list and dict could be Core methods (Builtin/Lobby methods)

Coerce iterables to index-based only and key-based only tables.

New (?) ideas

[2016-01-01 sex 15:16]

‘quoting and ‘*multiquoting on method definition

[2016-01-01 sex 15:17] Passed arguments are passed as unevalued messages - useful for code blocks. Also, explicit is better than implicit. Block = list? So that ‘*multiquoting works for defining blocks

Core object and namespacing

Core is like Python’s builtin and Io’s Lobby

Trying to mimic Python’s semantic with less bytecode and more io-like

By default, the first message on a chain is addressed to Core
We are always pushing a namespace object on the stack when we start an expression
On module level: ‘(foo bar) -> ‘(Core foo bar)
“Local” namespace:
On module level, points directly to the Core object
Core local -> Core
On method level, “Core local” points to the local context object
Core local -> LocalNamespaceCore local self -> the object the current method belongs
methods that work as “class body” when cloning
nested functions, nonlocal

RIO Interpreter

lang-rio pypy target

parser unit tests

parser

Should parse at least the basic syntax described on the Io documentation, without strings. Use EBFN lib, generate an AST.

Parse integers, basic messages and blocks.

[2016-01-01 sex 15:25]

More tests

[2016-01-01 sex 15:27]

Complex messages

[2016-01-01 sex 15:29]

Code blocks

[2016-01-01 sex 15:30]

Arguments (single, multiple…)

[2016-01-01 sex 15:31]

basic compilation

actually interpret the basic language

Probably when we need an object space.

I/O support

add Text (unicode strings), other numeric types, ranges

add operator shuffling

To support basic C/Python-style algebraic syntaxes and boolean operators as method calls.

collections: tuples, tables

Coroutines

Basic coroutine support - should serve as basis for the scheduler, actors, futures

Write documentation

[2016-01-01 sex 19:03]

Tutorial (by examples), some design documents, a style guideline (for rpython and rio code)