mirror of
https://github.com/urbit/shrub.git
synced 2024-09-11 12:25:43 +03:00
Cleaning up old code
This commit is contained in:
Christian Carter
parent
e4eae49cf9
commit
3af3130bdc
7
.gitignore
vendored
Normal file
7
.gitignore
vendored
Normal file
@ -0,0 +1,7 @@
|
||||
*.o
|
||||
.gdb_history
|
||||
generated
|
||||
run
|
||||
bin
|
||||
*.swp
|
||||
.*tags
|
||||
807
Makefile
Normal file
807
Makefile
Normal file
@ -0,0 +1,807 @@
|
||||
# A simple makefile.
|
||||
#
|
||||
|
||||
# Pick one of:
|
||||
# linux
|
||||
# osx
|
||||
|
||||
UNAME=$(shell uname)
|
||||
ifeq ($(UNAME),Darwin)
|
||||
OS=osx
|
||||
else ifeq ($(UNAME),Linux)
|
||||
OS=linux
|
||||
else
|
||||
$(error unknown unix)
|
||||
endif
|
||||
|
||||
# Pick one of:
|
||||
# little
|
||||
# big
|
||||
#
|
||||
ENDIAN=little
|
||||
|
||||
# Binary directory - not in quotes.
|
||||
#
|
||||
BIN=bin
|
||||
|
||||
# Library directory - from whence resources are now loaded.
|
||||
#
|
||||
LIB=$(PWD)/lib
|
||||
|
||||
RM=rm -f
|
||||
CC=gcc
|
||||
CLD=gcc -O3 -L/usr/local/lib -L/opt/local/lib
|
||||
YACC=bison -v -b$(GENERATED)/y
|
||||
LEX=lex
|
||||
|
||||
ifeq ($(OS),osx)
|
||||
CLDOSFLAGS=-bind_at_load
|
||||
OSLIBS=-framework CoreServices -framework CoreFoundation
|
||||
endif
|
||||
ifeq ($(OS),linux)
|
||||
OSLIBS=-lcrypto -lpthread -lrt -lcurses
|
||||
endif
|
||||
|
||||
LIBS=-lgmp -ltermcap -lsigsegv $(OSLIBS)
|
||||
|
||||
INCLUDE=include
|
||||
GENERATED=generated
|
||||
DEFINES=-DU2_OS_$(OS) -DU2_OS_ENDIAN_$(ENDIAN) -D U2_LIB=\"$(LIB)\"
|
||||
|
||||
CFLAGS=-O3 \
|
||||
-I/usr/local/include \
|
||||
-I/opt/local/include \
|
||||
-I$(INCLUDE) \
|
||||
-Ioutside/libuv/include \
|
||||
-I $(GENERATED) \
|
||||
$(DEFINES)
|
||||
|
||||
CWFLAGS=-Wall
|
||||
|
||||
.y.o:
|
||||
mkdir -p $(GENERATED)
|
||||
$(YACC) $<
|
||||
$(CC) -c $(CFLAGS) -o $@ $(GENERATED)/y.tab.c
|
||||
$(RM) $(GENERATED)/y.tab.c
|
||||
|
||||
.c.o:
|
||||
$(CC) -c $(CWFLAGS) $(CFLAGS) -o $@ $<
|
||||
|
||||
F_OFILES=\
|
||||
f/rail.o \
|
||||
f/loom.o \
|
||||
f/wire.o \
|
||||
f/chad.o \
|
||||
f/cash.o \
|
||||
f/coal.o \
|
||||
f/hevn.o \
|
||||
f/host.o \
|
||||
f/benx.o \
|
||||
f/trac.o \
|
||||
f/bail.o \
|
||||
f/dash.o \
|
||||
f/unix.o \
|
||||
f/nock.o
|
||||
|
||||
J195_1_OFILES=\
|
||||
gen195/1/add.o \
|
||||
gen195/1/dec.o \
|
||||
gen195/1/div.o \
|
||||
gen195/1/gte.o \
|
||||
gen195/1/gth.o \
|
||||
gen195/1/lte.o \
|
||||
gen195/1/lth.o \
|
||||
gen195/1/mod.o \
|
||||
gen195/1/mul.o \
|
||||
gen195/1/sub.o
|
||||
|
||||
J195_2_OFILES=\
|
||||
gen195/2/bind.o \
|
||||
gen195/2/clap.o \
|
||||
gen195/2/drop.o \
|
||||
gen195/2/flop.o \
|
||||
gen195/2/lent.o \
|
||||
gen195/2/levy.o \
|
||||
gen195/2/lien.o \
|
||||
gen195/2/need.o \
|
||||
gen195/2/reel.o \
|
||||
gen195/2/roll.o \
|
||||
gen195/2/skim.o \
|
||||
gen195/2/skip.o \
|
||||
gen195/2/slag.o \
|
||||
gen195/2/snag.o \
|
||||
gen195/2/sort.o \
|
||||
gen195/2/turn.o \
|
||||
gen195/2/weld.o
|
||||
|
||||
J195_3_OFILES=\
|
||||
gen195/3/bex.o \
|
||||
gen195/3/can.o \
|
||||
gen195/3/cap.o \
|
||||
gen195/3/cat.o \
|
||||
gen195/3/con.o \
|
||||
gen195/3/cut.o \
|
||||
gen195/3/dor.o \
|
||||
gen195/3/dis.o \
|
||||
gen195/3/end.o \
|
||||
gen195/3/gor.o \
|
||||
gen195/3/hor.o \
|
||||
gen195/3/lsh.o \
|
||||
gen195/3/mas.o \
|
||||
gen195/3/met.o \
|
||||
gen195/3/mix.o \
|
||||
gen195/3/mug.o \
|
||||
gen195/3/peg.o \
|
||||
gen195/3/rap.o \
|
||||
gen195/3/rip.o \
|
||||
gen195/3/rsh.o \
|
||||
gen195/3/vor.o
|
||||
|
||||
J195_4_OFILES=\
|
||||
gen195/4/in.o \
|
||||
gen195/4/by.o \
|
||||
gen195/4/in_has.o \
|
||||
gen195/4/in_gas.o \
|
||||
gen195/4/in_put.o \
|
||||
gen195/4/in_tap.o \
|
||||
gen195/4/by_gas.o \
|
||||
gen195/4/by_get.o \
|
||||
gen195/4/by_has.o \
|
||||
gen195/4/by_put.o
|
||||
|
||||
J195_5_OFILES=\
|
||||
gen195/5/cue.o \
|
||||
gen195/5/jam.o \
|
||||
gen195/5/mat.o \
|
||||
gen195/5/mock.o \
|
||||
gen195/5/parse.o \
|
||||
gen195/5/rub.o \
|
||||
gen195/5/shax.o \
|
||||
gen195/5/trip.o
|
||||
|
||||
J195_6_OFILES=\
|
||||
gen195/6/ap.o \
|
||||
gen195/6/cell.o \
|
||||
gen195/6/comb.o \
|
||||
gen195/6/cons.o \
|
||||
gen195/6/core.o \
|
||||
gen195/6/cube.o \
|
||||
gen195/6/face.o \
|
||||
gen195/6/fine.o \
|
||||
gen195/6/fitz.o \
|
||||
gen195/6/flan.o \
|
||||
gen195/6/flay.o \
|
||||
gen195/6/flip.o \
|
||||
gen195/6/flor.o \
|
||||
gen195/6/fork.o \
|
||||
gen195/6/hike.o \
|
||||
gen195/6/look.o \
|
||||
gen195/6/ut.o
|
||||
|
||||
J195_6_OFILES_UT=\
|
||||
gen195/6/ut_burn.o \
|
||||
gen195/6/ut_bust.o \
|
||||
gen195/6/ut_crop.o \
|
||||
gen195/6/ut_cull.o \
|
||||
gen195/6/ut_find.o \
|
||||
gen195/6/ut_fink.o \
|
||||
gen195/6/ut_fire.o \
|
||||
gen195/6/ut_firm.o \
|
||||
gen195/6/ut_fish.o \
|
||||
gen195/6/ut_fuse.o \
|
||||
gen195/6/ut_gain.o \
|
||||
gen195/6/ut_heal.o \
|
||||
gen195/6/ut_lose.o \
|
||||
gen195/6/ut_mint.o \
|
||||
gen195/6/ut_moot.o \
|
||||
gen195/6/ut_mull.o \
|
||||
gen195/6/ut_nest.o \
|
||||
gen195/6/ut_park.o \
|
||||
gen195/6/ut_peek.o \
|
||||
gen195/6/ut_play.o \
|
||||
gen195/6/ut_repo.o \
|
||||
gen195/6/ut_rest.o \
|
||||
gen195/6/ut_seek.o \
|
||||
gen195/6/ut_snap.o \
|
||||
gen195/6/ut_swab.o \
|
||||
gen195/6/ut_tack.o \
|
||||
gen195/6/ut_tock.o \
|
||||
gen195/6/ut_wrap.o
|
||||
|
||||
J195_OFILES=\
|
||||
$(J195_1_OFILES) \
|
||||
$(J195_2_OFILES) \
|
||||
$(J195_3_OFILES) \
|
||||
$(J195_4_OFILES) \
|
||||
$(J195_5_OFILES) \
|
||||
$(J195_6_OFILES) \
|
||||
$(J195_6_OFILES_UT) \
|
||||
gen195/watt.o
|
||||
|
||||
J194_1_OFILES=\
|
||||
gen194/1/add.o \
|
||||
gen194/1/dec.o \
|
||||
gen194/1/div.o \
|
||||
gen194/1/gte.o \
|
||||
gen194/1/gth.o \
|
||||
gen194/1/lte.o \
|
||||
gen194/1/lth.o \
|
||||
gen194/1/mod.o \
|
||||
gen194/1/mul.o \
|
||||
gen194/1/sub.o
|
||||
|
||||
J194_2_OFILES=\
|
||||
gen194/2/bind.o \
|
||||
gen194/2/clap.o \
|
||||
gen194/2/drop.o \
|
||||
gen194/2/flop.o \
|
||||
gen194/2/lent.o \
|
||||
gen194/2/levy.o \
|
||||
gen194/2/lien.o \
|
||||
gen194/2/need.o \
|
||||
gen194/2/reel.o \
|
||||
gen194/2/roll.o \
|
||||
gen194/2/skim.o \
|
||||
gen194/2/skip.o \
|
||||
gen194/2/slag.o \
|
||||
gen194/2/snag.o \
|
||||
gen194/2/sort.o \
|
||||
gen194/2/turn.o \
|
||||
gen194/2/weld.o
|
||||
|
||||
J194_3_OFILES=\
|
||||
gen194/3/bex.o \
|
||||
gen194/3/can.o \
|
||||
gen194/3/cap.o \
|
||||
gen194/3/cat.o \
|
||||
gen194/3/con.o \
|
||||
gen194/3/cut.o \
|
||||
gen194/3/dor.o \
|
||||
gen194/3/dis.o \
|
||||
gen194/3/end.o \
|
||||
gen194/3/gor.o \
|
||||
gen194/3/hor.o \
|
||||
gen194/3/lsh.o \
|
||||
gen194/3/mas.o \
|
||||
gen194/3/met.o \
|
||||
gen194/3/mix.o \
|
||||
gen194/3/mog.o \
|
||||
gen194/3/peg.o \
|
||||
gen194/3/rap.o \
|
||||
gen194/3/rip.o \
|
||||
gen194/3/rsh.o \
|
||||
gen194/3/vor.o
|
||||
|
||||
J194_4_OFILES=\
|
||||
gen194/4/in.o \
|
||||
gen194/4/by.o \
|
||||
gen194/4/in_has.o \
|
||||
gen194/4/in_gas.o \
|
||||
gen194/4/in_put.o \
|
||||
gen194/4/in_tap.o \
|
||||
gen194/4/by_gas.o \
|
||||
gen194/4/by_get.o \
|
||||
gen194/4/by_has.o \
|
||||
gen194/4/by_put.o
|
||||
|
||||
J194_5_OFILES=\
|
||||
gen194/5/cue.o \
|
||||
gen194/5/jam.o \
|
||||
gen194/5/mat.o \
|
||||
gen194/5/mock.o \
|
||||
gen194/5/parse.o \
|
||||
gen194/5/rub.o \
|
||||
gen194/5/shax.o \
|
||||
gen194/5/trip.o
|
||||
|
||||
J194_6_OFILES=\
|
||||
gen194/6/ap.o \
|
||||
gen194/6/cell.o \
|
||||
gen194/6/comb.o \
|
||||
gen194/6/cons.o \
|
||||
gen194/6/core.o \
|
||||
gen194/6/cube.o \
|
||||
gen194/6/face.o \
|
||||
gen194/6/fine.o \
|
||||
gen194/6/fitz.o \
|
||||
gen194/6/flan.o \
|
||||
gen194/6/flay.o \
|
||||
gen194/6/flip.o \
|
||||
gen194/6/flor.o \
|
||||
gen194/6/fork.o \
|
||||
gen194/6/hike.o \
|
||||
gen194/6/look.o \
|
||||
gen194/6/ut.o
|
||||
|
||||
J194_6_OFILES_UT=\
|
||||
gen194/6/ut_burn.o \
|
||||
gen194/6/ut_bust.o \
|
||||
gen194/6/ut_crop.o \
|
||||
gen194/6/ut_cull.o \
|
||||
gen194/6/ut_find.o \
|
||||
gen194/6/ut_fink.o \
|
||||
gen194/6/ut_fire.o \
|
||||
gen194/6/ut_firm.o \
|
||||
gen194/6/ut_fish.o \
|
||||
gen194/6/ut_fuse.o \
|
||||
gen194/6/ut_gain.o \
|
||||
gen194/6/ut_heal.o \
|
||||
gen194/6/ut_lose.o \
|
||||
gen194/6/ut_mint.o \
|
||||
gen194/6/ut_moot.o \
|
||||
gen194/6/ut_mull.o \
|
||||
gen194/6/ut_nest.o \
|
||||
gen194/6/ut_park.o \
|
||||
gen194/6/ut_peek.o \
|
||||
gen194/6/ut_play.o \
|
||||
gen194/6/ut_repo.o \
|
||||
gen194/6/ut_rest.o \
|
||||
gen194/6/ut_seek.o \
|
||||
gen194/6/ut_snap.o \
|
||||
gen194/6/ut_swab.o \
|
||||
gen194/6/ut_tack.o \
|
||||
gen194/6/ut_tock.o \
|
||||
gen194/6/ut_wrap.o
|
||||
|
||||
J194_OFILES=\
|
||||
$(J194_1_OFILES) \
|
||||
$(J194_2_OFILES) \
|
||||
$(J194_3_OFILES) \
|
||||
$(J194_4_OFILES) \
|
||||
$(J194_5_OFILES) \
|
||||
$(J194_6_OFILES) \
|
||||
$(J194_6_OFILES_UT) \
|
||||
gen194/watt.o
|
||||
|
||||
J193_1_OFILES=\
|
||||
gen193/1/add.o \
|
||||
gen193/1/dec.o \
|
||||
gen193/1/div.o \
|
||||
gen193/1/gte.o \
|
||||
gen193/1/gth.o \
|
||||
gen193/1/lte.o \
|
||||
gen193/1/lth.o \
|
||||
gen193/1/mod.o \
|
||||
gen193/1/mul.o \
|
||||
gen193/1/sub.o
|
||||
|
||||
J193_2_OFILES=\
|
||||
gen193/2/bind.o \
|
||||
gen193/2/clap.o \
|
||||
gen193/2/drop.o \
|
||||
gen193/2/flop.o \
|
||||
gen193/2/lent.o \
|
||||
gen193/2/levy.o \
|
||||
gen193/2/lien.o \
|
||||
gen193/2/need.o \
|
||||
gen193/2/reel.o \
|
||||
gen193/2/roll.o \
|
||||
gen193/2/skim.o \
|
||||
gen193/2/skip.o \
|
||||
gen193/2/slag.o \
|
||||
gen193/2/snag.o \
|
||||
gen193/2/sort.o \
|
||||
gen193/2/turn.o \
|
||||
gen193/2/weld.o
|
||||
|
||||
J193_3_OFILES=\
|
||||
gen193/3/bex.o \
|
||||
gen193/3/can.o \
|
||||
gen193/3/cap.o \
|
||||
gen193/3/cat.o \
|
||||
gen193/3/con.o \
|
||||
gen193/3/cut.o \
|
||||
gen193/3/dor.o \
|
||||
gen193/3/dis.o \
|
||||
gen193/3/end.o \
|
||||
gen193/3/gor.o \
|
||||
gen193/3/hor.o \
|
||||
gen193/3/lsh.o \
|
||||
gen193/3/mas.o \
|
||||
gen193/3/met.o \
|
||||
gen193/3/mix.o \
|
||||
gen193/3/mog.o \
|
||||
gen193/3/peg.o \
|
||||
gen193/3/rap.o \
|
||||
gen193/3/rip.o \
|
||||
gen193/3/rsh.o \
|
||||
gen193/3/vor.o
|
||||
|
||||
J193_4_OFILES=\
|
||||
gen193/4/in.o \
|
||||
gen193/4/by.o \
|
||||
gen193/4/in_has.o \
|
||||
gen193/4/in_gas.o \
|
||||
gen193/4/in_put.o \
|
||||
gen193/4/in_tap.o \
|
||||
gen193/4/by_gas.o \
|
||||
gen193/4/by_get.o \
|
||||
gen193/4/by_has.o \
|
||||
gen193/4/by_put.o
|
||||
|
||||
J193_5_OFILES=\
|
||||
gen193/5/cue.o \
|
||||
gen193/5/jam.o \
|
||||
gen193/5/mat.o \
|
||||
gen193/5/mock.o \
|
||||
gen193/5/parse.o \
|
||||
gen193/5/rub.o \
|
||||
gen193/5/shax.o \
|
||||
gen193/5/trip.o
|
||||
|
||||
J193_6_OFILES=\
|
||||
gen193/6/ap.o \
|
||||
gen193/6/cell.o \
|
||||
gen193/6/comb.o \
|
||||
gen193/6/cons.o \
|
||||
gen193/6/core.o \
|
||||
gen193/6/cube.o \
|
||||
gen193/6/face.o \
|
||||
gen193/6/fine.o \
|
||||
gen193/6/fitz.o \
|
||||
gen193/6/flan.o \
|
||||
gen193/6/flay.o \
|
||||
gen193/6/flip.o \
|
||||
gen193/6/flor.o \
|
||||
gen193/6/fork.o \
|
||||
gen193/6/hike.o \
|
||||
gen193/6/look.o \
|
||||
gen193/6/ut.o
|
||||
|
||||
J193_6_OFILES_UT=\
|
||||
gen193/6/ut_burn.o \
|
||||
gen193/6/ut_bust.o \
|
||||
gen193/6/ut_crop.o \
|
||||
gen193/6/ut_cull.o \
|
||||
gen193/6/ut_find.o \
|
||||
gen193/6/ut_fink.o \
|
||||
gen193/6/ut_fire.o \
|
||||
gen193/6/ut_firm.o \
|
||||
gen193/6/ut_fish.o \
|
||||
gen193/6/ut_fuse.o \
|
||||
gen193/6/ut_gain.o \
|
||||
gen193/6/ut_heal.o \
|
||||
gen193/6/ut_lose.o \
|
||||
gen193/6/ut_mint.o \
|
||||
gen193/6/ut_moot.o \
|
||||
gen193/6/ut_mull.o \
|
||||
gen193/6/ut_nest.o \
|
||||
gen193/6/ut_park.o \
|
||||
gen193/6/ut_peek.o \
|
||||
gen193/6/ut_play.o \
|
||||
gen193/6/ut_repo.o \
|
||||
gen193/6/ut_rest.o \
|
||||
gen193/6/ut_seek.o \
|
||||
gen193/6/ut_snap.o \
|
||||
gen193/6/ut_swab.o \
|
||||
gen193/6/ut_tack.o \
|
||||
gen193/6/ut_tock.o \
|
||||
gen193/6/ut_wrap.o
|
||||
|
||||
J193_OFILES=\
|
||||
$(J193_1_OFILES) \
|
||||
$(J193_2_OFILES) \
|
||||
$(J193_3_OFILES) \
|
||||
$(J193_4_OFILES) \
|
||||
$(J193_5_OFILES) \
|
||||
$(J193_6_OFILES) \
|
||||
$(J193_6_OFILES_UT) \
|
||||
gen193/watt.o
|
||||
|
||||
J192_1_OFILES=\
|
||||
gen192/1/add.o \
|
||||
gen192/1/dec.o \
|
||||
gen192/1/div.o \
|
||||
gen192/1/gte.o \
|
||||
gen192/1/gth.o \
|
||||
gen192/1/lte.o \
|
||||
gen192/1/lth.o \
|
||||
gen192/1/mod.o \
|
||||
gen192/1/mul.o \
|
||||
gen192/1/sub.o
|
||||
|
||||
J192_2_OFILES=\
|
||||
gen192/2/bind.o \
|
||||
gen192/2/clap.o \
|
||||
gen192/2/drop.o \
|
||||
gen192/2/flop.o \
|
||||
gen192/2/lent.o \
|
||||
gen192/2/levy.o \
|
||||
gen192/2/lien.o \
|
||||
gen192/2/need.o \
|
||||
gen192/2/reel.o \
|
||||
gen192/2/roll.o \
|
||||
gen192/2/skim.o \
|
||||
gen192/2/skip.o \
|
||||
gen192/2/slag.o \
|
||||
gen192/2/snag.o \
|
||||
gen192/2/sort.o \
|
||||
gen192/2/turn.o \
|
||||
gen192/2/weld.o
|
||||
|
||||
J192_3_OFILES=\
|
||||
gen192/3/bex.o \
|
||||
gen192/3/can.o \
|
||||
gen192/3/cap.o \
|
||||
gen192/3/cat.o \
|
||||
gen192/3/con.o \
|
||||
gen192/3/cut.o \
|
||||
gen192/3/dor.o \
|
||||
gen192/3/dis.o \
|
||||
gen192/3/end.o \
|
||||
gen192/3/gor.o \
|
||||
gen192/3/hor.o \
|
||||
gen192/3/lsh.o \
|
||||
gen192/3/mas.o \
|
||||
gen192/3/met.o \
|
||||
gen192/3/mix.o \
|
||||
gen192/3/mug.o \
|
||||
gen192/3/peg.o \
|
||||
gen192/3/rap.o \
|
||||
gen192/3/rip.o \
|
||||
gen192/3/rsh.o \
|
||||
gen192/3/vor.o
|
||||
|
||||
J192_4_OFILES=\
|
||||
gen192/4/in.o \
|
||||
gen192/4/by.o \
|
||||
gen192/4/in_has.o \
|
||||
gen192/4/in_gas.o \
|
||||
gen192/4/in_put.o \
|
||||
gen192/4/in_tap.o \
|
||||
gen192/4/by_gas.o \
|
||||
gen192/4/by_get.o \
|
||||
gen192/4/by_has.o \
|
||||
gen192/4/by_put.o
|
||||
|
||||
J192_5_OFILES=\
|
||||
gen192/5/cue.o \
|
||||
gen192/5/jam.o \
|
||||
gen192/5/mat.o \
|
||||
gen192/5/mink.o \
|
||||
gen192/5/parse.o \
|
||||
gen192/5/rub.o \
|
||||
gen192/5/shax.o \
|
||||
gen192/5/trip.o
|
||||
|
||||
J192_6_OFILES=\
|
||||
gen192/6/ap.o \
|
||||
gen192/6/cell.o \
|
||||
gen192/6/comb.o \
|
||||
gen192/6/cons.o \
|
||||
gen192/6/core.o \
|
||||
gen192/6/cube.o \
|
||||
gen192/6/face.o \
|
||||
gen192/6/fine.o \
|
||||
gen192/6/fitz.o \
|
||||
gen192/6/flan.o \
|
||||
gen192/6/flay.o \
|
||||
gen192/6/flip.o \
|
||||
gen192/6/flor.o \
|
||||
gen192/6/fork.o \
|
||||
gen192/6/hike.o \
|
||||
gen192/6/look.o \
|
||||
gen192/6/ut.o
|
||||
|
||||
J192_6_OFILES_UT=\
|
||||
gen192/6/ut_burn.o \
|
||||
gen192/6/ut_bust.o \
|
||||
gen192/6/ut_crop.o \
|
||||
gen192/6/ut_cull.o \
|
||||
gen192/6/ut_find.o \
|
||||
gen192/6/ut_fink.o \
|
||||
gen192/6/ut_fire.o \
|
||||
gen192/6/ut_firm.o \
|
||||
gen192/6/ut_fish.o \
|
||||
gen192/6/ut_fuse.o \
|
||||
gen192/6/ut_gain.o \
|
||||
gen192/6/ut_heal.o \
|
||||
gen192/6/ut_lose.o \
|
||||
gen192/6/ut_mint.o \
|
||||
gen192/6/ut_moot.o \
|
||||
gen192/6/ut_mull.o \
|
||||
gen192/6/ut_nest.o \
|
||||
gen192/6/ut_park.o \
|
||||
gen192/6/ut_peek.o \
|
||||
gen192/6/ut_play.o \
|
||||
gen192/6/ut_repo.o \
|
||||
gen192/6/ut_rest.o \
|
||||
gen192/6/ut_seek.o \
|
||||
gen192/6/ut_snap.o \
|
||||
gen192/6/ut_swab.o \
|
||||
gen192/6/ut_tack.o \
|
||||
gen192/6/ut_tock.o \
|
||||
gen192/6/ut_wrap.o
|
||||
|
||||
J192_OFILES=\
|
||||
$(J192_1_OFILES) \
|
||||
$(J192_2_OFILES) \
|
||||
$(J192_3_OFILES) \
|
||||
$(J192_4_OFILES) \
|
||||
$(J192_5_OFILES) \
|
||||
$(J192_6_OFILES) \
|
||||
$(J192_6_OFILES_UT) \
|
||||
gen192/watt.o
|
||||
|
||||
J191_1_OFILES=\
|
||||
gen191/1/add.o \
|
||||
gen191/1/dec.o \
|
||||
gen191/1/div.o \
|
||||
gen191/1/gte.o \
|
||||
gen191/1/gth.o \
|
||||
gen191/1/lte.o \
|
||||
gen191/1/lth.o \
|
||||
gen191/1/mod.o \
|
||||
gen191/1/mul.o \
|
||||
gen191/1/sub.o
|
||||
|
||||
J191_2_OFILES=\
|
||||
gen191/2/bind.o \
|
||||
gen191/2/clap.o \
|
||||
gen191/2/drop.o \
|
||||
gen191/2/flop.o \
|
||||
gen191/2/lent.o \
|
||||
gen191/2/levy.o \
|
||||
gen191/2/lien.o \
|
||||
gen191/2/need.o \
|
||||
gen191/2/reel.o \
|
||||
gen191/2/roll.o \
|
||||
gen191/2/skim.o \
|
||||
gen191/2/skip.o \
|
||||
gen191/2/slag.o \
|
||||
gen191/2/snag.o \
|
||||
gen191/2/sort.o \
|
||||
gen191/2/turn.o \
|
||||
gen191/2/weld.o
|
||||
|
||||
J191_3_OFILES=\
|
||||
gen191/3/bex.o \
|
||||
gen191/3/can.o \
|
||||
gen191/3/cap.o \
|
||||
gen191/3/cat.o \
|
||||
gen191/3/con.o \
|
||||
gen191/3/cut.o \
|
||||
gen191/3/dor.o \
|
||||
gen191/3/dis.o \
|
||||
gen191/3/end.o \
|
||||
gen191/3/gor.o \
|
||||
gen191/3/hor.o \
|
||||
gen191/3/lsh.o \
|
||||
gen191/3/mas.o \
|
||||
gen191/3/met.o \
|
||||
gen191/3/mix.o \
|
||||
gen191/3/mug.o \
|
||||
gen191/3/peg.o \
|
||||
gen191/3/po.o \
|
||||
gen191/3/rap.o \
|
||||
gen191/3/rip.o \
|
||||
gen191/3/rsh.o \
|
||||
gen191/3/vor.o
|
||||
|
||||
J191_4_OFILES=\
|
||||
gen191/4/in.o \
|
||||
gen191/4/by.o \
|
||||
gen191/4/in_has.o \
|
||||
gen191/4/in_gas.o \
|
||||
gen191/4/in_put.o \
|
||||
gen191/4/in_tap.o \
|
||||
gen191/4/by_gas.o \
|
||||
gen191/4/by_get.o \
|
||||
gen191/4/by_has.o \
|
||||
gen191/4/by_put.o
|
||||
|
||||
J191_5_OFILES=\
|
||||
gen191/5/cue.o \
|
||||
gen191/5/jam.o \
|
||||
gen191/5/mat.o \
|
||||
gen191/5/mink.o \
|
||||
gen191/5/parse.o \
|
||||
gen191/5/rub.o \
|
||||
gen191/5/shax.o \
|
||||
gen191/5/lore.o \
|
||||
gen191/5/loss.o \
|
||||
gen191/5/tape.o \
|
||||
gen191/5/trip.o
|
||||
|
||||
J191_6_OFILES=\
|
||||
gen191/6/ap.o \
|
||||
gen191/6/cell.o \
|
||||
gen191/6/comb.o \
|
||||
gen191/6/cons.o \
|
||||
gen191/6/core.o \
|
||||
gen191/6/cube.o \
|
||||
gen191/6/face.o \
|
||||
gen191/6/fine.o \
|
||||
gen191/6/fitz.o \
|
||||
gen191/6/flan.o \
|
||||
gen191/6/flay.o \
|
||||
gen191/6/flip.o \
|
||||
gen191/6/flor.o \
|
||||
gen191/6/fork.o \
|
||||
gen191/6/hike.o \
|
||||
gen191/6/look.o \
|
||||
gen191/6/ut.o
|
||||
|
||||
J191_6_OFILES_UT=\
|
||||
gen191/6/ut_burn.o \
|
||||
gen191/6/ut_bust.o \
|
||||
gen191/6/ut_crop.o \
|
||||
gen191/6/ut_cull.o \
|
||||
gen191/6/ut_find.o \
|
||||
gen191/6/ut_fink.o \
|
||||
gen191/6/ut_fire.o \
|
||||
gen191/6/ut_firm.o \
|
||||
gen191/6/ut_fish.o \
|
||||
gen191/6/ut_fuse.o \
|
||||
gen191/6/ut_gain.o \
|
||||
gen191/6/ut_heal.o \
|
||||
gen191/6/ut_lose.o \
|
||||
gen191/6/ut_mint.o \
|
||||
gen191/6/ut_moot.o \
|
||||
gen191/6/ut_mull.o \
|
||||
gen191/6/ut_nest.o \
|
||||
gen191/6/ut_park.o \
|
||||
gen191/6/ut_peek.o \
|
||||
gen191/6/ut_play.o \
|
||||
gen191/6/ut_repo.o \
|
||||
gen191/6/ut_rest.o \
|
||||
gen191/6/ut_seek.o \
|
||||
gen191/6/ut_snap.o \
|
||||
gen191/6/ut_swab.o \
|
||||
gen191/6/ut_tack.o \
|
||||
gen191/6/ut_tock.o \
|
||||
gen191/6/ut_wrap.o
|
||||
|
||||
J191_OFILES=\
|
||||
$(J191_1_OFILES) \
|
||||
$(J191_2_OFILES) \
|
||||
$(J191_3_OFILES) \
|
||||
$(J191_4_OFILES) \
|
||||
$(J191_5_OFILES) \
|
||||
$(J191_6_OFILES) \
|
||||
$(J191_6_OFILES_UT) \
|
||||
gen191/watt.o
|
||||
|
||||
BASE_OFILES=\
|
||||
$(F_OFILES) \
|
||||
$(J191_OFILES)
|
||||
|
||||
OUT_OFILES=\
|
||||
outside/jhttp/http_parser.o
|
||||
|
||||
VERE_OFILES=\
|
||||
v/ames.o \
|
||||
v/batz.o \
|
||||
v/http.o \
|
||||
v/loop.o \
|
||||
v/main.o \
|
||||
v/reck.o \
|
||||
v/save.o \
|
||||
v/time.o \
|
||||
v/term.o \
|
||||
v/unix.o \
|
||||
v/walk.o \
|
||||
$(BASE_OFILES) \
|
||||
$(OUT_OFILES)
|
||||
|
||||
LIBUV=outside/libuv/libuv.a
|
||||
|
||||
all: $(BIN)/vere
|
||||
|
||||
$(LIBUV):
|
||||
make -C outside/libuv
|
||||
|
||||
$(BIN)/vere: $(VERE_OFILES) $(LIBUV)
|
||||
mkdir -p $(BIN)
|
||||
$(CLD) $(CLDOSFLAGS) -o $(BIN)/vere $(VERE_OFILES) $(LIBUV) $(LIBS)
|
||||
|
||||
tags:
|
||||
ctags -R -f .tags --exclude=root
|
||||
|
||||
etags:
|
||||
etags -f .etags $$(find -name '*.c' -or -name '*.h')
|
||||
|
||||
clean:
|
||||
$(RM) $(VERE_OFILES) $(BIN)/vere $(BIN)/eyre
|
||||
make -C outside/libuv clean
|
||||
|
||||
24
README.markdown
Normal file
24
README.markdown
Normal file
@ -0,0 +1,24 @@
|
||||
Urbit
|
||||
=====
|
||||
|
||||
This is an implementation of C. Guy Yarvin's [Nock][1] axioms, a compiler from
|
||||
the "Hoon" language to Nock, and other foundations of the [Urbit][2] static
|
||||
functional namespace.
|
||||
|
||||
The interpreter depends on the following packages:
|
||||
|
||||
- GNU Multiprecision library
|
||||
- libsigsegv
|
||||
- openssl
|
||||
- libssl-dev
|
||||
- ncurses
|
||||
|
||||
You may be able to install these by running
|
||||
|
||||
sudo apt-get install libgmp3-dev libev-dev libsigsegv-dev openssl libssl-dev libncurses5-dev
|
||||
|
||||
|
||||
To build the system, run `make OS=osx` or `make OS=linux`.
|
||||
|
||||
[1]: http://moronlab.blogspot.com/2010/01/nock-maxwells-equations-of-software.html
|
||||
[2]: http://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html
|
||||
70
Spec/nock/10.txt
Normal file
70
Spec/nock/10.txt
Normal file
@ -0,0 +1,70 @@
|
||||
Author: Mencius Moldbug [moldbug@gmail.com]
|
||||
Date: 9/15/2008
|
||||
Version: 10K
|
||||
|
||||
1. Introduction
|
||||
|
||||
This file defines one function, "nock."
|
||||
|
||||
nock is in the public domain.
|
||||
|
||||
2. Data
|
||||
|
||||
A "noun" is either an "atom" or a "cell." An "atom" is an unsigned
|
||||
integer of any size. A "cell" is an ordered pair of any two nouns,
|
||||
the "head" and "tail."
|
||||
|
||||
3. Semantics
|
||||
|
||||
nock maps one noun to another. It doesn't always terminate.
|
||||
|
||||
4. Pseudocode
|
||||
|
||||
nock is defined in a pattern-matching pseudocode, below.
|
||||
|
||||
Brackets enclose cells. [a b c] is [a [b c]].
|
||||
|
||||
5. Definition
|
||||
|
||||
5.1 Transformations
|
||||
|
||||
*[a [b c] d] => [*[a b c] *[a d]]
|
||||
*[a 0 b] => /[b a]
|
||||
*[a 1 b] => [b]
|
||||
*[a 2 b c d] => *[a 3 [0 1] 3 [1 c d] [1 0] 3 [1 2 3] [1 0] 5 5 b]
|
||||
*[a 3 b] => **[a b]
|
||||
*[a 4 b] => &*[a b]
|
||||
*[a 5 b] => ^*[a b]
|
||||
*[a 6 b] => =*[a b]
|
||||
*[a] => *[a]
|
||||
|
||||
5.2 Operators
|
||||
|
||||
5.2.1 Goto [*]
|
||||
|
||||
*[a] -> nock[a]
|
||||
|
||||
5.2.2 Deep [&]
|
||||
|
||||
&[a b] -> 0
|
||||
&[a] -> 1
|
||||
|
||||
5.2.4 Bump [^]
|
||||
|
||||
^[a b] -> ^[a b]
|
||||
^[a] -> (a + 1)
|
||||
|
||||
5.2.5 Like [=]
|
||||
|
||||
=[a a] -> 0
|
||||
=[a b] -> 1
|
||||
=[a] -> =[a]
|
||||
|
||||
5.2.6 Snip [/]
|
||||
|
||||
/[1 a] -> a
|
||||
/[2 a b] -> a
|
||||
/[3 a b] -> b
|
||||
/[(a + a) b] -> /[2 /[a b]]
|
||||
/[(a + a + 1) b] -> /[3 /[a b]]
|
||||
/[a] -> /[a]
|
||||
74
Spec/nock/11.txt
Normal file
74
Spec/nock/11.txt
Normal file
@ -0,0 +1,74 @@
|
||||
Author: Mencius Moldbug (moldbug@gmail.com)
|
||||
Date: 5/25/2008
|
||||
Version: 11K
|
||||
|
||||
1. Introduction
|
||||
|
||||
This file defines one function, "nock."
|
||||
|
||||
nock is in the public domain.
|
||||
|
||||
2. Data
|
||||
|
||||
A "noun" is either an "atom" or a "cell." An "atom" is an unsigned
|
||||
integer of any size. A "cell" is an ordered pair of any two nouns,
|
||||
the "head" and "tail."
|
||||
|
||||
3. Semantics
|
||||
|
||||
nock maps one noun to another. It doesn't always terminate.
|
||||
|
||||
4. Pseudocode
|
||||
|
||||
nock is defined in a pattern-matching pseudocode, below.
|
||||
|
||||
Parentheses enclose cells. (a b c) is (a (b c)).
|
||||
|
||||
5. Definition
|
||||
|
||||
5.1 Transformations
|
||||
|
||||
*(a (b c) d) => (*(a b c) *(a d))
|
||||
*(a 0 b) => /(b a)
|
||||
*(a 1 b) => (b)
|
||||
*(a 2 b c d) => *(a 3 (0 1) 3 (1 c d) (1 0) 3 (1 2 3) (1 0) 5 5 b)
|
||||
*(a 3 b) => **(a b)
|
||||
*(a 4 b) => &*(a b)
|
||||
*(a 5 b) => ^*(a b)
|
||||
*(a 6 b) => =*(a b)
|
||||
|
||||
*(a 7 b c) => *(a 3 (((1 0) b) c) 1 0 3)
|
||||
*(a 8 b c) => *(a c)
|
||||
|
||||
*(a) => *(a)
|
||||
|
||||
5.2 Operators
|
||||
|
||||
5.2.1 Goto (*)
|
||||
|
||||
*(a) -> nock(a)
|
||||
|
||||
5.2.2 Deep (&)
|
||||
|
||||
&(a b) -> 0
|
||||
&(a) -> 1
|
||||
|
||||
5.2.4 Bump (^)
|
||||
|
||||
^(a b) -> ^(a b)
|
||||
^(a) -> a + 1
|
||||
|
||||
5.2.5 Same (=)
|
||||
|
||||
=(a a) -> 0
|
||||
=(a b) -> 1
|
||||
=(a) -> =(a)
|
||||
|
||||
5.2.6 Snip (/)
|
||||
|
||||
/(1 a) -> a
|
||||
/(2 a b) -> a
|
||||
/(3 a b) -> b
|
||||
/((a + a) b) -> /(2 /(a b))
|
||||
/((a + a + 1) b) -> /(3 /(a b))
|
||||
/(a) -> /(a)
|
||||
75
Spec/nock/12.txt
Normal file
75
Spec/nock/12.txt
Normal file
@ -0,0 +1,75 @@
|
||||
Author: Curtis Yarvin (curtis.yarvin@gmail.com)
|
||||
Date: 3/28/2008
|
||||
Version: 0.12
|
||||
|
||||
1. Introduction
|
||||
|
||||
This file defines one function, "nock."
|
||||
|
||||
nock is in the public domain.
|
||||
|
||||
2. Data
|
||||
|
||||
A "noun" is either an "atom" or a "cell." An "atom" is an unsigned
|
||||
integer of any size. A "cell" is an ordered pair of any two nouns,
|
||||
the "head" and "tail."
|
||||
|
||||
3. Semantics
|
||||
|
||||
nock maps one noun to another. It doesn't always terminate.
|
||||
|
||||
4. Pseudocode
|
||||
|
||||
nock is defined in a pattern-matching pseudocode, below.
|
||||
|
||||
Parentheses enclose cells. (a b c) is (a (b c)).
|
||||
|
||||
5. Definition
|
||||
|
||||
5.1 Transformations
|
||||
|
||||
*(a (b c) d) => (*(a b c) *(a d))
|
||||
*(a 0 b) => /(b a)
|
||||
*(a 1 b) => (b)
|
||||
*(a 2 b c) => *(*(a b) c)
|
||||
*(a 3 b) => **(a b)
|
||||
*(a 4 b) => &*(a b)
|
||||
*(a 5 b) => ^*(a b)
|
||||
*(a 6 b) => =*(a b)
|
||||
|
||||
*(a 7 b c d) => *(a 3 (0 1) 3 (1 c d) (1 0) 3 (1 2 3) (1 0) 5 5 b)
|
||||
*(a 8 b c) => *(a 2 (((1 0) b) c) 0 3)
|
||||
*(a 9 b c) => *(a c)
|
||||
|
||||
*(a) => *(a)
|
||||
|
||||
5.2 Operators
|
||||
|
||||
5.2.1 Goto (*)
|
||||
|
||||
*(a) -> nock(a)
|
||||
|
||||
5.2.2 Deep (&)
|
||||
|
||||
&(a b) -> 0
|
||||
&(a) -> 1
|
||||
|
||||
5.2.4 Bump (^)
|
||||
|
||||
^(a b) -> ^(a b)
|
||||
^(a) -> a + 1
|
||||
|
||||
5.2.5 Same (=)
|
||||
|
||||
=(a a) -> 0
|
||||
=(a b) -> 1
|
||||
=(a) -> =(a)
|
||||
|
||||
5.2.6 Snip (/)
|
||||
|
||||
/(1 a) -> a
|
||||
/(2 a b) -> a
|
||||
/(3 a b) -> b
|
||||
/((a + a) b) -> /(2 /(a b))
|
||||
/((a + a + 1) b) -> /(3 /(a b))
|
||||
/(a) -> /(a)
|
||||
71
Spec/nock/13.txt
Normal file
71
Spec/nock/13.txt
Normal file
@ -0,0 +1,71 @@
|
||||
Author: Curtis Yarvin (curtis.yarvin@gmail.com)
|
||||
Date: 3/8/2008
|
||||
Version: 0.13
|
||||
|
||||
1. Manifest
|
||||
|
||||
This file defines one Turing-complete function, "nock."
|
||||
|
||||
nock is in the public domain. So far as I know, it is
|
||||
neither patentable nor patented. Use it at your own risk.
|
||||
|
||||
2. Data
|
||||
|
||||
Both the domain and range of nock are "nouns."
|
||||
|
||||
A "noun" is either an "atom" or a "cell." An "atom" is an unsigned
|
||||
integer of any size. A "cell" is an ordered pair of any two nouns,
|
||||
the "head" and "tail."
|
||||
|
||||
3. Pseudocode
|
||||
|
||||
nock is defined in a pattern-matching pseudocode.
|
||||
|
||||
Match precedence is top-down. Operators are prefix. Parens
|
||||
denote cells, and group right: (a b c) is (a (b c)).
|
||||
|
||||
4. Definition
|
||||
|
||||
4.1 Transformations
|
||||
|
||||
*(a 0 b c) => *(*(a b) c)
|
||||
*(a 0 b) => /(b a)
|
||||
*(a 1 b) => (b)
|
||||
*(a 2 b) => **(a b)
|
||||
*(a 3 b) => &*(a b)
|
||||
*(a 4 b) => ^*(a b)
|
||||
*(a 5 b) => =*(a b)
|
||||
*(a 6 b c d) => *(a 2 (0 1) 2 (1 c d) (1 0) 2 (1 2 3) (1 0) 4 4 b)
|
||||
*(a b c) => (*(a b) *(a c))
|
||||
*(a) => *(a)
|
||||
|
||||
4.2 Operators
|
||||
|
||||
4.2.1 Goto (*)
|
||||
|
||||
*(a) -> nock(a)
|
||||
|
||||
4.2.2 Deep (&)
|
||||
|
||||
&(a b) -> 0
|
||||
&(a) -> 1
|
||||
|
||||
4.2.3 Bump (^)
|
||||
|
||||
^(a b) -> ^(a b)
|
||||
^(a) -> a + 1
|
||||
|
||||
4.2.4 Same (=)
|
||||
|
||||
=(a a) -> 0
|
||||
=(a b) -> 1
|
||||
=(a) -> =(a)
|
||||
|
||||
4.2.5 Snip (/)
|
||||
|
||||
/(1 a) -> a
|
||||
/(2 a b) -> a
|
||||
/(3 a b) -> b
|
||||
/((a + a) b) -> /(2 /(a b))
|
||||
/((a + a + 1) b) -> /(3 /(a b))
|
||||
/(a) -> /(a)
|
||||
42
Spec/nock/5.txt
Normal file
42
Spec/nock/5.txt
Normal file
@ -0,0 +1,42 @@
|
||||
1 Structures
|
||||
|
||||
A noun is an atom or a cell. An atom is any natural number.
|
||||
A cell is an ordered pair of nouns.
|
||||
|
||||
2 Reductions
|
||||
|
||||
nock(a) *a
|
||||
[a b c] [a [b c]]
|
||||
|
||||
?[a b] 0
|
||||
?a 1
|
||||
+[a b] +[a b]
|
||||
+a 1 + a
|
||||
=[a a] 0
|
||||
=[a b] 1
|
||||
=a =a
|
||||
|
||||
/[1 a] a
|
||||
/[2 a b] a
|
||||
/[3 a b] b
|
||||
/[(a + a) b] /[2 /[a b]]
|
||||
/[(a + a + 1) b] /[3 /[a b]]
|
||||
/a /a
|
||||
|
||||
*[a [b c] d] [*[a b c] *[a d]]
|
||||
|
||||
*[a 0 b] /[b a]
|
||||
*[a 1 b] b
|
||||
*[a 2 b c] *[*[a b] *[a c]]
|
||||
*[a 3 b] ?*[a b]
|
||||
*[a 4 b] +*[a b]
|
||||
*[a 5 b] =*[a b]
|
||||
|
||||
*[a 6 b c d] *[a 2 [0 1] 2 [1 c d] [1 0] 2 [1 2 3] [1 0] 4 4 b]
|
||||
*[a 7 b c] *[a 2 b 1 c]
|
||||
*[a 8 b c] *[a 7 [[7 [0 1] b] 0 1] c]
|
||||
*[a 9 b c] *[a 7 c 2 [0 1] 0 b]
|
||||
*[a 10 [b c] d] *[a 8 c 7 [0 3] d]
|
||||
*[a 10 b c] *[a c]
|
||||
|
||||
*a *a
|
||||
42
Spec/nock/6.txt
Normal file
42
Spec/nock/6.txt
Normal file
@ -0,0 +1,42 @@
|
||||
1 Structures
|
||||
|
||||
A noun is an atom or a cell. An atom is any natural number.
|
||||
A cell is an ordered pair of nouns.
|
||||
|
||||
2 Reductions
|
||||
|
||||
nock(a) *a
|
||||
[a b c] [a [b c]]
|
||||
|
||||
?[a b] 0
|
||||
?a 1
|
||||
+a 1 + a
|
||||
=[a a] 0
|
||||
=[a b] 1
|
||||
|
||||
/[1 a] a
|
||||
/[2 a b] a
|
||||
/[3 a b] b
|
||||
/[(a + a) b] /[2 /[a b]]
|
||||
/[(a + a + 1) b] /[3 /[a b]]
|
||||
|
||||
*[a [b c] d] [*[a b c] *[a d]]
|
||||
|
||||
*[a 0 b] /[b a]
|
||||
*[a 1 b] b
|
||||
*[a 2 b c] *[*[a b] *[a c]]
|
||||
*[a 3 b] ?*[a b]
|
||||
*[a 4 b] +*[a b]
|
||||
*[a 5 b] =*[a b]
|
||||
|
||||
*[a 6 b c d] *[a 2 [0 1] 2 [1 c d] [1 0] 2 [1 2 3] [1 0] 4 4 b]
|
||||
*[a 7 b c] *[a 2 b 1 c]
|
||||
*[a 8 b c] *[a 7 [[0 1] b] c]
|
||||
*[a 9 b c] *[a 7 c 0 b]
|
||||
*[a 10 b c] *[a c]
|
||||
*[a 10 [b c] d] *[a 8 c 7 [0 2] d]
|
||||
|
||||
+[a b] +[a b]
|
||||
=a =a
|
||||
/a /a
|
||||
*a *a
|
||||
42
Spec/nock/7.txt
Normal file
42
Spec/nock/7.txt
Normal file
@ -0,0 +1,42 @@
|
||||
1 Structures
|
||||
|
||||
A noun is an atom or a cell. An atom is any natural number.
|
||||
A cell is any ordered pair of nouns.
|
||||
|
||||
2 Pseudocode
|
||||
|
||||
[a b c] [a [b c]]
|
||||
nock(a) *a
|
||||
|
||||
?[a b] 0
|
||||
?a 1
|
||||
^a 1 + a
|
||||
=[a a] 0
|
||||
=[a b] 1
|
||||
|
||||
/[1 a] a
|
||||
/[2 a b] a
|
||||
/[3 a b] b
|
||||
/[(a + a) b] /[2 /[a b]]
|
||||
/[(a + a + 1) b] /[3 /[a b]]
|
||||
|
||||
*[a [b c] d] [*[a b c] *[a d]]
|
||||
|
||||
*[a 0 b] /[b a]
|
||||
*[a 1 b] b
|
||||
*[a 2 b c] *[*[a b] *[a c]]
|
||||
*[a 3 b] ?*[a b]
|
||||
*[a 4 b] ^*[a b]
|
||||
*[a 5 b] =*[a b]
|
||||
|
||||
*[a 6 b c d] *[a 2 [0 1] 2 [1 c d] [1 0] 2 [1 2 3] [1 0] 4 4 b]
|
||||
*[a 7 b c] *[a 2 b 1 c]
|
||||
*[a 8 b c] *[a 7 [[7 [0 1] b] 0 1] c]
|
||||
*[a 9 b c] *[a 7 c 0 b]
|
||||
*[a 10 b c] *[a c]
|
||||
*[a 10 [b c] d] *[a 8 c 7 [0 3] d]
|
||||
|
||||
^[a b] ^[a b]
|
||||
=a =a
|
||||
/a /a
|
||||
*a *a
|
||||
45
Spec/nock/8.txt
Normal file
45
Spec/nock/8.txt
Normal file
@ -0,0 +1,45 @@
|
||||
1 Structures
|
||||
|
||||
A noun is an atom or a cell. An atom is any unsigned integer.
|
||||
A cell is an ordered pair of nouns.
|
||||
|
||||
2 Pseudocode
|
||||
|
||||
[a b c] is [a [b c]]; *a is nock(a). Reductions match top-down.
|
||||
|
||||
3 Reductions
|
||||
|
||||
?[a b] 0
|
||||
?a 1
|
||||
^a (a + 1)
|
||||
=[a a] 0
|
||||
=[a b] 1
|
||||
|
||||
/[1 a] a
|
||||
/[2 a b] a
|
||||
/[3 a b] b
|
||||
/[(a + a) b] /[2 /[a b]]
|
||||
/[(a + a + 1) b] /[3 /[a b]]
|
||||
|
||||
*[a [b c] d] [*[a b c] *[a d]]
|
||||
*[a 0 b] /[b a]
|
||||
*[a 1 b] b
|
||||
*[a 2 b c] *[*[a b] *[a c]]
|
||||
*[a 3 b] ?*[a b]
|
||||
*[a 4 b] ^*[a b]
|
||||
*[a 5 b] =*[a b]
|
||||
|
||||
*[a 6 b c d] *[a 2 [0 1] 2 [1 c d] [1 0] 2 [1 2 3] [1 0] 4 4 b]
|
||||
*[a 7 b c] *[a 2 b 1 c]
|
||||
*[a 8 b c] *[a 7 [7 b [0 1]] c]
|
||||
*[a 9 b c] *[a 8 b 2 [[7 [0 3] d] [0 5]] 0 5]
|
||||
*[a 10 b c] *[a 8 b 8 [7 [0 3] c] 0 2]
|
||||
*[a 11 b c] *[a 8 b 7 [0 3] c]
|
||||
*[a 12 b c] *[a [1 0] 1 c]
|
||||
|
||||
^[a b] ^[a b]
|
||||
=a =a
|
||||
/a /a
|
||||
*a *a
|
||||
|
||||
|
||||
43
Spec/nock/9.txt
Normal file
43
Spec/nock/9.txt
Normal file
@ -0,0 +1,43 @@
|
||||
1 Context
|
||||
|
||||
This spec defines one function, Nock.
|
||||
|
||||
2 Structures
|
||||
|
||||
A noun is an atom or a cell. An atom is any unsigned integer.
|
||||
A cell is an ordered pair of any two nouns.
|
||||
|
||||
3 Pseudocode
|
||||
|
||||
Brackets enclose cells. [a b c] is [a [b c]].
|
||||
|
||||
*a is Nock(a). Reductions match top-down.
|
||||
|
||||
4 Reductions
|
||||
|
||||
?[a b] => 0
|
||||
?a => 1
|
||||
|
||||
^[a b] => ^[a b]
|
||||
^a => (a + 1)
|
||||
|
||||
=[a a] => 0
|
||||
=[a b] => 1
|
||||
=a => =a
|
||||
|
||||
/[1 a] => a
|
||||
/[2 a b] => a
|
||||
/[3 a b] => b
|
||||
/[(a + a) b] => /[2 /[a b]]
|
||||
/[(a + a + 1) b] => /[3 /[a b]]
|
||||
/a => /a
|
||||
|
||||
*[a 0 b] => /[b a]
|
||||
*[a 1 b] => b
|
||||
*[a 2 b c d] => *[a 3 [0 1] 3 [1 c d] [1 0] 3 [1 2 3] [1 0] 5 5 b]
|
||||
*[a 3 b] => **[a b]
|
||||
*[a 4 b] => ?*[a b]
|
||||
*[a 5 b] => ^*[a b]
|
||||
*[a 6 b] => =*[a b]
|
||||
*[a [b c] d] => [*[a b c] *[a d]]
|
||||
*a => *a
|
||||
31
Spec/vere/stage.txt
Normal file
31
Spec/vere/stage.txt
Normal file
@ -0,0 +1,31 @@
|
||||
To stage down from X to Y == (X - 1), steps:
|
||||
|
||||
Clean hoon parts:
|
||||
|
||||
- cp -r lib/X lib/Y
|
||||
- select kernel name in Y:
|
||||
hoon.hoon (regular)
|
||||
tram.hoon (genetically incompatible with stage X)
|
||||
test.hoon (barebones testing)
|
||||
|
||||
- rm lib/Y/hoon.pill
|
||||
- git add lib/Y/*.hoon
|
||||
- git add lib/Y/arvo/*.hoon
|
||||
- update stage number in lib/Y/hoon.hoon
|
||||
|
||||
Ugly jet parts:
|
||||
|
||||
- make clean; cp -r genX to genY;
|
||||
- git add genY/*.c genY/*.h genY/*/*.c
|
||||
- update genY/pit.h (7 subs)
|
||||
- add genY/ofiles in Makefile
|
||||
- link j2_da drivers in v/main.c
|
||||
- (optional) trim old stages
|
||||
- update FirstKernel in include/v/vere.h
|
||||
- update Pt* in f/coal.c (5 subs) and f/trac.c (2 subs)
|
||||
- remove .o files from Makefile
|
||||
|
||||
Convenient symlinks:
|
||||
- kernel letter L is `@ta`(add 'a' (sub 25 (mod (add 8 Y) 26)))
|
||||
- ln -s C/sys/Y sL
|
||||
- ln -s genY kL
|
||||
438
Spec/watt/1-anatomy.txt
Normal file
438
Spec/watt/1-anatomy.txt
Normal file
@ -0,0 +1,438 @@
|
||||
Anatomy of Watt: 1, Molds
|
||||
|
||||
One of the errors most people make when they write their first
|
||||
few programming languages is to specify the language before they
|
||||
write the implementation. They then compound this error by
|
||||
designing the language before they specify it. And worst of all,
|
||||
they describe it before they design it.
|
||||
|
||||
Having made all these mistakes more than once myself, I was
|
||||
determined to avoid them in Watt. Fortunately, I now have a
|
||||
reasonably complete and working Watt, so I can describe it! The
|
||||
best way to learn Watt will always be to read the code, though.
|
||||
|
||||
[Note that this is a DRAFT description; Watt, still, does not
|
||||
exist. It will not even have a Kelvin number until it boots.
|
||||
Moreover, instead of "reading the code" in Watt, you have to read
|
||||
it in C and Yacc - both harder, and less rewarding. Also, I
|
||||
would avoid actually playing with the build for a couple of days
|
||||
- there is still some medium-scale surgery to be done. Besides,
|
||||
more actual lessons will follow.]
|
||||
|
||||
Watt is based on Nock, of course. Most specifically, Watt is
|
||||
defined as a pair of gates in the Watt kernel: the Watt grammar
|
||||
and the Mill composer.
|
||||
|
||||
:::::::: Watt: the grammar
|
||||
::
|
||||
- watt
|
||||
|| gene
|
||||
src = text
|
||||
==
|
||||
:: Parse Watt source.
|
||||
::
|
||||
[...]
|
||||
|
||||
:::::::: Mill: the composer
|
||||
::
|
||||
- mill
|
||||
|| [mol=mold noc=nock]
|
||||
sub = mold
|
||||
gen = gene
|
||||
==
|
||||
:: Generate Nock code and infer type.
|
||||
::
|
||||
[...]
|
||||
|
||||
Here at Moron Lab, we are of the total-immersion school of
|
||||
programming-language pedagogy. One of the many reasons it's
|
||||
foolish to write your language documentation before your language
|
||||
is that it's just impossible to keep your pseudocode up to date.
|
||||
|
||||
Therefore, let's dive into Watt with some straight-up code.
|
||||
Everything below is working Watt or my error. I swear.
|
||||
|
||||
So if the syntax above is not self-explanatory to you, here is
|
||||
a trivial decrement in Watt:
|
||||
|
||||
|| @
|
||||
z = @
|
||||
==
|
||||
:: Transform [z] to "(z - 1)"
|
||||
::
|
||||
=> a 0
|
||||
|-
|
||||
?: (eq z (inc a))
|
||||
a
|
||||
$(a (inc a))
|
||||
|
||||
The algorithm (which is O(n)) should be obvious on inspection.
|
||||
"@" is pronounced "atom."
|
||||
|
||||
We can also write Nock in Watt. Note that this code cheats: it
|
||||
delegates basic Nock functions to... Nock. The whole exercise
|
||||
is pointless, because we could express it as
|
||||
|
||||
|| *
|
||||
z = *
|
||||
==
|
||||
:3.z
|
||||
|
||||
Nonetheless, this code closely resembles the present spec and
|
||||
functions perfectly as written below. "*" is pronounced "blur,"
|
||||
meaning "any noun."
|
||||
|
||||
|| *
|
||||
z = *
|
||||
==
|
||||
:: Compute "Nock(a)" - 9K.
|
||||
::
|
||||
?- z
|
||||
- [a 0 b=@]
|
||||
$(z :3.[a.z 0 b.z]) :: cheating
|
||||
|
||||
- [a 1 b=*]
|
||||
b
|
||||
|
||||
- [a 2 b=* c=* d=*]
|
||||
$(z [a.z 3 [0 1] 3 [1 c.z d.z] [1 0] 3 [1 2 3] [1 0] 5 5 b.z])
|
||||
|
||||
- [a 3 b=*]
|
||||
$(z $(z [a.z b.z]))
|
||||
|
||||
- [a 4 b=*]
|
||||
$(z :3.[a.z 4 b.z]) :: cheating
|
||||
|
||||
- [a 5 b=*]
|
||||
$(z :3.[a.z 5 b.z]) :: cheating
|
||||
|
||||
- [a 6 b=*]
|
||||
$(z :3.[a.z 6 b.z]) :: cheating
|
||||
|
||||
- [[a=* b=*] c=*]
|
||||
[$(z [a.z b.z]) $(z c.z)]
|
||||
==
|
||||
|
||||
We could also, of course, write:
|
||||
|
||||
- [a 2 b=* c=* d=*]
|
||||
?: $(z [a.z b.z])
|
||||
$(z a.z c.z)
|
||||
$(z a.z d.z)
|
||||
|
||||
Which should give the semantics of 2 away!
|
||||
|
||||
But this is an entirely intuitive introduction. It should under
|
||||
no circumstances be mistaken for a definition, or even a tutorial.
|
||||
It is just meant to explain what I mean when I use Watt syntax,
|
||||
in a paralinguistic Rosetta-Stone sort of way.
|
||||
|
||||
To understand Watt in a concrete way, let's see those gates again:
|
||||
|
||||
:::::::: Watt: the reader (ie, syntax)
|
||||
::
|
||||
- watt
|
||||
|| gene
|
||||
src = text
|
||||
==
|
||||
:: Parse source.
|
||||
::
|
||||
[...]
|
||||
|
||||
:::::::: Mill: the composer (ie, compiler)
|
||||
::
|
||||
- mill
|
||||
|| [mol=mold noc=nock]
|
||||
sub = mold
|
||||
gen = gene
|
||||
==
|
||||
:: Generate code and infer type.
|
||||
::
|
||||
[...]
|
||||
|
||||
In programmer-English, Watt is a function that transforms a text
|
||||
file (as a Nock atom) into a Watt AST (as a Nock noun). Mill is
|
||||
a function that transforms a Watt type (again a Nock noun, of
|
||||
course) into a Watt type and a Nock formula.
|
||||
|
||||
A Watt type is called a "mold." The abstract syntax tree (ie,
|
||||
your code read in, with minimal processing, as a data structure)
|
||||
is called a "gene."
|
||||
|
||||
(Why this unusual language? Why not call a type a type? Because,
|
||||
as a programmer, the word "type" already means something to you.
|
||||
Moreover, there is actually more than one concept in Watt for
|
||||
which we might use the word "type." It's entirely possible that
|
||||
people will just end up calling molds "types," but anyone you see
|
||||
instantiating this meme should be vigorously chastised! As for
|
||||
the superiority of "gene" over "AST", I will admit no argument.)
|
||||
|
||||
Mill is a function that transforms an ordered pair of
|
||||
two nouns, [sub gen], to another ordered pair, [mol noc].
|
||||
|
||||
Let's look at these mysterious nouns, the molds. Here is the
|
||||
definition of a mold:
|
||||
|
||||
:::::::: mold
|
||||
::
|
||||
- mold
|
||||
|~
|
||||
**
|
||||
%atom
|
||||
%blot
|
||||
%blur
|
||||
[%cell p=mold q=mold]
|
||||
[%cone p=mold q=(bush mark gene)]
|
||||
[%cube p=*]
|
||||
[%face p=mark q=mold]
|
||||
[%fork p=mold q=mold]
|
||||
[%fuse p=mold q=mold]
|
||||
[%hold p=mold q=gene]
|
||||
==
|
||||
|
||||
Peculiarly enough, this gate is both the definition of a mold and
|
||||
its implementation. For instance, if you have a random noun, n,
|
||||
which you're hoping might be a mold,
|
||||
|
||||
(mold n)
|
||||
|
||||
will produce n if n is a mold, and exit if n is not a mold. The
|
||||
result, of course, will be in mold [mold] - ie, it will be typed.
|
||||
(We say "in mold foo" instead of "of type foo.")
|
||||
|
||||
This is called "rectifying" n. Rectification is quite useful in
|
||||
the context of network communication - it is common to receive
|
||||
generic, unvalidated data from foreign sources, and need to
|
||||
import it into a strictly-typed programming language, a task
|
||||
commonly done ad hoc or not at all.
|
||||
|
||||
But I digress. Let's describe the type system - I mean, the
|
||||
mold system.
|
||||
|
||||
First, the philosophy of this system is the same minimalism
|
||||
you've already seen in Nock. Unlike Nock, Watt is not quite
|
||||
complete - there are a few bells and whistles I want to add,
|
||||
which will result in two or three more forks of mold. However,
|
||||
the definition above is sufficient for quite a rich programming
|
||||
experience. The bells and whistles will make rectification more
|
||||
powerful and facilitate object-oriented programming. Even with
|
||||
the above, however, OOP is doable - just a little "ghetto."
|
||||
|
||||
Let's walk through this data structure very quickly, and we'll
|
||||
keep your introduction to Watt short and easy to chew.
|
||||
|
||||
A mold satisfies the two basic requirements of any type or data
|
||||
description system.
|
||||
|
||||
One: a mold unambiguously defines a set of nouns. For any mold and
|
||||
any noun, that noun is either in the mold or not in the mold.
|
||||
Without the bells and whistles, we cannot describe all such sets,
|
||||
but even without the bells and whistles we can express just about
|
||||
any practical data structure.
|
||||
|
||||
(For instance, a mold is to nouns much as an XML DTD or schema is
|
||||
to valid XML. The difference is that nouns are much simpler than
|
||||
XML; molds are much, much, much simpler than XML Schema; and XML
|
||||
does not ship with a functional programming language. So it's a
|
||||
little like comparing an oxcart to a Ducati. But both are
|
||||
perfectly effective ways of getting from point A to point B.)
|
||||
|
||||
Two: a mold ascribes semantics to nouns in the mold. More
|
||||
precisely, it defines a namespace on the noun. A name in Watt is
|
||||
called a "port"; a path is a "wire." When you see [a.z] above,
|
||||
this is referencing port "a" in port "z" in the subject. (Note
|
||||
that in most Earth programming languages, this would be "z.a".)
|
||||
[$] is simply the name 0 - sometimes a name is superfluous.
|
||||
|
||||
Ports can be fragments of the subject ("parts") or computed
|
||||
functions ("hooks"). You can also hack into a noun with a direct
|
||||
fragment address - eg, [+2] for the head, [+3] for the tail.
|
||||
|
||||
Lisp programmers learning Watt may be slightly puzzled by the
|
||||
lack of an environment. Indeed, the simplest way to describe
|
||||
Watt to someone who knows Lisp is: Lisp without an environment.
|
||||
|
||||
Instead, every Watt gene is evaluated relative to a single noun
|
||||
which contains all data *and code* available to that gene. This
|
||||
is called "the subject." Thus, when we compute
|
||||
|
||||
(mill mol gen)
|
||||
|
||||
and produce a product
|
||||
|
||||
[pro=[mol=mold noc=nock]]
|
||||
|
||||
we are saying: produce the Nock formula, [noc.pro], that computes
|
||||
the function defined by [gen] on a subject in mold [mol]. The
|
||||
result of this function will be in mold [mol.pro].
|
||||
|
||||
Let's list the mold forks quickly, and we'll be done with this
|
||||
lesson. Frankly, my previous essays have been too long. There
|
||||
are two kinds of mold: the obvious kind, and the non-obvious
|
||||
kind. First, the former.
|
||||
|
||||
|
||||
Three atomic molds: %atom, %blot, %blur. %atom means: any
|
||||
atom. %blur means: any noun. %blot means: no nouns (ie,
|
||||
"void"). I trust there is no rocket science here. None of these
|
||||
export any ports.
|
||||
|
||||
[%cube p=*]: a constant noun. Any noun that equals [p] is in the
|
||||
mold; any noun that does not, is not. No ports are exported.
|
||||
|
||||
[%cell p=mold q=mold]: a cell, ie, ordered pair. [p] is the mold
|
||||
of the head; [q] the mold of the tail. Exports all ports of [p]
|
||||
and [q]; any conflict is an error.
|
||||
|
||||
[%fork p=mold q=mold]: set union of the molds [p] and [q].
|
||||
Exports any port for which [p] and [q] define the same formula.
|
||||
Symmetric; [%fork q p] has the same semantics as [%fork p q].
|
||||
|
||||
[%fuse p=mold q=mold]: set intersection of the molds [p] and [q].
|
||||
Asymmetric; [q] has higher priority, ie, [p] cannot change or
|
||||
conceal the semantics of [q].
|
||||
|
||||
[%face p=mark q=mold]: name a part. Exports the name [p]. For
|
||||
ports in [q], read through [p] - eg, in the Nock example above,
|
||||
[a.z] works but [a] will give you "port not found." [p] may not
|
||||
be 0 - port 0 is always a hook, never a part.
|
||||
|
||||
Now, the above are all the *obvious* molds. If you were writing
|
||||
a simple data-description model, the noun equivalent of a DTD,
|
||||
for finite static nouns, they might even be sufficient. But for
|
||||
actual functional programming, we need two more: %cone and %hold.
|
||||
If your brain has been nodding "duh, duh, of course" up to this
|
||||
point, it's time for it to sit up and pay attention!
|
||||
|
||||
|
||||
[%cone p=mold q=(bush mark gene)]: executable code. A bush is
|
||||
simply a data structure which, like Nock formulas, overloads the
|
||||
head atom: it is either
|
||||
|
||||
[mark gene]
|
||||
|
||||
mark being an atom - ie, a symbol - or
|
||||
|
||||
[(bush mark gene) (bush mark gene)]
|
||||
|
||||
with a tree search order. Thus, what we're looking at here is...
|
||||
a symbol table. Very comparable to a vtable in C++. Okay, we
|
||||
may still be in "duh" territory.
|
||||
|
||||
The nouns in the cone are of the form [data code]. [data]
|
||||
is a noun in the mold [p]. [code] matches the geometry of [q];
|
||||
every leaf
|
||||
|
||||
[mark gene]
|
||||
|
||||
becomes the Nock formula
|
||||
|
||||
noc.(mill [%cone p q] gene)
|
||||
|
||||
A cone exports all the marks in its book as hooks. If the port
|
||||
equals the mark, the formula produced calls the hook formula,
|
||||
with a subject that is the entire cone (not just the cone head).
|
||||
|
||||
So, for instance, the Nock equivalent of a lambda is a "gate."
|
||||
This is always a mold of the form
|
||||
|
||||
[%cone
|
||||
[%cell arg=mold env=mold]
|
||||
[0 gene]
|
||||
]
|
||||
|
||||
Ie, the data in a gate is an argument-environment pair (so there
|
||||
*is* an environment - it's just reentrant), and a hook whose name
|
||||
is 0 (ie, [$]). To invoke the lambda, replace the default
|
||||
argument with a compatible value of your choice, and use the
|
||||
hook.
|
||||
|
||||
When you write
|
||||
|
||||
(dec x)
|
||||
|
||||
you are actually invoking *two* hooks. First, [dec] resolves to
|
||||
a hook in the kernel which produces a decrement gate. Second,
|
||||
you replace the argument [+4] in that gate with [arg], and invoke
|
||||
the formula.
|
||||
|
||||
Note, in particular, that Watt never calculates "type signatures"
|
||||
for code. Rather, the gene is simply embedded in the mold! And
|
||||
since different genes generate different formulas, cones with
|
||||
different books are never in any sense compatible. If this makes
|
||||
you wonder how we do higher-order polymorphism, it should!
|
||||
Suffice it to say: there's a trick.
|
||||
|
||||
|
||||
[%hold p=mold q=gene]: delayed evaluation. For all but cosmetic
|
||||
purposes, [%hold p q] is equivalent to
|
||||
|
||||
mol.(mill p q)
|
||||
|
||||
Ie, [%hold p q] is the mold produced by gene [q] in mold [p].
|
||||
|
||||
Some programming languages support infinite data structures.
|
||||
Watt is not one of these; all Watt data structures are Nock
|
||||
nouns, and all Nock nouns are finite.
|
||||
|
||||
However, we often find ourselves needing to describe *indefinite*
|
||||
data structures. For example, a list of pairs of atoms:
|
||||
|
||||
(list :[@ @])
|
||||
|
||||
Nouns in this mold include
|
||||
|
||||
0
|
||||
[[3 7] 0]
|
||||
[[2 3] [37 42] 0]
|
||||
|
||||
And so on. Clearly, a list can be as long as you want. Clearly,
|
||||
since molds are Nock nouns, and Nock nouns are finite, we must
|
||||
define this infinitely-large set, containing indefinitely-large
|
||||
nouns, with a single mold which is a finite noun. Yikes!
|
||||
|
||||
Nor is [list] a built-in feature. If you scroll back up to the
|
||||
mold definition, you will not see any mention of lists - or any
|
||||
other generic data structure. Actually, [list] is just a gate
|
||||
in the kernel, like [dec] or [add] or [mill].
|
||||
|
||||
So when I write
|
||||
|
||||
((list :[@ @]) [[2 3] [37 42] 0])
|
||||
|
||||
ie, rectifying this noun, just as we might write
|
||||
|
||||
(mold [%cell %atom [%fork [%cube 12] [%cube 32]]])
|
||||
|
||||
what is the product mold? We'll see the answer in the next
|
||||
lesson. But it can only involve %hold.
|
||||
|
||||
In Watt, a finite and strict language, %hold is essentially lazy
|
||||
evaluation done manually. A list mold is *logically* infinite -
|
||||
that is, if you keep evaluating the holds, you can evaluate them
|
||||
ad infinitum. If Watt was implemented in Haskell, this would be
|
||||
done automatically rather than manually, and molds would be an
|
||||
infinite/lazy data structure.
|
||||
|
||||
But Watt is defined in Watt, not Haskell. (Well, it should
|
||||
be defined in Watt. Right now, of course, it's in C.) So
|
||||
lazy evaluation happens manually - we expand a %hold when we need
|
||||
to, and not otherwise.
|
||||
|
||||
A crucial property of Watt that makes this work is that all molds
|
||||
are *rational*: that is, we can expand them indefinitely, but at
|
||||
a certain point they always repeat themselves. This allows us to
|
||||
compute the obvious set-theoretic functions needed for any type
|
||||
system, such as mold compatibility and orthogonality, without
|
||||
going into an infinite loop. It is possible to define Watt genes
|
||||
for which Mill is very slow, but it is not possible to define
|
||||
Watt genes for which it goes into an infinite loop. Or, at
|
||||
least, if it is, there's a bug in my code!
|
||||
|
||||
All right. I think this is enough for one lesson.
|
||||
|
||||
Here is a concrete problem to cogitate on: how would you write a
|
||||
function that tests whether molds A and B are orthogonal (no noun
|
||||
is in both A and B)? Or compatible (any noun in A is also in B)?
|
||||
Are these functions NP-complete? If so, how might one work
|
||||
around this in practice?
|
||||
404
Spec/watt/2-anatomy.txt
Normal file
404
Spec/watt/2-anatomy.txt
Normal file
@ -0,0 +1,404 @@
|
||||
Anatomy of Watt: 2, Genes
|
||||
|
||||
Watt now works - or at least, works well enough to implement a
|
||||
polymorphic quicksort gate with parameterized comparator. It can
|
||||
also define its own implementation data structures, although
|
||||
these are slightly underconstrained. You'll find these in
|
||||
Test/qsort.watt and Test/mill.watt respectively.
|
||||
|
||||
I will prepare something like a tutorial introduction soon. I
|
||||
would hold off on actually playing with Watt until this is
|
||||
available, though of course you can. For now, I want to finish
|
||||
understanding Watt the way it's meant to be understood. There is
|
||||
no part 3 of this essay! After "Anatomy of Watt," the rest is
|
||||
just a bunch of tedious memorization - like learning any
|
||||
language.
|
||||
|
||||
Basically, there are two kinds of languages. There are languages
|
||||
meant to be learned from the syntax down, and languages meant to
|
||||
be learned from the plumbing up.
|
||||
|
||||
Haskell is an example of the former. I have never seen anyone
|
||||
try to teach Haskell by explaining its internals. In fact, last
|
||||
time I looked, the Haskell type-inference algorithm was not
|
||||
even explained in the Haskell documentation. As in: when I tried
|
||||
to look it up, I got redirected to a '70s academic paper behind a
|
||||
paywall. The idea of Haskell is: you do enough tutorials, and
|
||||
eventually you'll just get it. I suppose this works for some.
|
||||
It makes me want to throw a professor through some drywall.
|
||||
|
||||
C is an example of the latter. To learn C, you learn what the C
|
||||
compiler is doing. This is only viable because the C compiler,
|
||||
at least in the abstract, is a terribly simple bit of code. C is
|
||||
really only one step beyond a macro assembler.
|
||||
|
||||
Watt, while not at all like C, has much the same relationship
|
||||
to Nock that C has to assembly language. The semantic core of
|
||||
Watt is quite straightforward. Mapping this core onto a textual
|
||||
language which doesn't look or feel like ass is a good bit more
|
||||
work; and even when this work is done, the machinery is not at
|
||||
all hidden. It can't be hidden. IMHO, it shouldn't be.
|
||||
|
||||
In the first part of "Anatomy," we discussed the mold system,
|
||||
which you'll see at the top of mill.watt. Today, we're going to
|
||||
look at the gene system, which is the rest of the file.
|
||||
Basically, molds are types and genes are code.
|
||||
|
||||
Recall that the basic toolchain in Watt is
|
||||
|
||||
- mill
|
||||
|| [mol=mold noc=nock]
|
||||
sub = mold
|
||||
gen = gene
|
||||
==
|
||||
|
||||
so, when you want to compile something,
|
||||
|
||||
(mill sub gen)
|
||||
|
||||
where [sub] is the subject type and [gen] is the Watt code,
|
||||
produces [mol noc], where [mol] is the product type and [noc] is
|
||||
the Nock formula. Rockit science, this is not.
|
||||
|
||||
A key point to remember: Nock has no global environment. Whether
|
||||
it's code or data, if it's not in the subject, it doesn't exist.
|
||||
|
||||
Now, the gene part of mill.watt is a lot bigger than the mold
|
||||
part. It is also a lot scarier - it includes a number of
|
||||
strange, four-letter symbols which may be Martian curse words.
|
||||
|
||||
However, like the mold system, the gene system is actually pretty
|
||||
simple. Almost all these stems are internal macros - that is,
|
||||
they are implemented simply by expansion. We could in fact
|
||||
expand them in the parser, although this would make for some
|
||||
pretty husky genes.
|
||||
|
||||
While a few more will probably be added, at present the only
|
||||
axiomatic stems are the initial block of 15, from %bail through
|
||||
%spot:
|
||||
|
||||
[%bail ~] :: !!
|
||||
[%cast fes=gene rum=gene] :: ^-
|
||||
[%cage fut=(list gene)] :: +-
|
||||
[%dbug lyq=gene] :: !#
|
||||
[%home cux=home lyq=gene] :: !:
|
||||
[%kick ved=wire suc=bolt] :: :=
|
||||
[%like rid=wire bul=gene] :: ?=
|
||||
[%link del=gene zim=gene] :: ~>
|
||||
[%load pir=book] :: |@
|
||||
[%name tem=mark caf=gene] :: +=
|
||||
[%nock fiz={3 4 5 6} dil=gene] :: :N
|
||||
[%quiz tes=gene bif=gene hob=gene] :: ?:
|
||||
[%rock gos=*] :: %=
|
||||
[%sure fes=gene gav=gene vep=gene] :: ^=
|
||||
[%spot xed=spot lyq=gene] :: !@
|
||||
|
||||
|
||||
Moreover, three of these (%dbug, %home, and %spot) are
|
||||
exclusively for tracing and debugging. This leaves us with just
|
||||
12 stems to explain.
|
||||
|
||||
(A noun of the above form is called a "rose." The head, or tag,
|
||||
is the "stem." The tail, or payload, is the "bulb." An atomic
|
||||
leaf is a "bud." An implicit pair, like the implicit cons in
|
||||
Nock, is a "twig." Your form can have either buds or twigs, but
|
||||
not of course both.)
|
||||
|
||||
Let's go through them in non-alphabetical order, from simplest
|
||||
to trickiest.
|
||||
|
||||
[%bail ~]
|
||||
|
||||
%bail: bail out.
|
||||
|
||||
Formally, in the Nock spec, this is an infinite loop. In
|
||||
practice it just returns you to the command line.
|
||||
|
||||
Produces
|
||||
++
|
||||
mol=%blot
|
||||
noc=[0 0]
|
||||
==
|
||||
|
||||
|
||||
[%rock gos=*]
|
||||
|
||||
%rock: specific constant.
|
||||
|
||||
Produces
|
||||
++
|
||||
mol = [%cube gos]
|
||||
noc = [1 gos]
|
||||
==
|
||||
|
||||
|
||||
[%nock fiz={3 4 5 6} dil=gene]
|
||||
|
||||
%nock: Nock operator.
|
||||
|
||||
Produces
|
||||
++
|
||||
mol =
|
||||
?- fiz
|
||||
- 3
|
||||
%blur
|
||||
- 4
|
||||
[%fork [%cube 0] [%cube 1]]
|
||||
- 5
|
||||
%atom
|
||||
- 6
|
||||
[%fork [%cube 0] [%cube 1]]
|
||||
==
|
||||
noc = [fiz noc.(mill sub dil)]
|
||||
==
|
||||
|
||||
|
||||
[%cage fut=(list gene)]
|
||||
|
||||
%cage: construct tuple.
|
||||
|
||||
This is Lisp cons - n-ary rather than binary, to reduce gene
|
||||
size. Eg, for gen=[%cage foo bar ~], we get
|
||||
|
||||
++
|
||||
mol = [%cell mol.(mill sub foo) mol.(mill sub bar)]
|
||||
noc = [noc.(mill sub foo) noc.(mill sub bar)]
|
||||
==
|
||||
|
||||
|
||||
[%link del=gene zim=gene]
|
||||
|
||||
%link: compose functions.
|
||||
|
||||
Produces
|
||||
++
|
||||
mol = mol.(mill mol.(mill sub del) zim)
|
||||
noc = [3 noc.(mill sub del)
|
||||
1 noc.(mill mol.(mill sub del) zim)
|
||||
]
|
||||
==
|
||||
|
||||
ie, in C syntax, zim(del(sub)).
|
||||
|
||||
|
||||
[%name tem=mark caf=gene]
|
||||
|
||||
%name: name data.
|
||||
|
||||
Produces
|
||||
++
|
||||
mol = [%face tem mol.(mill sub caf)]
|
||||
noc = noc.(mill sub caf)
|
||||
==
|
||||
|
||||
|
||||
[%cast fes=gene rum=gene]
|
||||
|
||||
%cast: mold conversion.
|
||||
|
||||
Use mold of [fes], nock of [rum]:
|
||||
|
||||
++
|
||||
mol = mol.(mill sub fes)
|
||||
noc = noc.(mill sub rum)
|
||||
==
|
||||
|
||||
given the congruence test
|
||||
|
||||
(nest mol.(mill sub rum) mol.(mill sub fes))
|
||||
|
||||
where (nest foo bar) is yes only if every noun in mold [foo]
|
||||
is also in mold [bar]. ("Only if," not "if and only if,"
|
||||
meaning that the test is conservative.)
|
||||
|
||||
|
||||
[%sure fes=gene gav=gene vep=gene]
|
||||
|
||||
%sure: congruence assertion.
|
||||
|
||||
Produces
|
||||
|
||||
(noc mol vep)
|
||||
|
||||
given the congruence test
|
||||
|
||||
(nest mol.(mill sub gav) mol.(mill sub fes))
|
||||
|
||||
See %cast for the semantics of (nest).
|
||||
|
||||
|
||||
[%quiz tes=gene bif=gene hob=gene]
|
||||
|
||||
%quiz: if-then-else
|
||||
|
||||
Produces (oversimplifying somewhat)
|
||||
++
|
||||
mol = [%fork mol.(mill sub bif) mol.(mill sub hob)]
|
||||
noc = [2
|
||||
noc.(mill sub tes)
|
||||
noc.(mill sub bif)
|
||||
noc.(mill sub hob)
|
||||
]
|
||||
--
|
||||
|
||||
%quiz analyzes the boolean structure of [tes] for any
|
||||
%like genes which specialize the subject. If such
|
||||
a specialization mold [pax] is produced, it is fused with
|
||||
[sub] for the [bif] branch - ie,
|
||||
|
||||
(mill [%fuse pax sub] bif)
|
||||
|
||||
|
||||
[%like rid=wire bul=gene]
|
||||
|
||||
%like: test mold membership
|
||||
|
||||
%like tests whether a fragment of the subject, designated by
|
||||
[rid], is in the mold produced by the subject and [bul]. The
|
||||
result is a standard Nock loobean: 0 for yes, 1 for no.
|
||||
|
||||
[rid] must be a "flat" wire (see part 1 for the definition of
|
||||
[wire], or see the description of %kick below), meaning
|
||||
only parts, no hooks - ie, it must reference a fragment of
|
||||
the subject, not a functional pseudo-attribute.
|
||||
|
||||
[bul] must be a simple, flat mold - %like will not generate
|
||||
code for any old [bul]. Recursive molds, cones, etc, are not
|
||||
allowed - as a matter of policy, rather than ability.
|
||||
Rather, it is used only for simple disambiguation between
|
||||
forks, eg, matching stems.
|
||||
|
||||
See %quiz for how %like is used to specialize type.
|
||||
|
||||
|
||||
[%load pir=book]
|
||||
|
||||
%load: load code
|
||||
|
||||
%load creates a cone, which is a [data code] pair. [pir],
|
||||
the book, is a bush: either [mark gene] or [book book].
|
||||
This is translated into Nock code with the same geometry.
|
||||
[mark gene] becomes [nock]; [[mark gene] [mark gene]]
|
||||
becomes [nock nock]; and so on.
|
||||
|
||||
The subject for these formulas is always the cone itself.
|
||||
Mill does not compute type signatures; rather, the cone
|
||||
mold simply preserves the entire book.
|
||||
|
||||
Thus, (mill sub [%load [%myname mycode]]) generates
|
||||
|
||||
++
|
||||
[%cone sub [%myname mycode]]
|
||||
noc.(mill [%cone sub [%myname mycode]] mycode)
|
||||
--
|
||||
|
||||
|
||||
[%kick ved=wire suc=bolt]
|
||||
|
||||
%kick: use with changes
|
||||
|
||||
%kick is our last and most difficult stem. You might even
|
||||
say that all other kinds of gene are the supporting cast for
|
||||
%kick. Basically, Watt *is* %kick.
|
||||
|
||||
Basically, [ved] is a part or hook within the subject, and
|
||||
[suc] is a list of changes to the subject.
|
||||
|
||||
Recall the definitions of (wire) and (bolt):
|
||||
|
||||
- port
|
||||
|~
|
||||
**
|
||||
@:mark
|
||||
[%find tic=step vix=mark]
|
||||
[%frag haz=axis]
|
||||
==
|
||||
|
||||
- wire
|
||||
(list port)
|
||||
|
||||
- bolt
|
||||
(list :[p=wire q=gene])
|
||||
|
||||
So it looks like there are three kinds of ports. But there
|
||||
are only two: %find and %frag. To reduce gene size,
|
||||
|
||||
[%find 0 vix]
|
||||
|
||||
can be expressed as just [vix].
|
||||
|
||||
%frag maps directly to the Nock fragment operator, 0. %find
|
||||
searches for either a %face mold with a matching mark, or a
|
||||
cone with a matching mark in its book. If [tic] is nonzero,
|
||||
it searches into that mark or in the cone data with (dec
|
||||
tic). Otherwise, it either returns the face fragment matching
|
||||
the mark, or invokes the cone formula matching the mark. In
|
||||
the latter case, again, the subject is the cone itself.
|
||||
|
||||
If [suc] is nonzero, it specifies a list of edits to be
|
||||
applied to either the fragment or the cone subject. So, in
|
||||
the latter case, we edit the data and call the code. This
|
||||
can produce very strange and powerful effects.
|
||||
|
||||
A simple example of these strange and powerful effects is
|
||||
the common, or garden, function call. In Watt terms, we are
|
||||
kicking a gate. Suppose, for instance, we call
|
||||
|
||||
(add foo bar)
|
||||
|
||||
This does exactly what it might do in, say, Lisp: it produces
|
||||
the sum of foo and bar. Indeed I have shamelessly borrowed
|
||||
the Lisp syntax. But Watt is not, after all, a lambda
|
||||
language - so what happens behind the scenes is much
|
||||
stranger.
|
||||
|
||||
When the parser parses (add foo bar), it becomes the macro
|
||||
|
||||
[%mang
|
||||
[%kick [%add ~] ~]
|
||||
[%cage
|
||||
[%kick [%foo ~] ~]
|
||||
[%kick [%bar ~] ~]
|
||||
~
|
||||
]
|
||||
]
|
||||
|
||||
%mang means "call." This expands to a somewhat hefty macro
|
||||
which I won't burden you with at present. Let's look at what
|
||||
it does, though.
|
||||
|
||||
First we need to resolve %add. This is a hook in the kernel.
|
||||
But the hook does not actually add - rather, it produces a
|
||||
"gate," whose mold will be of the form
|
||||
|
||||
[%cone
|
||||
[%cell arg=mold env=mold]
|
||||
[0 add-gene]
|
||||
]
|
||||
|
||||
Thus, a gate is a cone whose data is a pair [arg env], and
|
||||
whose code is one nameless gene (since there's only one, a
|
||||
name would be superfluous). In the case of this particular
|
||||
gate, [arg] is the default argument for add - [0 0], and
|
||||
[env] is the aforementioned kernel, a cone whose book is all
|
||||
the gates in Cato/k300.watt, and whose data is ~, constant 0.
|
||||
|
||||
In order to call this add function on [foo bar], therefore,
|
||||
we need to (a) edit the gate to replace the default argument
|
||||
with [foo bar], and (b) invoke hook 0. Hence:
|
||||
|
||||
[%kick
|
||||
[0 0] :: kick hook 0
|
||||
[ [+4 :: changing fragment 4 - arg
|
||||
[%cage ;; to [foo bar]
|
||||
[%kick [%foo 0] 0]
|
||||
[%kick [%bar 0] 0]
|
||||
0
|
||||
]
|
||||
]
|
||||
0
|
||||
]
|
||||
]
|
||||
|
||||
After a while, this will feel completely natural to you - and
|
||||
lambda reduction will seem like bizarre alien technology.
|
||||
1
Spec/watt/297.nock
Normal file
1
Spec/watt/297.nock
Normal file
File diff suppressed because one or more lines are too long
3004
Spec/watt/297.watt
Normal file
3004
Spec/watt/297.watt
Normal file
File diff suppressed because it is too large
Load Diff
1
Spec/watt/298.nock
Normal file
1
Spec/watt/298.nock
Normal file
File diff suppressed because one or more lines are too long
2982
Spec/watt/298.watt
Normal file
2982
Spec/watt/298.watt
Normal file
File diff suppressed because it is too large
Load Diff
42
Spec/watt/A.txt
Normal file
42
Spec/watt/A.txt
Normal file
@ -0,0 +1,42 @@
|
||||
slon ~> X [del=gene zim=gene] [zim] in [del]
|
||||
gant := X [ved=rope suc=list+[rope gene]] use with changes
|
||||
blin |* E [bov=gene pir=list+gene] load and apply
|
||||
boce ?& E [das=list+gene] yes iff all of [das] are yes
|
||||
perd ^+ X [fes=gene rum=gene] [rum] perd to [fes], geometric
|
||||
brip :^ E [mef=skel] skeleton lamb
|
||||
halc ^- X [fes=gene rum=gene] [rum] perd to [fes], genetic
|
||||
crot ^@ E [rum=gene] [rum] perd to bead
|
||||
dbug !? X [lyq=gene] activate internal debug
|
||||
delc :$ E [mef=skel] skeleton stub
|
||||
feng ?> E [tes=gene bif=gene] if [tes], then [bif], else fail
|
||||
flec :- E [buz=gene] fire with default
|
||||
flot |- E [cug=gene] hot lamb
|
||||
frez &~ E [dil=gene] pray
|
||||
garc :+ E [buz=gene pum=list+gene] fire with list
|
||||
glax ?+ E [feg=gene bem=list+pike] examine [feg], externally
|
||||
glem -> E [hig=gene muc=gene] [muc] in [hig +]
|
||||
clep X [pir=bush+[mark gene]] load book
|
||||
tarn ^= X [fes=gene gav=gene vep=gene] [vep], since [gav] matches [fes]
|
||||
gult X [fiz=(3 4 5 6 7 8) dil=gene] nock operator
|
||||
stol ?: X [tes=gene bif=gene hob=gene] if [tes], then [bif], else [hob]
|
||||
lisc -< E [hig=gene muc=gene] [hig] in [muc +]
|
||||
lome |= E [cug=gene] cold lamb
|
||||
sard :* X [caw=list+[mark gene]] classic American tuple
|
||||
malk |+ E [pir=list+[mark gene]] book as list
|
||||
neft &^ E [dil=gene] inc
|
||||
peld ?| E [das=list+gene] yes iff any of [das] are yes
|
||||
pont => E [han=mark dur=gene leb=gene] [leb] in [[han=dur] +]
|
||||
prex ?< E [tes=gene hob=gene] if [tes], then fail, else [hob]
|
||||
pung :~ E [buz=gene lep=gene] fire lamb, direct
|
||||
rald ^* E [rum=gene] [rum] perd to blur
|
||||
rulf =< E [han=mark dur=gene leb=gene] [dur] in [[han=leb] +]
|
||||
spot X [xed=[[@ @] [@ @] lyq=gene] source position, [at to] [lin col]
|
||||
serd |: E [tep=gene von=gene] lamb construction
|
||||
poos X [cux=lab lyq=gene] source label
|
||||
spal &~ E [dil=gene] cell
|
||||
stiv ~< E [del=gene zim=gene] [del] in [zim]
|
||||
trup ?! E [gix=gene] not
|
||||
veck &* E [dil=gene] raw eval
|
||||
forb ?= X [rid=rope bul=gene] yes iff [rid] is like [bul]
|
||||
wamp &= E [dil=gene] eq
|
||||
zact ?- E [mox=rope bem=list+pike] examine [mox], internally
|
||||
31
Spec/watt/E.txt
Normal file
31
Spec/watt/E.txt
Normal file
@ -0,0 +1,31 @@
|
||||
blin |* E [bov=gene pir=list+[mark gene]] load and apply
|
||||
boce ?& E [das=list+gene] yes iff all of [das] are yes
|
||||
brip :^ E [mef=skel] skeleton lamb
|
||||
crot ^@ E [rum=gene] [rum] perd to bead
|
||||
delc :$ E [mef=skel] skeleton stub
|
||||
drol || E [nix=skel gub=skel von=gene] lamb with cast
|
||||
feng ?> E [tes=gene bif=gene] if [tes], then [bif], else fail
|
||||
flec :- E [buz=gene] call with default
|
||||
flot |- E [cug=gene] hot lamb
|
||||
frez &~ E [dil=gene] pray
|
||||
garc :+ E [buz=gene pum=list+gene] call with list
|
||||
glax ?+ E [feg=gene bem=list+pike] examine [feg], externally
|
||||
glem -> E [hig=gene muc=gene] [muc] in [hig +]
|
||||
lisc -< E [hig=gene muc=gene] [hig] in [muc +]
|
||||
lome |= E [cug=gene] cold lamb
|
||||
malk |+ E [pir=list+[mark gene]] book as list
|
||||
neft &^ E [dil=gene] inc
|
||||
peld ?| E [das=list+gene] yes iff any of [das] are yes
|
||||
plom :. E [fut=list+gene] nameless tuple
|
||||
pont => E [han=mark dur=gene leb=gene] [leb] in [[han=dur] +]
|
||||
prex ?< E [tes=gene hob=gene] if [tes], then fail, else [hob]
|
||||
pung :~ E [buz=gene lep=gene] call lamb, direct
|
||||
rald ^* E [rum=gene] [rum] perd to blur
|
||||
rulf =< E [han=mark dur=gene leb=gene] [dur] in [[han=leb] +]
|
||||
stur |: E [tep=skel von=gene] lamb construction
|
||||
spal &~ E [dil=gene] cell
|
||||
stiv ~< E [del=gene zim=gene] [del] in [zim]
|
||||
trup ?! E [gix=gene] not
|
||||
veck &* E [dil=gene] raw eval
|
||||
wamp &= E [dil=gene] eq
|
||||
zact ?- E [mox=rope bem=list+pike] examine [mox], internally
|
||||
15
Spec/watt/X.txt
Normal file
15
Spec/watt/X.txt
Normal file
@ -0,0 +1,15 @@
|
||||
clep X [pir=bush+[mark gene]] load book
|
||||
dbug !? X [lyq=gene] activate internal debug
|
||||
forb ?= X [rid=rope bul=gene] yes iff [rid] is like [bul]
|
||||
gant := X [ved=rope suc=list+[rope gene]] use with changes
|
||||
gult X [fiz=(3 4 5 6 7) dil=gene] nock operator
|
||||
griv && X [dil=gene zep=noun] raw formula
|
||||
halc ^- X [fes=gene rum=gene] [rum] perd to [fes], genetic
|
||||
perd ^+ X [fes=gene rum=gene] [rum] perd to [fes], geometric
|
||||
poos X [cux=lab lyq=gene] source label
|
||||
pret X [daq=clod] constant, cube
|
||||
sard :* X [caw=list+[mark gene]] classic American tuple
|
||||
slon ~> X [del=gene zim=gene] [zim] in [del]
|
||||
spot X [xed=[[@ @] [@ @] lyq=gene] source position, [at to] [lin col]
|
||||
stol ?: X [tes=gene bif=gene hob=gene] if [tes], then [bif], else [hob]
|
||||
tarn ^= X [fes=gene gav=gene vep=gene] [vep], since [gav] matches [fes]
|
||||
92
Spec/watt/atoms.txt
Normal file
92
Spec/watt/atoms.txt
Normal file
@ -0,0 +1,92 @@
|
||||
Coinage of Watt
|
||||
|
||||
|
||||
Name Definition Example as printed Comment
|
||||
-------------------------------------------------------------------------------
|
||||
%blob opaque noun ~02Aw9cbfG21 ~0 prefix and uw
|
||||
%many coin list ._foo_bar__ underscore delimited
|
||||
~ %c codepoint ~--urbit.rocks~21 UTF-32 codepoint array
|
||||
~ %da absolute time ~2012.8.3..21.30.12..beef.dead galactic time, AD/BC
|
||||
~323-.6.10 death of Alexander
|
||||
~ %dr relative time ~d30.h20.m15.s12..dead.beef GT, relative
|
||||
~ %f flag .y boolean, 0=yes and 1=no
|
||||
.n
|
||||
~ %n null ~ absence of information
|
||||
~ %if IPv4 address .232.12.9.1
|
||||
~ %is IPv6 address .0.0.0.0.0.0.dead.beef
|
||||
~ %p phonemic ~pic memorable integer
|
||||
~-
|
||||
~nopgen
|
||||
~nopgen-durban
|
||||
~nopgen-durban--picmec-micmac
|
||||
~ %rd real-double .~28.4089
|
||||
~ %rh real-half .~~34
|
||||
~ %rq real-quad .~~~17
|
||||
~ %rs real-single .-576.78
|
||||
|
||||
~ %sb signed 2
|
||||
~ %sd signed 10
|
||||
~ %sh signed 16
|
||||
~ %sv signed 32
|
||||
~ %sw signed 64
|
||||
|
||||
~ %ub unsigned 2
|
||||
~ %ud unsigned 10
|
||||
~ %ux unsigned 16
|
||||
~ %uv unsigned 32
|
||||
~ %uw unsigned 64
|
||||
|
||||
~ %t text ~~urbit.rocks~21 literal UTF-8
|
||||
~ %ta legible span ~.under~-score [a/z 0/9 - . ~ _]
|
||||
~ %tas symbolic span foo-bar-baz [a/z -, start a/z]
|
||||
|
||||
sack prefix tree, with status (& good, | no good, * postponed)
|
||||
|
||||
a/z %tabc symbol &
|
||||
1/9 %ud unsigned decimal &
|
||||
0 %ud unsigned decimal &
|
||||
. %
|
||||
b %ub unsigned binary &
|
||||
h %uh unsigned hex &
|
||||
v %uv unsigned base32 &
|
||||
w %uw unsigned base64 &
|
||||
|
||||
.
|
||||
y,n %f booleans 0 and 1 &
|
||||
0/9 %rs single precision real *
|
||||
%ib ipv4 &
|
||||
%il ipv6 &
|
||||
~ %rh half precision real *
|
||||
. %rd double precision real *
|
||||
.. %rq quad precision real *
|
||||
-
|
||||
0/9 %rs single precision real *
|
||||
~ %rh half precision real *
|
||||
. %rd double precision real *
|
||||
.. %rq quad precision real *
|
||||
_ [%many] encoded list, _ and __
|
||||
|
||||
-
|
||||
1/9 %sd signed decimal
|
||||
0 %sd signed decimal
|
||||
b %sb signed binary
|
||||
h %sh signed hex
|
||||
v %sv signed base32
|
||||
w %sw signed base64
|
||||
-
|
||||
1/9 %sd signed decimal
|
||||
0 %sd signed decimal
|
||||
b %sb signed binary
|
||||
h %sh signed hex
|
||||
v %sv signed base32
|
||||
w %sw signed base64
|
||||
~ $c ucs32 string
|
||||
|
||||
~ %n null
|
||||
~ %t utf8 string (escaped)
|
||||
. %ta unescaped span
|
||||
- %p zero post
|
||||
a/z %p post
|
||||
0 [%blob] jam as base64
|
||||
* %da absolute date
|
||||
* %dr relative date
|
||||
58
Spec/watt/fdirose.txt
Normal file
58
Spec/watt/fdirose.txt
Normal file
@ -0,0 +1,58 @@
|
||||
!! "hopven" %zike
|
||||
!# "hopdax" %zush
|
||||
!% "hopmit" %zoot
|
||||
!: "hopdig" %zalt
|
||||
!` "hoptic" %zole
|
||||
%* "mitras" %teck
|
||||
%+ "mitpod" %bung
|
||||
%- "mitnub" %fung
|
||||
%. "mitdot" %gnum
|
||||
%: "mitdig" %mung
|
||||
%= "mitben" %mack
|
||||
%^ "mithat" %tung
|
||||
%~ "mitsig" %hang
|
||||
%| "mitbar" %gath
|
||||
.* "dotras" %sail
|
||||
.= "dotben" %sing
|
||||
.? "dotask" %dust
|
||||
.^ "dothat" %vint
|
||||
:* "digras" %prex
|
||||
:+ "digpod" %trex
|
||||
:- "dignub" %twix
|
||||
:^ "dighat" %quax
|
||||
:~ "digsig" %slax
|
||||
;+ "lompod" %fist
|
||||
;- "lomnub" %mast
|
||||
=+ "benpod" %gant
|
||||
=- "bennub" %tang
|
||||
=< "bender" %claf
|
||||
=> "benred" %flac
|
||||
?! "askhop" %vern
|
||||
?& "askamp" %chan
|
||||
?* "askras" %moze
|
||||
?- "asknub" %grel
|
||||
?. "askdot" %lort
|
||||
?: "askdig" %trol
|
||||
?< "askder" %marg
|
||||
?= "askben" %plin
|
||||
?> "askred" %gram
|
||||
?| "askbar" %dorn
|
||||
?~ "asksig" %fent
|
||||
^$ "hatbuc" %germ
|
||||
^% "hatmit" %velt
|
||||
^* "hatras" %mave
|
||||
^+ "hatdig" %pock
|
||||
^- "hatnub" %cast
|
||||
^: "hatpod" %stil
|
||||
^= "hatben" %bran
|
||||
^? "hatask" %hint
|
||||
^@ "hatpat" %grit
|
||||
^~ "hatsig" %wost
|
||||
|% "barmit" %tash
|
||||
|* "barras" %pank
|
||||
|- "barnub" %vamp
|
||||
|: "bardig" %sunt
|
||||
|= "barben" %lome
|
||||
|? "barask" %rond
|
||||
|~ "barsig" %lonk
|
||||
|
||||
184
Spec/watt/gto.txt
Normal file
184
Spec/watt/gto.txt
Normal file
@ -0,0 +1,184 @@
|
||||
new:
|
||||
bar |
|
||||
bas \
|
||||
buc $
|
||||
cab _ :: XX dun
|
||||
cen %
|
||||
col :
|
||||
com ,
|
||||
doq "
|
||||
dot .
|
||||
fas /
|
||||
gal <
|
||||
gar >
|
||||
hax #
|
||||
hep -
|
||||
kel {
|
||||
ker }
|
||||
ket ^
|
||||
lus +
|
||||
pel (
|
||||
pam &
|
||||
per )
|
||||
pat @ :: XX mat
|
||||
sel [
|
||||
sem ;
|
||||
ser ]
|
||||
sig ~
|
||||
soq '
|
||||
tar *
|
||||
tic `
|
||||
tis =
|
||||
wut ?
|
||||
zap !
|
||||
|
||||
old:
|
||||
del < gal
|
||||
pel ) par
|
||||
bar | bar
|
||||
hes $ hes
|
||||
sed } ker
|
||||
bot ' soc
|
||||
ket ^ ket
|
||||
sep - mus
|
||||
cab _ cab
|
||||
lep ( pal
|
||||
sig ~ sig
|
||||
com , com
|
||||
led > gar
|
||||
tam ; sem
|
||||
cas ? wut
|
||||
lyc = tis
|
||||
tar * tar
|
||||
dax # hax
|
||||
mit % cen
|
||||
tec ` tic
|
||||
deg : col
|
||||
ned ] ser
|
||||
tob " doc
|
||||
den [ sel
|
||||
nov \ bas
|
||||
von / fas
|
||||
des { kel
|
||||
pam & pam
|
||||
wat @ pat
|
||||
dot . dot
|
||||
pes + lus
|
||||
zap ! zap
|
||||
|
||||
Watt GTO: Gran Tabula Operazioni
|
||||
|
||||
|= %brts AM "bartis" "funk" declare a function
|
||||
|
||||
|
||||
|
||||
(Copied from watt.watt - recopy if in doubt.)
|
||||
::::
|
||||
::
|
||||
++ gene
|
||||
$& [p=gene q=gene]
|
||||
$%
|
||||
[%% p=axis]
|
||||
::
|
||||
[%brts p=gene q=gene]
|
||||
[%brls p=gene q=gene]
|
||||
[%brdt p=gene]
|
||||
[%brhp p=gene]
|
||||
[%brtr p=gene q=gene]
|
||||
::
|
||||
[%clkt p=gene q=gene r=gene s=gene]
|
||||
[%clhp p=gene q=gene]
|
||||
[%clls p=gene q=gene r=gene]
|
||||
[%clsg p=(list gene)]
|
||||
[%cltr p=(list gene)]
|
||||
::
|
||||
[%cntr p=twig q=gene r=(list >[p=gene q=gene])]
|
||||
[%cncl p=gene q=gene]
|
||||
[%cndt p=gene q=gene]
|
||||
[%cnkt p=gene q=gene r=gene s=gene]
|
||||
[%cnbc p=term]
|
||||
[%cnls p=gene q=gene r=gene]
|
||||
[%cnhp p=gene q=(list gene)]
|
||||
[%cnhx p=twig]
|
||||
[%cnsg p=twig q=gene r=gene]
|
||||
[%cnts p=twig q=(list >[p=gene q=gene])]
|
||||
::
|
||||
[%dtkt p=gene]
|
||||
[%dtls p=gene]
|
||||
[%dtpt p=term q=@]
|
||||
[%dtsg p=term q=*]
|
||||
[%dttr p=gene q=gene]
|
||||
[%dtts p=gene q=gene]
|
||||
[%dtwt p=gene]
|
||||
::
|
||||
[%bcbr p=gene q=gene]
|
||||
[%bccb p=gene]
|
||||
[%bccl p=(list gene)]
|
||||
[%bccn p=gene q=(list gene)]
|
||||
[%bcgr p=gene]
|
||||
[%bckt p=gene]
|
||||
[%bcpm p=gene q=gene]
|
||||
[%bctr p=gene]
|
||||
[%bcts p=?([%atom odor] %noun %cell %flag %null)]
|
||||
[%bcwt p=gene q=(list gene)]
|
||||
::
|
||||
[%ktbr p=gene]
|
||||
[%ktls p=gene q=gene]
|
||||
[%ktdt p=gene q=gene]
|
||||
[%ktgl p=gene q=gene]
|
||||
[%ktgr p=gene q=gene]
|
||||
[%kthp p=gene q=gene]
|
||||
[%ktpm p=gene]
|
||||
[%ktsg p=gene]
|
||||
[%ktts p=term q=gene]
|
||||
[%ktwt p=gene]
|
||||
::
|
||||
[%brcb p=gene q=(map term foot)]
|
||||
[%brcn p=(map term foot)]
|
||||
[%brkt p=gene q=(map term foot)]
|
||||
::
|
||||
[%sgbr p=gene q=gene]
|
||||
[%sgcl p=[p=@ q=@] q=gene]
|
||||
[%sgcn p=chop q=gene r=(list >[p=term q=gene]) s=gene]
|
||||
[%sgdt p=chop q=gene]
|
||||
[%sggl p=$|(term [p=term q=gene]) q=gene]
|
||||
[%sggr p=$|(term [p=term q=gene]) q=gene]
|
||||
[%sgbc p=term q=gene]
|
||||
[%sghx p=term q=gene]
|
||||
[%sgkt p=gene]
|
||||
[%sgls p=@ q=gene]
|
||||
[%sghp p=@ q=gene]
|
||||
[%sgpm p=gene q=gene]
|
||||
[%sgsg p=gene q=gene]
|
||||
[%sgts p=gene q=gene]
|
||||
::
|
||||
[%smcl p=gene q=(list gene)]
|
||||
[%smdq p=(list goop)]
|
||||
[%smsg p=gene q=(list gene)]
|
||||
::
|
||||
[%tsgl p=gene q=gene]
|
||||
[%tsgr p=gene q=gene]
|
||||
[%tsls p=gene q=gene]
|
||||
[%tshp p=gene q=gene]
|
||||
::
|
||||
[%wtbr p=(list gene)]
|
||||
[%wthp p=gene q=(list >[p=gene q=gene])]
|
||||
[%wtcl p=gene q=gene r=gene]
|
||||
[%wtcn p=gene q=gene]
|
||||
[%wtdt p=gene q=gene r=gene]
|
||||
[%wtts p=gene q=gene]
|
||||
[%wtgl p=gene q=gene]
|
||||
[%wtgr p=gene q=gene]
|
||||
[%wtls p=gene q=gene r=(list >[p=gene q=gene])]
|
||||
[%wtpm p=(list gene)]
|
||||
[%wtsg p=gene q=gene r=gene]
|
||||
[%wtzp p=gene]
|
||||
::
|
||||
[%zpcb p=spot q=gene]
|
||||
[%zpcm p=gene q=gene]
|
||||
[%zpcn ~]
|
||||
[%zpfs p=gene]
|
||||
[%zpsm p=gene q=gene]
|
||||
[%zpts p=gene]
|
||||
[%zpzp ~]
|
||||
==
|
||||
5
Spec/watt/runes.txt
Normal file
5
Spec/watt/runes.txt
Normal file
@ -0,0 +1,5 @@
|
||||
s/csdt/wtdt/g
|
||||
s/cslc/wtts/g
|
||||
s/csps/wtls/g
|
||||
s/cssp/wtms/g
|
||||
s/mtdt/cndt/g
|
||||
117
Spec/watt/sss-reviews.txt
Normal file
117
Spec/watt/sss-reviews.txt
Normal file
@ -0,0 +1,117 @@
|
||||
Dear Curtis,
|
||||
|
||||
We are sorry to inform you that your paper has not been selected for
|
||||
presentation at the Workshop on Self-sustaining Systems (S3) 2010 at The
|
||||
University of Tokyo, Japan.
|
||||
|
||||
Attached you will find the reviewers' comments. We hope you find them
|
||||
useful for improving your paper and for resubmitting to another event.
|
||||
|
||||
Best regards,
|
||||
Hidehiko and Robert
|
||||
|
||||
|
||||
=========================== REVIEWS ==========================
|
||||
|
||||
---------------------------- REVIEW 1 --------------------------
|
||||
PAPER: 3
|
||||
TITLE: Watt: A Self-Sustaining Functional Language
|
||||
|
||||
|
||||
SUMMARY
|
||||
|
||||
The author presents Watt and Nock. Watt is said to be a "functional
|
||||
programming for stupid people like you". Nock is said to be the "model".
|
||||
|
||||
EVALUATION
|
||||
|
||||
A workshop contribution does not have to be perfect, but it needs to
|
||||
be presented in a way that allows for a technical evaluation. This paper
|
||||
is written in a different style. The paper is unclear and incomprehensible.
|
||||
In many places it is vague, for example, "The relationship between Urth and
|
||||
Earth is unclear". At some places it is humurous, for example, "Urth code
|
||||
is nothing like Earth code". In other places it is simply insulting, for
|
||||
example, "Watt is functional programming for stupid people like you".
|
||||
|
||||
Comments:
|
||||
|
||||
"Watt is C, A is the machine instruction set, B is the C source for CC,
|
||||
and C is the executable for CC". C???
|
||||
"spec is is generally"=> "spec is generally"
|
||||
"Watt is dishwater; Urbit is vaporware". What?
|
||||
"eg" => "e.g.," Same for ie.
|
||||
"It has has all the flaws" => "It has all the flaws"
|
||||
"slowness, ..., and slowness". Once is slow enough.
|
||||
|
||||
|
||||
|
||||
---------------------------- REVIEW 2 --------------------------
|
||||
PAPER: 3
|
||||
TITLE: Watt: A Self-Sustaining Functional Language
|
||||
|
||||
|
||||
This paper presents a self-sustaining functional language: Watt.
|
||||
Watt is defined by a very small kernel which compiles itself to
|
||||
Nock, which is a simple non-lambda automaton. Nock is defined
|
||||
with very concise spec in English and pseudocode.
|
||||
|
||||
My major concern is that there is only an alpha release of the
|
||||
language with a lot of flaws and I can not tell from the paper
|
||||
if there are efficient and practical way to improve the flaws.
|
||||
For example, to have Watt program with reasonable performance.
|
||||
|
||||
Although it seems the author has very good reason to use an
|
||||
alien language to create Watt, it is still hard to understand
|
||||
the language and design intuition. It would be better if the
|
||||
paper can explain more about the design intuition, for example,
|
||||
why it only defines noun and does not introduce type, variables and
|
||||
functions etc. Also it is not clear about the programmability
|
||||
of Watt. What kinds of programs can easily be expressed? And what kinds
|
||||
of programs can it not easily express? And it still looks not clear
|
||||
to me in which domain Watt can beat other existing language and
|
||||
how.
|
||||
|
||||
Also it would be good if there is an example to illustrate Watt.
|
||||
A small but complete Watt program would be good.
|
||||
|
||||
There are some redundant words in the paper, for example: in
|
||||
Section 1.2 Practical, the 5th paragraph, the second sentence,
|
||||
there is an extra 'is' and in the 9th paragraph, the second
|
||||
sentence, there is an extra 'since'.
|
||||
|
||||
|
||||
|
||||
---------------------------- REVIEW 3 --------------------------
|
||||
PAPER: 3
|
||||
TITLE: Watt: A Self-Sustaining Functional Language
|
||||
|
||||
|
||||
The paper describes a minimal computation kernel (called Nock) and a statically typed functional language (Watt) built on top of it.
|
||||
|
||||
I think the approach of a minimal kernel with obvious execution semantics and a
|
||||
real language that maps on top of it is interesting and well worth pursuing. It
|
||||
is also clearly relevant to S3. The problem I have with this paper is that it
|
||||
does not really help me to understand what is going on with Nock and Watt.
|
||||
While Nock is probably fully specified by the formulas given, it is very hard
|
||||
to see what they are doing. It would have been helpful to see some detailed
|
||||
examples to understand Nock a bit more directly.
|
||||
|
||||
The same problem is even more pronounced for the section about Watt. We learn
|
||||
some things about Watt (compiles to Nock, statically typed, type inference,
|
||||
...), however, the actual working of the language remains unclear. The example
|
||||
code in Figure 2 and 3 is essentially inscrutable. I think that again some very
|
||||
simple and fully explained examples could have helped to understand the
|
||||
language and the intuition behind it better. On the other hand, I regard some
|
||||
parts of the Watt sections as not really necessary for the paper. It is not
|
||||
that helpful to get a list of semi-arbitrary names for glyphs and digraphs.
|
||||
|
||||
I understand the reasoning behind not using standard names for constructs in
|
||||
the language. However, the paper doesn't do a good enough job at telling me
|
||||
what the non-standard names actually mean, which leads to the fact that I don't
|
||||
understand the standard, nor the non-standard names.
|
||||
|
||||
Another issue of the paper is the idiosyncratic and partially arcane way to
|
||||
describe things and the unconventional language. I was left with the impression
|
||||
that this approach to writing was more an end in itself and not a mean to make
|
||||
the reader understand better. While reading the paper I sometimes felt vaguely
|
||||
insulted, which is not something you want your readers to be.
|
||||
1029
Spec/watt/sss10.tex
Normal file
1029
Spec/watt/sss10.tex
Normal file
File diff suppressed because it is too large
Load Diff
166
Spec/watt/wattbib.bib
Normal file
166
Spec/watt/wattbib.bib
Normal file
@ -0,0 +1,166 @@
|
||||
@inproceedings{hindleymilner,
|
||||
author = {Damas, Luis and Milner, Robin},
|
||||
title = {Principal type-schemes for functional programs},
|
||||
booktitle = {POPL '82: Proceedings of the 9th ACM SIGPLAN-SIGACT symposium on Principles of programming languages},
|
||||
year = {1982},
|
||||
isbn = {0-89791-065-6},
|
||||
pages = {207--212},
|
||||
location = {Albuquerque, New Mexico},
|
||||
doi = {http://doi.acm.org/10.1145/582153.582176},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
|
||||
@misc{graham100yr,
|
||||
author = {Graham, Paul},
|
||||
year = {2003},
|
||||
title = {The hundred-year language},
|
||||
howpublished = "\url{http://www.paulgraham.com/hundred.html}"
|
||||
}
|
||||
|
||||
@article{skcombinator,
|
||||
author = {Sch{\"{o}}nfinkel, M.},
|
||||
citeulike-article-id = {2546429},
|
||||
journal = {Math Annalen},
|
||||
keywords = {lcbbbib},
|
||||
pages = {305--316},
|
||||
posted-at = {2008-03-17 14:30:48},
|
||||
priority = {3},
|
||||
title = {{\"{U}}ber die Bausteine der mathematischen Logik},
|
||||
volume = {92},
|
||||
year = {1924}
|
||||
}
|
||||
|
||||
@inproceedings{tromp,
|
||||
author = {John Tromp},
|
||||
title = {Binary Lambda Calculus and Combinatory Logic},
|
||||
booktitle = {Proceedings of the 5th Conference on Real Numbers and Computers, RNC5},
|
||||
year = {2003},
|
||||
pages = {214}
|
||||
}
|
||||
|
||||
@misc{grahamarc,
|
||||
author = {Graham, Paul},
|
||||
year = {2001},
|
||||
title = {Arc at 3 weeks},
|
||||
howpublished = "\url{http://www.paulgraham.com/arcll1.html}"
|
||||
}
|
||||
|
||||
@misc{grahamcore,
|
||||
author = {Graham, Paul},
|
||||
year = {2008},
|
||||
title = {First priority: core language},
|
||||
howpublished = "\url{http://www.paulgraham.com/core.html}"
|
||||
}
|
||||
|
||||
@misc{piumartacola,
|
||||
author = {Piumarta, Ian},
|
||||
year = {2005},
|
||||
title = {Making COLAs with Pepsi and Coke},
|
||||
howpublished = "\url{http://piumarta.com/papers/colas-whitepaper.pdf}"
|
||||
}
|
||||
|
||||
@misc{tarverqi,
|
||||
author = {Tarver, Mark},
|
||||
year = {2009},
|
||||
title = {Functional programming with Qi},
|
||||
howpublished = "\url{http://www.lambdassociates.org/Book/page000.htm}"
|
||||
}
|
||||
|
||||
@article{kaymaxwell,
|
||||
author = {Feldman, Stuart},
|
||||
title = {A Conversation with Alan Kay},
|
||||
journal = {Queue},
|
||||
volume = {2},
|
||||
number = {9},
|
||||
year = {2005},
|
||||
issn = {1542-7730},
|
||||
pages = {20--30},
|
||||
doi = {http://doi.acm.org/10.1145/1039511.1039523},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
|
||||
@article{mccarthylisp,
|
||||
author = {McCarthy, John},
|
||||
title = {History of LISP},
|
||||
journal = {SIGPLAN Not.},
|
||||
volume = {13},
|
||||
number = {8},
|
||||
year = {1978},
|
||||
issn = {0362-1340},
|
||||
pages = {217--223},
|
||||
doi = {http://doi.acm.org/10.1145/960118.808387},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
|
||||
@article{haskell98,
|
||||
author = {Simon {Peyton Jones} and others},
|
||||
title = {The {Haskell} 98 Language and Libraries: The
|
||||
Revised Report},
|
||||
journal = {Journal of Functional Programming},
|
||||
volume = 13,
|
||||
number = 1,
|
||||
pages = {0--255},
|
||||
month = {Jan},
|
||||
year = 2003,
|
||||
note =
|
||||
{\url{http://www.haskell.org/definition/}}
|
||||
}
|
||||
|
||||
@inproceedings{crashonly,
|
||||
author = {Candea, George and Fox, Armando},
|
||||
title = {Crash-only software},
|
||||
booktitle = {HOTOS'03: Proceedings of the 9th conference on
|
||||
Hot Topics in Operating Systems},
|
||||
year = {2003},
|
||||
pages = {12--12},
|
||||
location = {Lihue, Hawaii},
|
||||
publisher = {USENIX Association},
|
||||
address = {Berkeley, CA, USA},
|
||||
}
|
||||
|
||||
@inproceedings{unixtrouble,
|
||||
author = {Leon, Lorenzo De and Harris, William G. and Evens,
|
||||
Martha},
|
||||
title = {Is there really trouble with UNIX?},
|
||||
booktitle = {CHI '83: Proceedings of the SIGCHI conference
|
||||
on Human Factors in Computing Systems},
|
||||
year = {1983},
|
||||
isbn = {0-89791-121-0},
|
||||
pages = {125--129},
|
||||
location = {Boston, Massachusetts, United States},
|
||||
doi = {http://doi.acm.org/10.1145/800045.801595},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
|
||||
@article{kaysmalltalk,
|
||||
author = {Kay, Alan C.},
|
||||
title = {The early history of Smalltalk},
|
||||
journal = {SIGPLAN Not.},
|
||||
volume = {28},
|
||||
number = {3},
|
||||
year = {1993},
|
||||
issn = {0362-1340},
|
||||
pages = {69--95},
|
||||
doi = {http://doi.acm.org/10.1145/155360.155364},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
|
||||
@inproceedings{namedcontent,
|
||||
author = {Jacobson, Van and Smetters, Diana K. and Thornton,
|
||||
James D. and Plass, Michael F. and Briggs, Nicholas H. and
|
||||
Braynard, Rebecca L.},
|
||||
title = {Networking named content},
|
||||
booktitle = {CoNEXT '09},
|
||||
year = {2009},
|
||||
isbn = {978-1-60558-636-6},
|
||||
pages = {1--12},
|
||||
location = {Rome, Italy},
|
||||
doi = {http://doi.acm.org/10.1145/1658939.1658941},
|
||||
publisher = {ACM},
|
||||
address = {New York, NY, USA},
|
||||
}
|
||||
75
Spec/zeno/1.txt
Normal file
75
Spec/zeno/1.txt
Normal file
@ -0,0 +1,75 @@
|
||||
1. zeno: a 32-bit Nock interpreter
|
||||
|
||||
The core of the Watt reference distribution is zeno, a 32-bit
|
||||
Nock interpreter.
|
||||
|
||||
zeno is by no means as efficient as possible. For instance, a
|
||||
mature version would generate bytecode or machine code for
|
||||
bottleneck Nock, not rely entirely on hardcoded jets. However,
|
||||
zeno is designed to extend well in this sort of direction. It is
|
||||
also easily generalizable to a 64-bit model.
|
||||
|
||||
In many ways, zeno is a typical language runtime system.
|
||||
However, it has some unusual large-scale features:
|
||||
|
||||
- zeno is a direct interpreter.
|
||||
|
||||
zeno does not generate byte or machine code. It runs Nock
|
||||
formulas straight out of the noun tree. Nock itself can be
|
||||
seen as a kind of "treecode" - it is designed for direct
|
||||
execution.
|
||||
|
||||
- zeno cannot call foreign functions.
|
||||
|
||||
There is no way to call system-level C functions from Nock.
|
||||
How absurd would it be to make a system call from SQL? However
|
||||
absurd it would be, it would be much more absurd in Nock.
|
||||
|
||||
- zeno is jet-propelled.
|
||||
|
||||
Naive Nock is inherently inefficient; eg, decrement is an O(n)
|
||||
operation. To rectify this, zeno loads external accelerators
|
||||
called "jets," written in C, which match well-known Nock
|
||||
formulas (such as decrement). Every jet must match Nock
|
||||
semantics exactly; zeno can test this automatically.
|
||||
|
||||
Can a jet call a foreign function? Yes, but only if it is
|
||||
doing so to precisely match Nock semantics. For instance, if
|
||||
you have a tuned C implementation of a pure function such as
|
||||
crypto, Unicode collation, etc, etc, you can call it from a jet
|
||||
- so long as the jet formula matches perfectly.
|
||||
|
||||
It is impossible to perform input from a matching jet. If you
|
||||
perform output from jets, armed men will come to your house at
|
||||
night and kill you. You probably think I'm joking about this.
|
||||
|
||||
- zeno is pausable (and should be stable).
|
||||
|
||||
In other words, zeno can be halted and restarted without OS
|
||||
tools - it can participate in cooperative multitasking. More
|
||||
or less a requirement for any serious interpreter, but still
|
||||
worth mentioning. At present halting is a hack, but it should be
|
||||
upgraded to a genuine transaction model.
|
||||
|
||||
- zeno does not use the C stack for nested computations.
|
||||
|
||||
More or less implied in the previous.
|
||||
|
||||
- zeno does not use heuristic memory management.
|
||||
|
||||
Ie, garbage collection. May I speak frankly? Managing memory
|
||||
is the work of the programmer. GC is the work of Satan.
|
||||
When you assign the programmer's work to the interpreter,
|
||||
your fingers are working for Satan.
|
||||
|
||||
Nor is it a question of malloc() and "riding the bus." Since
|
||||
nouns are acyclic, the only question in noun memory management
|
||||
is how to improve on classic reference counting. Not a
|
||||
heuristic algorithm - and not one that requires pausing the UI.
|
||||
(If you're of a certain age, every time you see Safari spin its
|
||||
wheel, you think: "Garbage collecting... done.")
|
||||
|
||||
The default allocation scheme in zeno is not reference
|
||||
counting, but a three-pointer seniority scheme. This "Seuss
|
||||
system" works well for some algorithms, not so well for others.
|
||||
For the latter, there is reference counting.
|
||||
363
Spec/zeno/2.txt
Normal file
363
Spec/zeno/2.txt
Normal file
@ -0,0 +1,363 @@
|
||||
Memory structure of Zeno (the loom):
|
||||
|
||||
1. Layout
|
||||
|
||||
You may know the typical Unix process layout, in which heap
|
||||
grows upward from low memory, and stack grows downward
|
||||
from high memory. The general advantage of this layout
|
||||
is zero fragmentation: heap and stack can grow as far
|
||||
toward each other as possible, until they meet.
|
||||
|
||||
This design is independent of the actual structures that grow
|
||||
from both ends of a linear address space. We might just as
|
||||
well have two heaps growing toward each other, or two stacks.
|
||||
|
||||
The loom allocator is the latter - two stacks, growing toward
|
||||
each other. A stack is actually a more powerful structure
|
||||
than a heap; if you have a stack and you want a heap, you can
|
||||
always push one on top of the stack. If you have a heap
|
||||
and you want a (contiguous) stack, you are SOL.
|
||||
|
||||
We call these opposed stacks "beams." A loom is two symmetric
|
||||
beams, one growing up from the bottom of memory, the other
|
||||
growing down from the top. The obvious constraint is that the
|
||||
beams must never cross. The unused area between them may be of
|
||||
any length and at any position.
|
||||
|
||||
(The loom design is not Nock-specific. Any functional language
|
||||
with acyclic data structures can use it. For instance, the same
|
||||
approach could be used for functional processing of XML.)
|
||||
|
||||
All loom addresses are word (32-bit) addresses. The loom
|
||||
pointer format can address 2^28 words, or 1GB, which is
|
||||
adequate for most light-duty programming tasks.
|
||||
|
||||
A "ray" is a 29-bit word offset onto a beam. If bit 29
|
||||
is 0, the ray grows forward from 0 and is "west." If bit
|
||||
29 is 1, the ray grows backward from the end of the loom,
|
||||
and is "east." East and west address spaces overlap; any
|
||||
word in the loom has an east address and a west address.
|
||||
|
||||
(The loom mapping cannot be implemented in hardware by any
|
||||
existing MMU I know of, but it is of course much simpler than a
|
||||
page table, and relatively alacritous in software. Twisted
|
||||
pointers of various kinds are typical ingredients in any dynamic
|
||||
language implementation.)
|
||||
|
||||
All u3 nouns are represented by the 32-bit word type "rat."
|
||||
If bit 31 of a rat is 0, it is a "cat" - a direct atom.
|
||||
Bits 0-30 of a cat are an unsigned 31-bit integer.
|
||||
|
||||
A rat can be a special value, u3_none - not a noun. A
|
||||
rat which is not u3_none is a "fox."
|
||||
|
||||
If bit 31 of a rat is 1, bits 0-28 are a ray which points
|
||||
to an indirect noun - a "dog." If bit 30 is 0, the dog is
|
||||
a "pom" - an indirect cell. If bit 30 is 1, the noun is a
|
||||
"pug" - an indirect atom.
|
||||
|
||||
Bit 29 on a dog is set iff the dog has special information
|
||||
behind the pointer, including but not limited to allocation
|
||||
header (block and reference count).
|
||||
|
||||
Although poms and pugs cannot be referenced through C pointers,
|
||||
because a ray is not a C pointer and requires specialized address
|
||||
arithmetic, their shape is described by these simple structures:
|
||||
|
||||
struct u3_cell {
|
||||
c3_w mug_w;
|
||||
u3_ray hed_ray;
|
||||
u3_ray tel_ray;
|
||||
};
|
||||
struct u3_atom {
|
||||
c3_w mug_w;
|
||||
c3_w len_w;
|
||||
c3_w buf_w[0];
|
||||
};
|
||||
|
||||
"c3_w" and "u3_ray" are both uint32_t. "buf_w" is really an
|
||||
array of length "len_w," of course.
|
||||
|
||||
"mug_w" is a 31-bit insecure hash which matches the Watt (mug)
|
||||
gate. The mug is computed lazily, as we need it - 0 is an
|
||||
out-of-band value. It is useful not just in associative and
|
||||
balanced trees, but also in simple functions like equality. If
|
||||
two dogs have the same mug, they may be different nouns; if they
|
||||
have different mugs, they must be different nouns.
|
||||
|
||||
We also borrow the mug field to maintain dag structure when
|
||||
copying nouns. Why copy a noun? See below.
|
||||
|
||||
2. Allocation (simple)
|
||||
|
||||
Now we consider the loom's allocation algorithm, the "Seuss
|
||||
system." The Seuss system manages memory with three pointers:
|
||||
"hat", "cap", and "mat".
|
||||
|
||||
"hat" and "cap", rays, are the tops of two opposing stack
|
||||
allocators, rays on opposite beams. Either the hat is east
|
||||
and the cap is west, or vice versa.
|
||||
|
||||
"mat" is a ray on the same beam as the cap, at or below it.
|
||||
|
||||
The loom is hence divided into three parts:
|
||||
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->.....box.......---pad----**can**........box.........<-|
|
||||
| |
|
||||
west east
|
||||
|
||||
The "pad" is free memory. The "box" is stable memory. The
|
||||
"can" is temporary memory. Again, the loom is symmetric. The
|
||||
can is always on one side of the pad, but that side can be east
|
||||
(as shown above), or west:
|
||||
|
||||
0 mat cap hat 1GB
|
||||
| | | | |
|
||||
|->.....box.......***can****--pad--........box.........<-|
|
||||
| |
|
||||
west east
|
||||
|
||||
The loom imposes a seniority restriction on all pointers. Box is
|
||||
senior to can. A reference stored in the can may point into the
|
||||
box, but a reference stored in the box cannot point into the can.
|
||||
|
||||
Since the box cannot point to the can, the can may be entirely
|
||||
destroyed without any corruption of the box. In general, the can
|
||||
is used for temporary allocation - ie, future garbage.
|
||||
|
||||
So the programmer in this context has two allocation choices.
|
||||
She can allocate garbage on the cap, or product on the hat.
|
||||
Rather than the normal model of stack and heap, she has two stack
|
||||
pointers - cap and hat - which grow toward each other.
|
||||
|
||||
In general, any function F is expected to produce its product as a
|
||||
fragmentation-free block of nouns, allocated in the box (on the
|
||||
hat), with pointers to older data in the box, but not of course
|
||||
the can. The can is expected to be reset after the call. Thus
|
||||
F is expected, as part of the calling convention, to pick up its
|
||||
own garbage.
|
||||
|
||||
Two stacks seems like a lot of choices for the programmer, every
|
||||
time she allocates a cell. Actually, though, this choice can in
|
||||
normal circumstances be made by the interpreter - because the
|
||||
only memory management problem in acyclic functional programming
|
||||
is composition.
|
||||
|
||||
When computing F(x), Zeno allocates product on the hat. When
|
||||
computing F(G(x)), Zeno allocates product of G(x) on the cap, and
|
||||
product of F(x) on the hat. If F(x) uses unmodified product of
|
||||
G(x), these must be copied from cap to hat. For the product of
|
||||
G(x) is, by definition, garbage.
|
||||
|
||||
And when computing F(G(H(x)))? Sadly, the calculations that
|
||||
produce garbage have a nasty tendency to allocate temporary nouns
|
||||
of their own. If we had an infinite number of beams, we'd be
|
||||
set. But we only have two.
|
||||
|
||||
Zeno handles the H(x) problem by reversing the beams. Let's work
|
||||
through a simple example:
|
||||
|
||||
As we start:
|
||||
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............----------*******....................<-|
|
||||
| |
|
||||
west east
|
||||
|
||||
"." is permanent memory, the box; "*" is temporary memory, the
|
||||
can; "-" is free memory, the pad.
|
||||
|
||||
Our goal is to allocate the product of F as ".", by pushing
|
||||
the hat a couple of columns east.
|
||||
|
||||
First, we depart to compute G. The product of G is "!", and is
|
||||
allocated on the cap. Not that G is hardcoded for this role, of
|
||||
course - it allocates its product on the hat, like any function.
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............--------!!*******....................<-|
|
||||
| | | |
|
||||
west mat hat east
|
||||
cap
|
||||
now now
|
||||
|
||||
Thus, so long as the VM exhibits east/west independence,
|
||||
we can compute G with the same code that computed F, on the
|
||||
opposite beam. And if G depends on another function, H?
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............????----!!*******....................<-|
|
||||
| | | | |
|
||||
west mat cap hat east
|
||||
now now now
|
||||
|
||||
The garbage of G - which is the product of H - is "?". How do we
|
||||
get H to allocate on the cap? By reversing the beams again.
|
||||
This solution can be iterated indefinitely - until, of course,
|
||||
the cap and hat collide. At this point you are out of memory.
|
||||
|
||||
We complete the calculation of G by retreating:
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............--------!!*******....................<-|
|
||||
| | | | |
|
||||
| hat cap mat east
|
||||
west now now now
|
||||
|
||||
We have now computed G and placed its product on the cap. So we
|
||||
are ready to compute F, placing its product on the hat. The
|
||||
product of F is "~":
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............~~------!!*******....................<-|
|
||||
| | | | |
|
||||
west hat cap mat east
|
||||
now now now
|
||||
|
||||
We then retract the cap, freeing the product of G:
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............~~--------*******....................<-|
|
||||
| | | | |
|
||||
west hat cap mat east
|
||||
now now now
|
||||
|
||||
Thus we have pushed the product of F, without any garbage,
|
||||
on the hat. The algorithm is optimal, except for the cost of
|
||||
copying temporary results - which varies from 0 to prohibitive.
|
||||
|
||||
One case in which the algorithm above needs improvement is
|
||||
tail-call compaction. In a tail-call loop, F(x) resolves to
|
||||
F(G(x)) - which resolves to F(G(G(x))), etc, etc.
|
||||
|
||||
The loom knows the final destination at all times and never needs
|
||||
to copy the result - but it also accumulates a pile of
|
||||
intermediate results, G(x), G(G(x)), etc, on the cap. Where
|
||||
"!" is G(x), "?" is G(G(x)), '#" is G(G(G(x))):
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............----##??!!*******....................<-|
|
||||
| | | | |
|
||||
| hat cap mat east
|
||||
west now now now
|
||||
|
||||
This is obviously craptastic. Can anything be done about it?
|
||||
That depends on one thing - whether G(G(x)) references G(x). If
|
||||
it does (for example, when inverting a list), no compaction is
|
||||
possible - there is nothing to free.
|
||||
|
||||
But if G(G(x)) does not reference G(x), we can simply slide
|
||||
G(G(x)) down the cap over its parent. In general, tail calls can
|
||||
be computed in fixed space if the new tail context does not
|
||||
reference the old tail context.
|
||||
|
||||
How can we determine this? Well, we could analyze the formula.
|
||||
In a compilation context, this is probably what we'd do. In an
|
||||
interpreter, however, there is no room for static analysis.
|
||||
|
||||
Therefore, the only way to determine whether G(G(x)) references
|
||||
G(x) is a brute-force nano-garbage collection. We simply chase
|
||||
any pointers in G(G(x)) and see if they fall into G(x). If not,
|
||||
we slide "?" down over "!". This is called "tamping."
|
||||
|
||||
Tamping is a effective optimization because its cost is
|
||||
proportional to the size of G(G(x)). This may be an arbitrarily
|
||||
large and complex noun, but we do not have to chase pointers
|
||||
outside G(G(x)). "?" cannot address "!" through either "." or
|
||||
"*", because "." and "*" cannot point to "!" due to seniority.
|
||||
|
||||
A tamped loom makes an excellent top-level default. For many
|
||||
algorithms, it is entirely impractical. But, if the implementor
|
||||
of the algorithm knows this, it is easy to request special
|
||||
treatment. The pad is an unfragmented block of memory - the
|
||||
appropriate input for any memory-management algorithm.
|
||||
|
||||
The Watt programmer, optimizing for Zeno, does so by using hints
|
||||
(Nock 11) to select one of three memory disciplines: %flee,
|
||||
%stay, and %keep. The above is the %flee discipline, which
|
||||
is the default. In general, the memory discipline defines what
|
||||
Zeno does where, under %flee, it would depart.
|
||||
|
||||
The %stay discipline never departs. Instead, it uses the cap as
|
||||
a conventional stack, and the hat as a conventional heap. Only
|
||||
control information is allocated on the cap. All product nouns -
|
||||
F(x), G(x) and H(x) - are allocated on the hat:
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............??!!~~----*******....................<-|
|
||||
| | | | |
|
||||
west hat cap mat east
|
||||
now now now
|
||||
|
||||
What do we do with G(x) and H(x)? We leak the motherfsckers.
|
||||
But at least there is no copying.
|
||||
|
||||
This is remedied by the %keep discipline. Remember that
|
||||
disciplines affect one thing: departure policy. In the %flee
|
||||
discipline, we depart; in the %stay discipline, we remain.
|
||||
|
||||
In %keep, we depart - but install a refcount allocator. In the
|
||||
departing frame, this upgrades the hat to a reference-counted
|
||||
heap. It also sets the memory discipline to %stay. Thus, in the
|
||||
departing frame, we do not leak but rather free.
|
||||
|
||||
Since we are refcounting in the departed frame, not the current
|
||||
frame, the result still needs to be copied back if used. It is
|
||||
good to copy out of an allocator, because the allocator doubles
|
||||
the size of a cell.
|
||||
|
||||
Therefore, if we compute F under %keep, we observe, in the
|
||||
departed context,
|
||||
|
||||
old old old
|
||||
0 hat cap mat 1GB
|
||||
| | | | |
|
||||
|->...............-----?=!?&*******....................<-|
|
||||
| | | | |
|
||||
west mat hat rut east
|
||||
cap
|
||||
now now now
|
||||
|
||||
"&" is the free list; "=" is a free block.
|
||||
|
||||
Using the allocator adds a fourth memory pointer, "rut", to the
|
||||
Seuss system. The rut sets (a) the location of the free list
|
||||
and (b) the boundaries of reference control. If the rut is set,
|
||||
before advancing the hat, zeno will try to allocate out of the
|
||||
free list.
|
||||
|
||||
Since nouns are acyclic, reference counting is always effective.
|
||||
Why bother with this loom business, then? Why not just a simple
|
||||
reference-counting allocator for all of memory?
|
||||
|
||||
One of the big performance problems with refcounting is its
|
||||
tendency to absolutely screw the hell out of your cache. Address
|
||||
space can be backed by anything - from on-chip cache to a tape
|
||||
drive. Many programs pass around references to memory they use
|
||||
much more rarely, and when they use this memory it is only to
|
||||
read them. If the entire space is in one reference pool, this
|
||||
will generate a shower of *writes* to deep data structures that
|
||||
are essentially static.
|
||||
|
||||
Reference counting in the loom is *local*. References only need
|
||||
to be tracked for nouns between rut and hat. Even if these nouns
|
||||
reference reference-counted nouns elsewhere in the loom, counts
|
||||
do not need to be updated for any noun between 0 and hat, or rut
|
||||
and 1GB.
|
||||
92
doc/atoms.txt
Normal file
92
doc/atoms.txt
Normal file
@ -0,0 +1,92 @@
|
||||
Coinage of Watt
|
||||
|
||||
|
||||
Name Definition Example as printed Comment
|
||||
-------------------------------------------------------------------------------
|
||||
%blob opaque noun ~02Aw9cbfG21 ~0 prefix and uw
|
||||
%many coin list ._foo_bar__ underscore delimited
|
||||
~ %c codepoint ~--urbit.rocks~21 UTF-32 codepoint array
|
||||
~ %da absolute time ~2012.8.3..21.30.12..beef.dead galactic time, AD/BC
|
||||
~323-.6.10 death of Alexander
|
||||
~ %dr relative time ~d30.h20.m15.s12..dead.beef GT, relative
|
||||
~ %f flag .y boolean, 0=yes and 1=no
|
||||
.n
|
||||
~ %n null ~ absence of information
|
||||
~ %if IPv4 address .232.12.9.1
|
||||
~ %is IPv6 address .0.0.0.0.0.0.dead.beef
|
||||
~ %p phonemic ~pic memorable integer
|
||||
~-
|
||||
~nopgen
|
||||
~nopgen-durban
|
||||
~nopgen-durban--picmec-micmac
|
||||
~ %rd real-double .~28.4089
|
||||
~ %rh real-half .~~34
|
||||
~ %rq real-quad .~~~17
|
||||
~ %rs real-single .-576.78
|
||||
|
||||
~ %sb signed 2
|
||||
~ %sd signed 10
|
||||
~ %sh signed 16
|
||||
~ %sv signed 32
|
||||
~ %sw signed 64
|
||||
|
||||
~ %ub unsigned 2
|
||||
~ %ud unsigned 10
|
||||
~ %uh unsigned 16
|
||||
~ %uv unsigned 32
|
||||
~ %uw unsigned 64
|
||||
|
||||
~ %t text ~~urbit.rocks~21 literal UTF-8
|
||||
~ %ta legible span ~.under~-score [a/z 0/9 - . ~ _]
|
||||
~ %tas symbolic span foo-bar-baz [a/z -, start a/z]
|
||||
|
||||
sack prefix tree, with status (& good, | no good, * postponed)
|
||||
|
||||
a/z %tabc symbol &
|
||||
1/9 %ud unsigned decimal &
|
||||
0 %ud unsigned decimal &
|
||||
. %
|
||||
b %ub unsigned binary &
|
||||
h %uh unsigned hex &
|
||||
v %uv unsigned base32 &
|
||||
w %uw unsigned base64 &
|
||||
|
||||
.
|
||||
y,n %f booleans 0 and 1 &
|
||||
0/9 %rs single precision real *
|
||||
%ib ipv4 &
|
||||
%il ipv6 &
|
||||
~ %rh half precision real *
|
||||
. %rd double precision real *
|
||||
.. %rq quad precision real *
|
||||
-
|
||||
0/9 %rs single precision real *
|
||||
~ %rh half precision real *
|
||||
. %rd double precision real *
|
||||
.. %rq quad precision real *
|
||||
_ [%many] encoded list, _ and __
|
||||
|
||||
-
|
||||
1/9 %sd signed decimal
|
||||
0 %sd signed decimal
|
||||
b %sb signed binary
|
||||
h %sh signed hex
|
||||
v %sv signed base32
|
||||
w %sw signed base64
|
||||
-
|
||||
1/9 %sd signed decimal
|
||||
0 %sd signed decimal
|
||||
b %sb signed binary
|
||||
h %sh signed hex
|
||||
v %sv signed base32
|
||||
w %sw signed base64
|
||||
~ $c ucs32 string
|
||||
|
||||
~ %n null
|
||||
~ %t utf8 string (escaped)
|
||||
. %ta unescaped span
|
||||
- %p zero post
|
||||
a/z %p post
|
||||
0 [%blob] jam as base64
|
||||
* %da absolute date
|
||||
* %dr relative date
|
||||
252
doc/book/0-intro.markdown
Normal file
252
doc/book/0-intro.markdown
Normal file
@ -0,0 +1,252 @@
|
||||
1: Introduction and philosophy
|
||||
==============================
|
||||
|
||||
Urbit is a new programming and execution environment
|
||||
designed from scratch. Any resemblance to existing languages
|
||||
or operating systems is coincidental, cosmetic, or inevitable.
|
||||
|
||||
## Urbit is a stack ##
|
||||
|
||||
Nock is a stateless virtual machine defined in 200 words. The
|
||||
Nock machine is sealed - all execution is "pure." Nock's goal is
|
||||
extreme commoditization of computing semantics.
|
||||
|
||||
Hoon is a high-level language which defines itself in Nock. Its
|
||||
self-compiling kernel, 7000 lines of code, specifies Hoon
|
||||
unambiguously; there is no Hoon spec. Hoon can be classified as
|
||||
a pure, strict higher-order static type-inferred functional
|
||||
language, with co/contra/bivariance and genericity. However,
|
||||
Hoon does not use lambda calculus, unification, or other
|
||||
constructs from "PL theory." Hoon also excels at handling and
|
||||
validating untyped data, a common task on teh Internets. Its
|
||||
syntax is entirely novel and initially quite frightening.
|
||||
|
||||
Arvo is a deterministic functional operating system defined in
|
||||
Hoon. While still basically a toy, it can serve web apps and
|
||||
network securely with other Arvo instances. An Arvo instance
|
||||
is designed to be a simple independent computer in the cloud.
|
||||
|
||||
It's possible to use Nock without Hoon, but there is no obvious
|
||||
reason to do so. It's not necessary to learn Nock to learn Hoon,
|
||||
but it helps a lot. The same for Hoon and Arvo. Therefore,
|
||||
we'll work through all three in order. in order. If you're
|
||||
convinced that you want to learn Urbit, feel free to skip the
|
||||
justifications below.
|
||||
|
||||
## Nock ##
|
||||
|
||||
Nock is a virtual machine, like the Java VM or Microsoft CLR.
|
||||
Just as you execute Java by compiling it to the JVM, you execute
|
||||
Hoon by compiling it to Nock.
|
||||
|
||||
Do you need to learn Nock to learn Hoon? In theory, no, just as
|
||||
you don't need to know anything about the JVM to learn Java.
|
||||
Indeed, in theory we could compile Hoon to the JVM (or Java to
|
||||
Nock). What's the difference between Nock and the JVM, anyway?
|
||||
Why do we need a new virtual machine? And since we'll only be
|
||||
programming in Hoon, why do we care how Hoon is executed?
|
||||
|
||||
There is no formal difference between Nock and the JVM. In
|
||||
theory, both are Turing-complete computers. In practice, they
|
||||
have just about nothing in common.
|
||||
|
||||
The main practical difference is that Nock is two orders of
|
||||
magnitude simpler. The JVM spec is a book. The Nock spec is 200
|
||||
words; it fits on a T-shirt; it gzips to 371 bytes. There are
|
||||
lots of other differences, but all follow from this.
|
||||
|
||||
Why does size matter? The goal of any programming language is to
|
||||
become a standard. Universal standardization equals world
|
||||
domination. The simpler a specification is, the easier to
|
||||
standardize. Nock is a practical interpreter as simple as the
|
||||
most frozen and fundamental of protocols or formats: IPv4, XML,
|
||||
JSON. A 200-word spec needs a standards process like a fish
|
||||
needs swim lessons. When a T-shirt goes to war with a book, it's
|
||||
like tanks against cavalry - or should be, anyway.
|
||||
|
||||
Since every program in Hoon (including the Hoon compiler) reduces
|
||||
to Nock, every program in Hoon inherits Nock's precision. If two
|
||||
Nock interpreters produce different results, one is wrong, and it
|
||||
is always easy to tell which - without a "standards lawyer." Can
|
||||
we imagine the end of incompatiblity?
|
||||
|
||||
Essential to actually realizing this promise is a second
|
||||
difference between Nock and the JVM, which is that the JVM can
|
||||
call Unix system calls and libraries, and Nock can't. Nock has
|
||||
no "native methods" or foreign-function interface. Nor is it
|
||||
ever extended, embellished, forked, improved or advanced.
|
||||
|
||||
Java began as a portable language; so did C. Most Java today is
|
||||
server-side Java, dependent no less than C on library and OS
|
||||
configuration. It is possible to write portable Java; it is
|
||||
possible to write portable C. It is not possible to write
|
||||
unportable Nock or Hoon. It is also not possible to write
|
||||
insecure Nock or Hoon, unless your interpreter is so broken
|
||||
there's an actual hole in its skull.
|
||||
|
||||
How does Nock obtain native CPU performance, if it can't call
|
||||
native code? This is actually a much more pressing problem in
|
||||
Nock than in conventional virtual machines, like the JVM, because
|
||||
naive Nock is hopelessly inefficient. Nock is defined in a page
|
||||
of pseudocode, and a naive interpreter can be written in a page
|
||||
of any language. But since Nock's only arithmetic operator is
|
||||
increment, decrement in your one-page interpreter is an `O(n)`
|
||||
operation. Addition is `O(n^2)`. And so on.
|
||||
|
||||
The programmer cannot solve this problem by calling a C function,
|
||||
because Nock can't do that. In theory, an optimizing Nock
|
||||
interpreter might be able to analyze the code and reduce it to a
|
||||
simpler equivalent. But this would be a true research problem.
|
||||
|
||||
Instead, a practical Nock engine simply recognizes code it knows
|
||||
and substitutes equivalent C functions, or "jets." For instance,
|
||||
in theory there are many different ways to express decrement in
|
||||
Nock, but in practice the Nock interpreter will execute only one:
|
||||
the decrement function in the Hoon kernel. Therefore, the only
|
||||
Nock decrement that must be optimized is the code that Hoon
|
||||
generates when it compiles its own decrement. All others will
|
||||
suck, so don't roll your own. Code recognition, as opposed to
|
||||
code analysis, is not a research problem.
|
||||
|
||||
Jet propulsion separates mechanism and policy, transferring the
|
||||
task of achieving native performance from the programmer to the
|
||||
sysadmin. The Hoon programmer must still use hints to mark
|
||||
functions for jet recognition, but cannot control or discern how
|
||||
these functions are actually executed. Of course, a correct jet
|
||||
is indistiguishable in every way, except timing, from naive Nock.
|
||||
The 200-word spec defines the result, not the algorithm.
|
||||
|
||||
We can see a jet as a sort of "functional device driver." For
|
||||
instance, an OpenGL programmer today has no idea whether her GL
|
||||
operations are implemented in software or by a GPU. This
|
||||
abstraction is essential to modern graphics programming.
|
||||
|
||||
When we compare jets to native calls, what are the pros and cons?
|
||||
Jets have only one disadvantage: high-performance code must be
|
||||
written twice, once in Hoon and once in C. Indeed, from the C
|
||||
programmer's perspective, Hoon is a specification language for
|
||||
your C functions. Hoon specifications are executable, of course,
|
||||
so you can test the two implementations against each other -
|
||||
again, transparently to the programmer. Moreover, the jet can
|
||||
even fail in special cases and drop back to the interpreter.
|
||||
|
||||
Hoon ships with a Nock that jet-propels most of the Hoon kernel,
|
||||
including most of the Hoon compiler. If you're wondering how we
|
||||
wrote Hoon in Hoon when we didn't have Hoon, the answer is that
|
||||
we wrote Hoon in C and evolved this C code into a mere jet. This
|
||||
process is not recommended unless absolutely necessary - by far
|
||||
the best way to write the jet pair is to write the Hoon first.
|
||||
|
||||
## Hoon ##
|
||||
|
||||
If I can summarize Hoon's goal, it's to be the C of functional
|
||||
programming. If you're not so arthritic that you learned to code
|
||||
in Turbo Pascal, you may never fully appreciate the metaphor.
|
||||
|
||||
All languages in the Algol procedural family, including both C
|
||||
and Pascal, map straightforwardly onto a conventional CPU. But
|
||||
Pascal and C handle this mapping very differently. Pascal and C
|
||||
both have pointers and arrays, but Pascal works hard to treat
|
||||
both pointers and arrays as mathematical abstractions. C drops
|
||||
the abstraction; it makes no bones about the fact that a pointer
|
||||
is a memory address.
|
||||
|
||||
To a Pascal purist, to anyone who thinks mathematically, this
|
||||
seemed hideous. C isn't really a high-level language at all -
|
||||
it's a glorified macro assembler. Mankind retreats to the cave.
|
||||
But to programmers who are not natural mathematicians, whose
|
||||
minds are mechanical rather than abstract, C is a lifesaver.
|
||||
Since most mathematicians are also good mechanical thinkers,
|
||||
whereas very few people are naturally adept at abstraction,
|
||||
C slew and pillaged the once promising empire of Pascal.
|
||||
|
||||
There are two broad families of functional language available
|
||||
today: Haskell/ML, and Lisp. The Haskell family is relatively
|
||||
abstract; the Lisp family, relatively concrete. Perhaps Lisp is
|
||||
about as abstract as Pascal; Haskell is far more abstract. Both
|
||||
rest on the fundamental abstraction of functional programming,
|
||||
the lambda calculus, and more generally the foundational
|
||||
metamathematics of the late 19th and early 20th centuries.
|
||||
|
||||
Hoon has nothing to do with any of this stuff. It has functions
|
||||
and types, or what appear to be functions and types. On closer
|
||||
inspection, they are not abstractions at all, just glorified Nock
|
||||
macros.
|
||||
|
||||
If we compare these concrete patterns to the genuine abstractions
|
||||
of Haskell, we see that - as with Pascal and C - Hoon is roughly
|
||||
as expressive as Haskell. Haskell has higher-order type
|
||||
inference; Hoon has "higher-order" "type" "inference." Some
|
||||
Haskell extensions have dependent types - Hoon has "refined"
|
||||
"types." Hoon, like Lisp, unlike Haskell, is also very
|
||||
comfortable with typeless data; it should be, because it has no
|
||||
types, only "types." The Hoon features and the Haskell
|
||||
abstractions have nothing in common - except that they solve the
|
||||
same problems for you, the programmer. In short, Hoon next to
|
||||
Haskell is a white shark next to a killer whale. The apparent
|
||||
resemblance is strictly superficial.
|
||||
|
||||
So we could describe Hoon as a pure, strict, higher-order typed
|
||||
functional language. But don't do this in front of a Haskell
|
||||
purist, unless you put quotes around "typed," "functional," and
|
||||
possibly even "language." We could also say "object-oriented,"
|
||||
with the same scare quotes for the cult of Eiffel.
|
||||
|
||||
Knowing Pascal made it harder, not easier, to learn C. Knowing
|
||||
Haskell or Lisp makes it harder to learn Hoon. Indeed, knowing
|
||||
either would have made it impossible for me to write Hoon. I do
|
||||
know C, of course, and the spirit of K&R is all over Hoon. Or so
|
||||
I'd like to think. Just as C is little more than a macro
|
||||
assembler for machine code, Hoon is little more than a macro
|
||||
assembler for Nock.
|
||||
|
||||
The most basic difference between Hoon and other languages is
|
||||
that Hoon is defined in Hoon. There is no formal Hoon spec -
|
||||
just a self-compiling compiler written in Hoon. The target of
|
||||
this compiler is, of course, Nock. Thus Hoon is as precisely
|
||||
defined as Nock, which is quite precisely indeed.
|
||||
|
||||
This would be true regardless of the size of Hoon in Hoon, but
|
||||
Hoon in Hoon is in fact quite small. The Hoon kernel is 7000
|
||||
lines; it gzips to 25K. But this includes not only the
|
||||
self-compiling compiler, but also all the standard libraries it
|
||||
needs. The compiler alone is 2500 lines, including a very
|
||||
intricate "monadic" parser, a non-Hindley-Milner "type inference"
|
||||
engine, and a Nock code generator. This reflects both the
|
||||
internal simplicity of Hoon and its expressiveness. If you know
|
||||
these 2500 lines, and an expert should, you _know_ Hoon.
|
||||
|
||||
On the other hand, the _apparent_ complexity of Hoon is very
|
||||
high. When you open a Hoon file, you are confronted with an
|
||||
enormous avalanche of barely structured line noise. Again this
|
||||
reminds us of C, which makes no attempt at the kind of abstract
|
||||
prettiness we expect from a Pascal or a Haskell. Learning Hoon
|
||||
involves learning nearly 100 ASCII digraph "runes."
|
||||
|
||||
Is this a harsh learning curve? Of course it is. On the other
|
||||
hand, it is not a mathematical task, but a mechanical one. It is
|
||||
trivial compared to the task of learning the Chinese alphabet,
|
||||
memorizing the Qu'ran, etc, all rote mental tasks routinely
|
||||
performed by normal human 11-year-olds. If you have an
|
||||
11-year-old who understands the Hindley-Milner algorithm, you
|
||||
have a remarkable young mathematician.
|
||||
|
||||
A practical programming language is first and foremost a UI for
|
||||
programmers - meaning human programmers. Concrete languages beat
|
||||
abstract ones because they play to the strengths of the human
|
||||
brain, and avoid its weaknesses. Functional programming is
|
||||
traditionally reserved for the topmost echelon of natural talent.
|
||||
I'd like to think that anyone who can learn to fix a Chevy can
|
||||
learn to write a Hoon function. We'll see if that's true.
|
||||
|
||||
A programming language is called a language for a reason - it
|
||||
should activate the human linguistic lobes. Learning Hoon
|
||||
is like learning a language very alien to your first, such as
|
||||
Chinese from English. Before you know Hoon, it looks like
|
||||
squiggles. Once you know Hoon, and the rote task of syntax
|
||||
processing is hardwired, you look at your screen and _see_
|
||||
the function. Or, at least, I do - I hope you can too.
|
||||
|
||||
## Arvo ##
|
||||
|
||||
Lorem ipsum.
|
||||
1107
doc/book/1-nock.markdown
Normal file
1107
doc/book/1-nock.markdown
Normal file
File diff suppressed because it is too large
Load Diff
81
doc/book/2-philosophy.markdown
Normal file
81
doc/book/2-philosophy.markdown
Normal file
@ -0,0 +1,81 @@
|
||||
2: Hoon - Philosophy
|
||||
=========
|
||||
|
||||
Yo, let's write some Hoon!
|
||||
|
||||
In this tutorial we're going to try to learn Hoon, without first
|
||||
learning either Nock or Arvo. You probably should at least skim
|
||||
the Nock doc though - learning Hoon without understanding Nock is
|
||||
a little like learning C without understanding how a CPU works.
|
||||
It is not easier than knowing both, it's harder.
|
||||
|
||||
As for Arvo, all we'll use of it here is the power to edit a
|
||||
library and type expressions on the command line. These are
|
||||
not hard things and we'll explain them as we go along.
|
||||
|
||||
We'll cover Hoon in three sections - philosophy, syntax, and
|
||||
semantics. You should probably just skip to syntax.
|
||||
|
||||
The good news about Hoon is that it compiles itself to Nock in
|
||||
3400 lines of Hoon. If this number is accurate (it is), Hoon
|
||||
is very expressive, or very simple, or both. (It's both.) The
|
||||
bad news is that it really has nothing at all in common, either
|
||||
syntactically or semantically, with anything you've used before.
|
||||
|
||||
In particular, please remember that _you are not too stupid_ to
|
||||
program in Hoon. Hoon is FP made stupid - for the stupid, by the
|
||||
stupid. (This is the real reason it's only 3400 lines.)
|
||||
|
||||
Maybe you've had some bad experiences with a higher-order typed
|
||||
functional language - like Haskell or OCaml. Dare we suspect
|
||||
that these experiences came on one of our nation's fine college
|
||||
campuses? Well, we have to admit, Hoon is a higher-order typed
|
||||
functional language. But really, don't let this discourage you.
|
||||
|
||||
First, Hoon hasn't been to college. Second, at least it's
|
||||
strict. And third, we don't use any of that PL theory shit.
|
||||
We're OS guys. Our mission is not to praise PL, but to drive it
|
||||
out of the CS department with a flaming sword, back to the
|
||||
fundless ghetto of math where it belongs. Hoon is 'street FP.'
|
||||
The only functional language it gives any real props to is JS.
|
||||
JS sucks, of course, but at least it's a player. (Scala is a
|
||||
player too, but it's also the size of a blue whale's ass.)
|
||||
|
||||
We hope we're not being too harsh on PL theory. The fact is that
|
||||
this branch of mathematics (constructive logic or whatever) is a
|
||||
perfectly adequate and remarkably elegant formal description of
|
||||
computing. But, of course, it is not the only such description.
|
||||
And it was originally created for mathematicians, not coders.
|
||||
|
||||
Nor is the math department's standard of elegance the only such
|
||||
standard. The programmer has his own design sense, which
|
||||
corresponds more closely to usability in a UI sense. To read a
|
||||
program is to simulate it in your head, and the skill needed to
|
||||
do this revolves around tracing long complex sequences of very
|
||||
simple transformations.
|
||||
|
||||
For these simple transformations, I think, we use a completely
|
||||
different processing path - less a mathematical intution, than a
|
||||
mechanical one. This is why many good C programmers are bad at
|
||||
symbolic math. Of course, we all should be good at all things -
|
||||
but are we? And this is why Hoon is not Haskell.
|
||||
|
||||
For example, it's very true and cool that you can represent all
|
||||
data as functions. It's also pretty neat that you can take a
|
||||
leak while standing on your head, and you always hit the bowl.
|
||||
To an OS guy it seems more interesting to represent functions as
|
||||
data. Like, you know how to send data over the network. Do you
|
||||
know how to send functions over the network?
|
||||
|
||||
(On the other hand, if only because Hoon is very immature, Haskell
|
||||
is good at many things that Hoon isn't good at. For instance,
|
||||
good list/container comprehensions are the pons asinorum of a
|
||||
functional language. Hoon's actually kind of suck. This is not
|
||||
(well, mostly not) because Hoon sucks, but because (a) they are
|
||||
some of the oldest library code in the system, and (b) they have
|
||||
never seen either end of a top-notch functional programmer.
|
||||
Despite the fact that category theory can go bite itself, people
|
||||
with more FP experience on more mature languages probably have a
|
||||
lot to contribute here.)
|
||||
|
||||
Anyway. That's enough philosophy. Come on, who needs it?
|
||||
326
doc/book/3-syntax.markdown
Normal file
326
doc/book/3-syntax.markdown
Normal file
@ -0,0 +1,326 @@
|
||||
3: Hoon - Syntax
|
||||
=========
|
||||
|
||||
Now, let's actually look at Hoon. Really, try not to recoil
|
||||
in horror. It's actually not anything like line noise.
|
||||
|
||||
Open the Hoon kernel - `urb/les/arvo/hoon.hoon`. Let's look at
|
||||
the full, official decrement function (line 549):
|
||||
|
||||
++ dec
|
||||
~/ %dec
|
||||
|= a=@
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
Whaa?
|
||||
|
||||
Any attempt to understand this in terms of any language you
|
||||
already know would clearly be mistaken. In both syntax and
|
||||
semantics, learning to program in Hoon is learning to program all
|
||||
over again. When we say from scratch, we mean from scratch!
|
||||
|
||||
It's actually worse than that - learning Hoon is learning to
|
||||
_read_ all over again. Hoon is a keyword-free language - any
|
||||
alphanumeric text in the program is part of the program. Where
|
||||
other languages have reserved words, Hoon has squiggles.
|
||||
|
||||
We use so many of these ASCII glyphs that we like to be able
|
||||
to read them out loud. A language is meant to be _said_. The
|
||||
squiggles have conventional names, sort of, some of them, some of
|
||||
them easy to say, others not so much. So we've renamed them:
|
||||
|
||||
ace space gal < per )
|
||||
bar | gar > sel [
|
||||
bas \ hax # sem ;
|
||||
buc $ hep - ser ]
|
||||
cab _ kel { sig ~
|
||||
cen % ker } soq '
|
||||
col : ket ^ tar *
|
||||
com , lus + tec `
|
||||
doq " pam & tis =
|
||||
dot . pat @ wut ?
|
||||
fas / pel ( zap !
|
||||
|
||||
You just have to memorize these names. Sorry.
|
||||
|
||||
But is this at least enough symbols? Alas, nowhere near.
|
||||
ASCII's glyph supply is not the greatest, but we can make all the
|
||||
squiggles we need by forming digraphs, or _runes_.
|
||||
|
||||
To pronounce a rune, concatenate the glyph names, stressing the
|
||||
first syllable and softening the second vowel into a "schwa."
|
||||
Hence, to say `~.`, say "sigdot." To say `|=`, say "bartis."
|
||||
Which has an inevitable tendency to turn into "barts" - a sin
|
||||
to be encouraged. In any language actually spoken by actual
|
||||
humans, laziness soon rounds off any rough edges.
|
||||
|
||||
So if we had to read the above decrement, omitting the spaces
|
||||
(which only a real purist would pronounce), we'd say: "luslus dec
|
||||
sigfas cen dec bartis a tis pat sigbar soq dec soq ketcab pat wutgal
|
||||
tis pel zero a per tislus b tis pat barhep wutcol tis pel a lus pel
|
||||
b per per b buc pel b lus pel b per per." The authorities would
|
||||
then arrive, and drag us out in a big net. Definitely don't do
|
||||
this at the airport.
|
||||
|
||||
Geeks being solitary by nature, opportunities for reading code
|
||||
aloud are limited. But studies by actual scientists have shown
|
||||
that even when we read silently, we activate the motor cortex
|
||||
that controls our vocal cords. Even if we never speak these
|
||||
squiggles, they're easier to _think_ if bound to simple sounds.
|
||||
|
||||
(And don't worry if you can't get yourself to say "lus" instead
|
||||
of "plus" for `+`, or "tar" instead of "star" for `*` - I have
|
||||
this problem myself. It's much easier to replace "underscore"
|
||||
with "cab" or "ampersand" with "pam.")
|
||||
|
||||
Hoon has almost 90 digraphic runes. They are easier to organize
|
||||
in your head, though, because the choice of glyph is not random.
|
||||
The second glyph in a rune means little or nothing, but the first
|
||||
defines a rough semantic category. These categories are:
|
||||
|
||||
| bar gates (ie, functions) (ie, one-method cores)
|
||||
? wut conditionals, booleans, tests
|
||||
: col tuples
|
||||
. dot nock operators
|
||||
$ buc factory macros (ie, type definitions)
|
||||
^ ket type conversions
|
||||
= tis compositions
|
||||
% cen invocations
|
||||
& pam gears (ie, objects) (ie, multi-method cores)
|
||||
~ sig hints
|
||||
; sem miscellaneous macros
|
||||
! zap special operations
|
||||
|
||||
Each rune has _[not]_ its own doc file in the `rune/190` directory. The
|
||||
name of the file is the name of the rune, minus the vowels.
|
||||
Thus, `|=` or "bartis" is _[not]_ defined in `rune/190/brts.txt`.
|
||||
|
||||
Opening this file, we see:
|
||||
|
||||
%brts |= "bartis"
|
||||
|
||||
define:
|
||||
[%brts p=gene q=gene]
|
||||
|
||||
expand:
|
||||
[%brts *] [%brcb p.gen (~(put by *(map term foot)) %% [%ash q.gen])]
|
||||
|
||||
There should be some actual discussion, but there isn't. Still,
|
||||
`brts.txt` is quite complete as a definition of `|=`. How? We
|
||||
need to step back a little.
|
||||
|
||||
When the Hoon parser parses a source file, it generates a noun
|
||||
called a `gene`. If you know what an AST is, a gene is an AST node.
|
||||
If you don't, don't worry about it.
|
||||
|
||||
Search the current kernel for `++ gene` - note double space.
|
||||
This code is both the type declaration for type `gene`, and
|
||||
a function that maps an untyped noun to a typed gene. In it
|
||||
you'll see the above definition,
|
||||
|
||||
[%brts p=gene q=gene]
|
||||
|
||||
Ie, one kind of gene is a triple whose head is the constant
|
||||
`%brts`, and whose tail is a pair of genes, `p` and `q`.
|
||||
|
||||
We also see the semantics of this rune: it expands to
|
||||
|
||||
[%brcb p.gen (~(put by *(map term foot)) %% [%ash q.gen])]
|
||||
|
||||
ie, `|=` is a built-in macro. But back to syntax.
|
||||
|
||||
What is `%brts`? The atom also known as `1937011298` or
|
||||
`0x73747262`. Simply a string mapped to an unsigned integer, LSB
|
||||
first. It's easy to see why the vowels got lost - `%bartis` is
|
||||
`126896762413410` or `0x736974726162`. On a 32-bit CPU with
|
||||
31-bit direct atoms, `%brts` is direct and `%bartis` indirect
|
||||
(not that the programmer can tell the difference). But you still
|
||||
say "bartis."
|
||||
|
||||
For instance, in the decrement above, we have
|
||||
|
||||
|= a=@
|
||||
~| 'dec'
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
In this `%brts`, `p` is
|
||||
|
||||
a=@
|
||||
|
||||
and `q` is
|
||||
|
||||
~| 'dec'
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
We are starting to see the principles of Hoon syntax. Let's make
|
||||
them clear.
|
||||
|
||||
First, for any rune, the Hoon parser has two kinds of syntax:
|
||||
normal and custom. Most runes, such as `|=`, have only normal
|
||||
syntax without custom syntax. Almost all runes with custom
|
||||
syntax also have normal. Custom can mean anything; normal
|
||||
is rigid and uniform.
|
||||
|
||||
All programming languages, but especially functional ones, face
|
||||
two difficult syntactic problems. One is controlling the large
|
||||
numbers of terminators that appear in any deeply nested tree
|
||||
structure - Lisp is infamous for its piles of right parens.
|
||||
These are not a serious usability problem, except inasmuch as you
|
||||
consider ugly a usability problem (which I do). Two, a more
|
||||
serious concern, is keeping complex routines from flowing off the
|
||||
right margin as tab depth increases.
|
||||
|
||||
A glance at the more complex organs of the Hoon kernel reveals
|
||||
that Hoon is relatively untroubled by either of these woes. But
|
||||
why? One dubious panacea for the terminator problem is the use
|
||||
of significant whitespace. Whitespace in Hoon is not
|
||||
significant. (To be exact, the presence or absence of whitespace
|
||||
matters, but the quantity never does.)
|
||||
|
||||
The answer is that the normal syntax for every rune has two
|
||||
forms: "wide" and "tall." As a functional language, Hoon does
|
||||
not distinguish between statements and expressions, but normal
|
||||
wide syntax is expression-like and tall is statement-like.
|
||||
|
||||
For instance, in our example above,
|
||||
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
is a tall normal form. The equivalent wide form is
|
||||
|
||||
?:(=(a +(b)) b $(b +(b)))
|
||||
|
||||
It's usually best to use the wide form if your gene fits on the
|
||||
line, but this is obviously an aesthetic choice. If your gene
|
||||
does not fit your margin (which should always be 80 columns),
|
||||
you have no choice but to go tall. For reasons that should be
|
||||
obvious, a tall gene can contain wide subgenes, but a wide gene
|
||||
cannot contain tall subgenes - just as, in procedural languages,
|
||||
a statement can contain expressions but not vice versa.
|
||||
|
||||
In the wide normal form, the rune is followed immediately (no
|
||||
whitespace) by a left paren ("pel"), then the subgenes with a
|
||||
single space between them, then a right paren ("per") as
|
||||
terminator. If the rune was inside the parens rather than a
|
||||
prefix, this would be the Lisp syntax.
|
||||
|
||||
In the tall normal form, any quantity of whitespace follows the
|
||||
rune, and separates the subgenes from each other. Where is the
|
||||
terminator? There is no terminator - in most cases.
|
||||
|
||||
Consider the `?:` rune, "wutcol," `%wtcl`. This is
|
||||
|
||||
[%wtcl p=gene q=gene r=gene]
|
||||
|
||||
Why should we need a terminator? We know `%wtcl`, whose
|
||||
semantics are if-then-else, has three subgenes. When the parser
|
||||
sees `?:` followed by space, it simply parses the next three
|
||||
genes and fills the rune with them.
|
||||
|
||||
This only works in runes with fixed tuple structure, which
|
||||
fortunately is most of them. A counterexample is `:*`, ie,
|
||||
|
||||
[%cltr p=(list gene)]
|
||||
|
||||
which is of variable length and needs a terminator. But we
|
||||
have no dangling parens, but an attractive tall closure:
|
||||
|
||||
:* %foo
|
||||
%bar
|
||||
%baz
|
||||
%moo
|
||||
==
|
||||
|
||||
whose equivalent wide normal is
|
||||
|
||||
:*(%foo %bar %baz %moo)
|
||||
|
||||
which no one would ever write, preferring the custom
|
||||
|
||||
[%foo %bar %baz %moo]
|
||||
|
||||
This leaves only one question: indentation. Since space is not
|
||||
significant (even linebreaks are irrelevant - the newline is just
|
||||
another space), the use of whitespace in tall forms is purely a
|
||||
matter of style. Style is very important, however!
|
||||
|
||||
The first law of Hoon indentation style is that all tall
|
||||
indentation is in two-space increments. (Tabs are illegal. If
|
||||
you pollute a Hoon file with ASCII 9, not only will it not parse,
|
||||
but thugs in ski masks will kick down your door and shoot you.
|
||||
You laugh! Try it!) Single spaces are for wide only.
|
||||
|
||||
The second law of Hoon indentation is that everything in the
|
||||
kernel is good indentation style. Or at least if it's not, it
|
||||
needs changed. The kernel shall be lapidary, noble, ideal and
|
||||
above all suspicion - a Doric column, a Tlingit totem pole,
|
||||
an Egyptian obelisk.
|
||||
|
||||
Tallness matters. The third law of Hoon indentation is that
|
||||
large genes should flow _down_ and not _across_ - like the
|
||||
decrement example above. The right margin is a precious resource
|
||||
not to be wasted. It's this law, when properly applied, that
|
||||
makes casual readers wonder if Hoon is a functional language at
|
||||
all. It doesn't have a program counter, but it looks like it
|
||||
does - at least when written right.
|
||||
|
||||
In list-structured runes, like the `:*` above, there is no choice
|
||||
but to lose right margin. Fortunately, most runes are tuples,
|
||||
and most have limited "fanout" - 1, 2, 3 or at most 4.
|
||||
|
||||
Both of our above examples - `|=` and `?:` - use "backstep"
|
||||
indentation which takes advantage of this tuple structure. For
|
||||
instance, `|=` has two subgenes, `p` and `q.` We put `p` on the
|
||||
same line as `|=`, set off by two spaces, losing 4 characters of
|
||||
margin. We put `q` _directly below_, losing no margin at all.
|
||||
|
||||
It so happens that in almost every actual case of `|=`, `p` (the
|
||||
function's argument) is relatively light, whereas `q` (the
|
||||
function's body) will be much heavier. Thus, with this pattern of
|
||||
indentation, we lose no margin and our code flows _down_.
|
||||
|
||||
We see this even more in `?:`, where the conditional test (which
|
||||
is much less likely to be heavy) is first and farthest right,
|
||||
followed by the "then" case indented two spaces, followed by the
|
||||
"else" case at the same indent as the rune.
|
||||
|
||||
Suppose your "else" is relatively light, and your "then" is
|
||||
heavy? You may prefer the `?.` rune, Hoon's "unless," which puts
|
||||
the else before the then. Or not. And in both `?:` and `?.`,
|
||||
the test (which of course can be arbitrarily heavy) is first.
|
||||
It is not necessary for your code to _always_ flow down and not
|
||||
across - just _mostly_.
|
||||
|
||||
The conventional principle which backstep indentation sacrifices,
|
||||
of course, is the idea that absolute indentation depth should
|
||||
correspond to tree depth, loop depth, or some other metric. Hoon
|
||||
is so deeply nested that if tab depth matched tree depth, your
|
||||
margins on anything interesting would be in the next cube to your
|
||||
right. There is perhaps a case for indenting loops, but we don't
|
||||
find we miss this cue at all.
|
||||
|
||||
The paucity of terminators also eliminates a lot of redundancy in
|
||||
the parser, which can result in relatively exciting syntax
|
||||
errors. Our experience is that this is seldom a big problem,
|
||||
because there are terminated tall forms and the cascade stops
|
||||
with them. It is often a small problem, however.
|
||||
382
doc/book/4-semantics.markdown
Normal file
382
doc/book/4-semantics.markdown
Normal file
@ -0,0 +1,382 @@
|
||||
4: Hoon - Semantics
|
||||
=========
|
||||
|
||||
Now let's actually learn to program in Hoon, which really isn't
|
||||
that hard. Unfortunately, we have to start by learning enough
|
||||
Arvo to not be utterly defenseless.
|
||||
|
||||
Start vere, the Arvo VM, which you created in chapter 2:
|
||||
|
||||
vere $mypier
|
||||
|
||||
You'll see a prompt of the form
|
||||
|
||||
~tasfyn-partyv/try=>
|
||||
|
||||
What does this prompt mean?
|
||||
|
||||
`~tasfyn-partyv` (or whatever) is your ship. `try` is your desk;
|
||||
that is, the project you're working on. There is no spur, or
|
||||
further current directory. The current case (revision) is the
|
||||
null case, `=`, ie, you are working in the present tense.
|
||||
|
||||
This is the `behn` prompt. Arvo is talking to you through the
|
||||
console vane `dill` from the processing vane `behn`. You can
|
||||
think of `behn` as a shell, a REPL or both. As either it is very
|
||||
barebones and can perform only a few basic tasks. You can see
|
||||
its source in Unix in `$URBIT_HOME/tasfyn-partyv/arvo/behn.hoon`,
|
||||
or print it in Urbit with `:cat /===/arvo/behn/hoon`.
|
||||
|
||||
As this correspondence implies, basically the way you get
|
||||
any kind of bulk information from Unix, into Urbit, is to write
|
||||
it into a Unix file whose path Urbit knows how to sync.
|
||||
|
||||
While learning Hoon we are not going to run any commands in
|
||||
`behn` or use its OS-level capabilities at all. We are just
|
||||
going to use it as a REPL. But we are still using it and should
|
||||
have no reason to fear it.
|
||||
|
||||
`behn` uses emacs control keys for history and editing.
|
||||
^ABEFKNPY all basically kind of work. (Since `dill` works at the
|
||||
character level, not the line level, this is not `readline`.)
|
||||
There are also special Arvo controls: ^CDWX.
|
||||
|
||||
^C will stop any working task (and cancel the event that caused
|
||||
it). If Urbit is waiting rather than working, ^C will kill the
|
||||
waiting task. ^X will cycle between waiting tasks and the
|
||||
command line (which can always create a new task). Think of it
|
||||
as switching windows, in a command-line sense. ^W switches
|
||||
ships, on a multi-ship pier. ^D exits back to Unix.
|
||||
|
||||
If there is an error you may see a stack trace. The bottom of
|
||||
the trace is the thing that caused the problem.
|
||||
|
||||
|
||||
|
||||
Now let's see how to use Hoon
|
||||
|
||||
|
||||
|
||||
Now, let's actually look at Hoon. Really, try not to recoil
|
||||
in horror. It's actually not anything like line noise.
|
||||
|
||||
Open the Hoon kernel - `urb/les/arvo/hoon.hoon`. Let's look at
|
||||
the full, official decrement function (line 549):
|
||||
|
||||
++ dec
|
||||
~/ %dec
|
||||
|= a=@
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
Whaa?
|
||||
|
||||
Any attempt to understand this in terms of any language you
|
||||
already know would clearly be mistaken. In both syntax and
|
||||
semantics, learning to program in Hoon is learning to program all
|
||||
over again. When we say from scratch, we mean from scratch!
|
||||
|
||||
It's actually worse than that - learning Hoon is learning to
|
||||
_read_ all over again. Hoon is a keyword-free language - any
|
||||
alphanumeric text in the program is part of the program. Where
|
||||
other languages have reserved words, Hoon has squiggles.
|
||||
|
||||
We use so many of these ASCII glyphs that we like to be able
|
||||
to read them out loud. A language is meant to be _said_. The
|
||||
squiggles have conventional names, sort of, some of them, some of
|
||||
them easy to say, others not so much. So we've renamed them:
|
||||
|
||||
ace space gal < per )
|
||||
bar | gar > sel [
|
||||
bas \ hax # sem ;
|
||||
buc $ hep - ser ]
|
||||
cab _ kel { sig ~
|
||||
cen % ker } soq '
|
||||
col : ket ^ tar *
|
||||
com , lus + tec `
|
||||
doq " pam & tis =
|
||||
dot . pat @ wut ?
|
||||
fas / pel ( zap !
|
||||
|
||||
You just have to memorize these names. Sorry.
|
||||
|
||||
But is this at least enough symbols? Alas, nowhere near.
|
||||
ASCII's glyph supply is not the greatest, but we can make all the
|
||||
squiggles we need by forming digraphs, or _runes_.
|
||||
|
||||
To pronounce a rune, concatenate the glyph names, stressing the
|
||||
first syllable and softening the second vowel into a "schwa."
|
||||
Hence, to say `~.`, say "sigdot." To say `|=`, say "bartis."
|
||||
Which has an inevitable tendency to turn into "barts" - a sin
|
||||
to be encouraged. In any language actually spoken by actual
|
||||
humans, laziness soon rounds off any rough edges.
|
||||
|
||||
So if we had to read the above decrement, omitting the spaces
|
||||
(which only a real purist would pronounce), we'd say: "luslus dec
|
||||
sigfas cen dec bartis a tis pat sigbar soq dec soq ketcab pat wutgal
|
||||
tis pel zero a per tislus b tis pat barhep wutcol tis pel a lus pel
|
||||
b per per b buc pel b lus pel b per per." The authorities would
|
||||
then arrive, and drag us out in a big net. Definitely don't do
|
||||
this at the airport.
|
||||
|
||||
Geeks being solitary by nature, opportunities for reading code
|
||||
aloud are limited. But studies by actual scientists have shown
|
||||
that even when we read silently, we activate the motor cortex
|
||||
that controls our vocal cords. Even if we never speak these
|
||||
squiggles, they're easier to _think_ if bound to simple sounds.
|
||||
|
||||
(And don't worry if you can't get yourself to say "lus" instead
|
||||
of "plus" for `+`, or "tar" instead of "star" for `*` - I have
|
||||
this problem myself. It's much easier to replace "underscore"
|
||||
with "cab" or "ampersand" with "pam.")
|
||||
|
||||
Hoon has almost 90 digraphic runes. They are easier to organize
|
||||
in your head, though, because the choice of glyph is not random.
|
||||
The second glyph in a rune means little or nothing, but the first
|
||||
defines a rough semantic category. These categories are:
|
||||
|
||||
| bar gates (ie, functions) (ie, one-method cores)
|
||||
? wut conditionals, booleans, tests
|
||||
: col tuples
|
||||
. dot nock operators
|
||||
$ buc factory macros (ie, type definitions)
|
||||
^ ket type conversions
|
||||
= tis compositions
|
||||
% cen invocations
|
||||
& pam gears (ie, objects) (ie, multi-method cores)
|
||||
~ sig hints
|
||||
; sem miscellaneous macros
|
||||
! zap special operations
|
||||
|
||||
Each rune has _[not]_ its own doc file in the `rune/190` directory. The
|
||||
name of the file is the name of the rune, minus the vowels.
|
||||
Thus, `|=` or "bartis" is _[not]_ defined in `rune/190/brts.txt`.
|
||||
|
||||
Opening this file, we see:
|
||||
|
||||
%brts |= "bartis"
|
||||
|
||||
define:
|
||||
[%brts p=gene q=gene]
|
||||
|
||||
expand:
|
||||
[%brts *] [%brcb p.gen (~(put by *(map term foot)) %% [%ash q.gen])]
|
||||
|
||||
There should be some actual discussion, but there isn't. Still,
|
||||
`brts.txt` is quite complete as a definition of `|=`. How? We
|
||||
need to step back a little.
|
||||
|
||||
When the Hoon parser parses a source file, it generates a noun
|
||||
called a `gene`. If you know what an AST is, a gene is an AST node.
|
||||
If you don't, don't worry about it.
|
||||
|
||||
Search the current kernel for `++ gene` - note double space.
|
||||
This code is both the type declaration for type `gene`, and
|
||||
a function that maps an untyped noun to a typed gene. In it
|
||||
you'll see the above definition,
|
||||
|
||||
[%brts p=gene q=gene]
|
||||
|
||||
Ie, one kind of gene is a triple whose head is the constant
|
||||
`%brts`, and whose tail is a pair of genes, `p` and `q`.
|
||||
|
||||
We also see the semantics of this rune: it expands to
|
||||
|
||||
[%brcb p.gen (~(put by *(map term foot)) %% [%ash q.gen])]
|
||||
|
||||
ie, `|=` is a built-in macro. But back to syntax.
|
||||
|
||||
What is `%brts`? The atom also known as `1937011298` or
|
||||
`0x73747262`. Simply a string mapped to an unsigned integer, LSB
|
||||
first. It's easy to see why the vowels got lost - `%bartis` is
|
||||
`126896762413410` or `0x736974726162`. On a 32-bit CPU with
|
||||
31-bit direct atoms, `%brts` is direct and `%bartis` indirect
|
||||
(not that the programmer can tell the difference). But you still
|
||||
say "bartis."
|
||||
|
||||
For instance, in the decrement above, we have
|
||||
|
||||
|= a=@
|
||||
~| 'dec'
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
In this `%brts`, `p` is
|
||||
|
||||
a=@
|
||||
|
||||
and `q` is
|
||||
|
||||
~| 'dec'
|
||||
^- @
|
||||
?< =(0 a)
|
||||
=+ b=@
|
||||
|-
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
We are starting to see the principles of Hoon syntax. Let's make
|
||||
them clear.
|
||||
|
||||
First, for any rune, the Hoon parser has two kinds of syntax:
|
||||
normal and custom. Most runes, such as `|=`, have only normal
|
||||
syntax without custom syntax. Almost all runes with custom
|
||||
syntax also have normal. Custom can mean anything; normal
|
||||
is rigid and uniform.
|
||||
|
||||
All programming languages, but especially functional ones, face
|
||||
two difficult syntactic problems. One is controlling the large
|
||||
numbers of terminators that appear in any deeply nested tree
|
||||
structure - Lisp is infamous for its piles of right parens.
|
||||
These are not a serious usability problem, except inasmuch as you
|
||||
consider ugly a usability problem (which I do). Two, a more
|
||||
serious concern, is keeping complex routines from flowing off the
|
||||
right margin as tab depth increases.
|
||||
|
||||
A glance at the more complex organs of the Hoon kernel reveals
|
||||
that Hoon is relatively untroubled by either of these woes. But
|
||||
why? One dubious panacea for the terminator problem is the use
|
||||
of significant whitespace. Whitespace in Hoon is not
|
||||
significant. (To be exact, the presence or absence of whitespace
|
||||
matters, but the quantity never does.)
|
||||
|
||||
The answer is that the normal syntax for every rune has two
|
||||
forms: "wide" and "tall." As a functional language, Hoon does
|
||||
not distinguish between statements and expressions, but normal
|
||||
wide syntax is expression-like and tall is statement-like.
|
||||
|
||||
For instance, in our example above,
|
||||
|
||||
?: =(a +(b))
|
||||
b
|
||||
$(b +(b))
|
||||
|
||||
is a tall normal form. The equivalent wide form is
|
||||
|
||||
?:(=(a +(b)) b $(b +(b)))
|
||||
|
||||
It's usually best to use the wide form if your gene fits on the
|
||||
line, but this is obviously an aesthetic choice. If your gene
|
||||
does not fit your margin (which should always be 80 columns),
|
||||
you have no choice but to go tall. For reasons that should be
|
||||
obvious, a tall gene can contain wide subgenes, but a wide gene
|
||||
cannot contain tall subgenes - just as, in procedural languages,
|
||||
a statement can contain expressions but not vice versa.
|
||||
|
||||
In the wide normal form, the rune is followed immediately (no
|
||||
whitespace) by a left paren ("pel"), then the subgenes with a
|
||||
single space between them, then a right paren ("per") as
|
||||
terminator. If the rune was inside the parens rather than a
|
||||
prefix, this would be the Lisp syntax.
|
||||
|
||||
In the tall normal form, any quantity of whitespace follows the
|
||||
rune, and separates the subgenes from each other. Where is the
|
||||
terminator? There is no terminator - in most cases.
|
||||
|
||||
Consider the `?:` rune, "wutcol," `%wtcl`. This is
|
||||
|
||||
[%wtcl p=gene q=gene r=gene]
|
||||
|
||||
Why should we need a terminator? We know `%wtcl`, whose
|
||||
semantics are if-then-else, has three subgenes. When the parser
|
||||
sees `?:` followed by space, it simply parses the next three
|
||||
genes and fills the rune with them.
|
||||
|
||||
This only works in runes with fixed tuple structure, which
|
||||
fortunately is most of them. A counterexample is `:*`, ie,
|
||||
|
||||
[%cltr p=(list gene)]
|
||||
|
||||
which is of variable length and needs a terminator. But we
|
||||
have no dangling parens, but an attractive tall closure:
|
||||
|
||||
:* %foo
|
||||
%bar
|
||||
%baz
|
||||
%moo
|
||||
==
|
||||
|
||||
whose equivalent wide normal is
|
||||
|
||||
:*(%foo %bar %baz %moo)
|
||||
|
||||
which no one would ever write, preferring the custom
|
||||
|
||||
[%foo %bar %baz %moo]
|
||||
|
||||
This leaves only one question: indentation. Since space is not
|
||||
significant (even linebreaks are irrelevant - the newline is just
|
||||
another space), the use of whitespace in tall forms is purely a
|
||||
matter of style. Style is very important, however!
|
||||
|
||||
The first law of Hoon indentation style is that all tall
|
||||
indentation is in two-space increments. (Tabs are illegal. If
|
||||
you pollute a Hoon file with ASCII 9, not only will it not parse,
|
||||
but thugs in ski masks will kick down your door and shoot you.
|
||||
You laugh! Try it!) Single spaces are for wide only.
|
||||
|
||||
The second law of Hoon indentation is that everything in the
|
||||
kernel is good indentation style. Or at least if it's not, it
|
||||
needs changed. The kernel shall be lapidary, noble, ideal and
|
||||
above all suspicion - a Doric column, a Tlingit totem pole,
|
||||
an Egyptian obelisk.
|
||||
|
||||
Tallness matters. The third law of Hoon indentation is that
|
||||
large genes should flow _down_ and not _across_ - like the
|
||||
decrement example above. The right margin is a precious resource
|
||||
not to be wasted. It's this law, when properly applied, that
|
||||
makes casual readers wonder if Hoon is a functional language at
|
||||
all. It doesn't have a program counter, but it looks like it
|
||||
does - at least when written right.
|
||||
|
||||
In list-structured runes, like the `:*` above, there is no choice
|
||||
but to lose right margin. Fortunately, most runes are tuples,
|
||||
and most have limited "fanout" - 1, 2, 3 or at most 4.
|
||||
|
||||
Both of our above examples - `|=` and `?:` - use "backstep"
|
||||
indentation which takes advantage of this tuple structure. For
|
||||
instance, `|=` has two subgenes, `p` and `q.` We put `p` on the
|
||||
same line as `|=`, set off by two spaces, losing 4 characters of
|
||||
margin. We put `q` _directly below_, losing no margin at all.
|
||||
|
||||
It so happens that in almost every actual case of `|=`, `p` (the
|
||||
function's argument) is relatively light, whereas `q` (the
|
||||
function's body) will be much heavier. Thus, with this pattern of
|
||||
indentation, we lose no margin and our code flows _down_.
|
||||
|
||||
We see this even more in `?:`, where the conditional test (which
|
||||
is much less likely to be heavy) is first and farthest right,
|
||||
followed by the "then" case indented two spaces, followed by the
|
||||
"else" case at the same indent as the rune.
|
||||
|
||||
Suppose your "else" is relatively light, and your "then" is
|
||||
heavy? You may prefer the `?.` rune, Hoon's "unless," which puts
|
||||
the else before the then. Or not. And in both `?:` and `?.`,
|
||||
the test (which of course can be arbitrarily heavy) is first.
|
||||
It is not necessary for your code to _always_ flow down and not
|
||||
across - just _mostly_.
|
||||
|
||||
The conventional principle which backstep indentation sacrifices,
|
||||
of course, is the idea that absolute indentation depth should
|
||||
correspond to tree depth, loop depth, or some other metric. Hoon
|
||||
is so deeply nested that if tab depth matched tree depth, your
|
||||
margins on anything interesting would be in the next cube to your
|
||||
right. There is perhaps a case for indenting loops, but we don't
|
||||
find we miss this cue at all.
|
||||
|
||||
The paucity of terminators also eliminates a lot of redundancy in
|
||||
the parser, which can result in relatively exciting syntax
|
||||
errors. Our experience is that this is seldom a big problem,
|
||||
because there are terminated tall forms and the cascade stops
|
||||
with them. It is often a small problem, however.
|
||||
8
doc/rune/old/barbon.txt
Normal file
8
doc/rune/old/barbon.txt
Normal file
@ -0,0 +1,8 @@
|
||||
|= %brbn "barbon"
|
||||
|
||||
gene:
|
||||
[%brbn p=*gene q=*gene]
|
||||
|
||||
ap open:
|
||||
[%pmbn p.gen [[%% [& q.gen]] ~ ~]]
|
||||
--
|
||||
14
doc/rune/old/barcas.txt
Normal file
14
doc/rune/old/barcas.txt
Normal file
@ -0,0 +1,14 @@
|
||||
|? %brcs "barcas"
|
||||
|
||||
gene:
|
||||
[%brcs p=*(list gene)]
|
||||
|
||||
ap open:
|
||||
?~ p.gen
|
||||
[%zpzp ~]
|
||||
[%brbn [%ktdp [%tmbn %noun] i.p.gen] [%cstr [~ 4] p.gen]]
|
||||
|
||||
meta:
|
||||
?~ p.gen
|
||||
!$(!!)
|
||||
!$(|=(^-(* {i.p.gen}) ?*(.4 {p.gen})))
|
||||
10
doc/rune/old/bardap.txt
Normal file
10
doc/rune/old/bardap.txt
Normal file
@ -0,0 +1,10 @@
|
||||
|- %brdp "bardap"
|
||||
|
||||
gene:
|
||||
[%brdp p=*gene]
|
||||
|
||||
ap open:
|
||||
[%bnld [%brdg p.gen] %%]
|
||||
|
||||
meta:
|
||||
=>(|:({p.gen}) $)
|
||||
7
doc/rune/old/bardeg.txt
Normal file
7
doc/rune/old/bardeg.txt
Normal file
@ -0,0 +1,7 @@
|
||||
|: %brdg "bardig"
|
||||
|
||||
gene:
|
||||
[%brdg p=*gene]
|
||||
|
||||
ap open:
|
||||
[%pmdg [[%% [& p.gen]] ~ ~]]
|
||||
7
doc/rune/old/bardot.txt
Normal file
7
doc/rune/old/bardot.txt
Normal file
@ -0,0 +1,7 @@
|
||||
|. %brdt "bardot"
|
||||
|
||||
gene:
|
||||
[%brdt p=*gene q=*gene]
|
||||
|
||||
ap open:
|
||||
[%pmdt p.gen [[%% [& q.gen]] ~ ~]]
|
||||
8
doc/rune/old/bartar.txt
Normal file
8
doc/rune/old/bartar.txt
Normal file
@ -0,0 +1,8 @@
|
||||
|* %brtr "bartar"
|
||||
|
||||
gene:
|
||||
[%brtr p=*gene q=*gene]
|
||||
|
||||
ap open:
|
||||
[%pmtr p.gen [[%% [& q.gen]] ~ ~]]
|
||||
--
|
||||
10
doc/rune/old/bondap.txt
Normal file
10
doc/rune/old/bondap.txt
Normal file
@ -0,0 +1,10 @@
|
||||
=- %bndp "bondap"
|
||||
|
||||
gene:
|
||||
[%bndp p=*gene q=*gene]
|
||||
|
||||
open:
|
||||
[%bnpd q.gen p.gen]
|
||||
|
||||
soft:
|
||||
=+({q.gen} {p.gen})
|
||||
10
doc/rune/old/bondel.txt
Normal file
10
doc/rune/old/bondel.txt
Normal file
@ -0,0 +1,10 @@
|
||||
=< %bndl "bondel"
|
||||
|
||||
gene:
|
||||
[%bndl p=*gene q=*gene]
|
||||
|
||||
open:
|
||||
[%bnld q.gen p.gen]
|
||||
|
||||
soft:
|
||||
=>({q.gen} {p.gen})
|
||||
4
doc/rune/old/bonled.txt
Normal file
4
doc/rune/old/bonled.txt
Normal file
@ -0,0 +1,4 @@
|
||||
=> %bnld "bonled"
|
||||
|
||||
gene:
|
||||
[%bnld p=*gene q=*gene]
|
||||
4
doc/rune/old/bonpad.txt
Normal file
4
doc/rune/old/bonpad.txt
Normal file
@ -0,0 +1,4 @@
|
||||
=+ %bnpd "bonpad"
|
||||
|
||||
gene:
|
||||
[%bnpd p=*gene q=*gene]
|
||||
4
doc/rune/old/casbar.txt
Normal file
4
doc/rune/old/casbar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?| %csbr "casbar"
|
||||
|
||||
gene:
|
||||
[%csbr p=*(list gene)]
|
||||
4
doc/rune/old/casbon.txt
Normal file
4
doc/rune/old/casbon.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?= %csbn "casbon"
|
||||
|
||||
gene:
|
||||
[%csbn p=*gene q=*gene]
|
||||
4
doc/rune/old/casdap.txt
Normal file
4
doc/rune/old/casdap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?- %csdp "casdap"
|
||||
|
||||
gene:
|
||||
[%csdp p=*gene q=*(list &[p=*gene q=*gene])] :: ?- casdap
|
||||
4
doc/rune/old/casdeg.txt
Normal file
4
doc/rune/old/casdeg.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?: %csdg "casdeg"
|
||||
|
||||
gene:
|
||||
[%csdg p=*gene q=*gene r=*gene]
|
||||
4
doc/rune/old/casdel.txt
Normal file
4
doc/rune/old/casdel.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?< %csdl "casdel"
|
||||
|
||||
gene:
|
||||
[%csdl p=*gene q=*gene]
|
||||
4
doc/rune/old/casdot.txt
Normal file
4
doc/rune/old/casdot.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?. %csdt "casdot"
|
||||
|
||||
gene:
|
||||
[%csdt p=*gene q=*gene r=*gene]
|
||||
4
doc/rune/old/casled.txt
Normal file
4
doc/rune/old/casled.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?> %csld "casled"
|
||||
|
||||
gene:
|
||||
[%csld p=*gene q=*gene]
|
||||
4
doc/rune/old/caspam.txt
Normal file
4
doc/rune/old/caspam.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?& %cspm "caspam"
|
||||
|
||||
gene:
|
||||
[%cspm p=*(list gene)]
|
||||
4
doc/rune/old/cassig.txt
Normal file
4
doc/rune/old/cassig.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?~ %cssg "cassig"
|
||||
|
||||
gene:
|
||||
[%cssg p=*gene q=*gene r=*gene]
|
||||
4
doc/rune/old/castar.txt
Normal file
4
doc/rune/old/castar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?* %cstr "castar"
|
||||
|
||||
gene:
|
||||
[%cstr p=*gene q=*(list gene)]
|
||||
4
doc/rune/old/caszap.txt
Normal file
4
doc/rune/old/caszap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
?! %cszp "caszap"
|
||||
|
||||
gene:
|
||||
[%cszp p=*gene]
|
||||
4
doc/rune/old/degdap.txt
Normal file
4
doc/rune/old/degdap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
:- %dgdp "degdap"
|
||||
|
||||
gene:
|
||||
[%dgdp p=*gene q=*gene]
|
||||
4
doc/rune/old/degket.txt
Normal file
4
doc/rune/old/degket.txt
Normal file
@ -0,0 +1,4 @@
|
||||
:^ %dgkt "degket"
|
||||
|
||||
gene:
|
||||
[%dgkt p=*gene q=*gene r=*gene s=*gene]
|
||||
4
doc/rune/old/degpad.txt
Normal file
4
doc/rune/old/degpad.txt
Normal file
@ -0,0 +1,4 @@
|
||||
:+ %dgpd "degpad"
|
||||
|
||||
gene:
|
||||
[%dgpd p=*gene q=*gene r=*gene]
|
||||
4
doc/rune/old/degsig.txt
Normal file
4
doc/rune/old/degsig.txt
Normal file
@ -0,0 +1,4 @@
|
||||
:` %dgsg "degsig"
|
||||
|
||||
gene:
|
||||
[%dgsg p=*(list gene)]
|
||||
4
doc/rune/old/degtar.txt
Normal file
4
doc/rune/old/degtar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
:* %dgtr "degtar"
|
||||
|
||||
gene:
|
||||
[%dgtr p=*(list gene)]
|
||||
4
doc/rune/old/dotbon.txt
Normal file
4
doc/rune/old/dotbon.txt
Normal file
@ -0,0 +1,4 @@
|
||||
.= %dtbn "dotbon"
|
||||
|
||||
gene:
|
||||
[%dtbn p=*gene q=*gene]
|
||||
4
doc/rune/old/dotket.txt
Normal file
4
doc/rune/old/dotket.txt
Normal file
@ -0,0 +1,4 @@
|
||||
.^ %dtkt "dotket"
|
||||
|
||||
gene:
|
||||
[%dtkt p=*gene]
|
||||
1
doc/rune/old/dotsig.txt
Normal file
1
doc/rune/old/dotsig.txt
Normal file
@ -0,0 +1 @@
|
||||
.~ %dtsg "dotsig"
|
||||
4
doc/rune/old/dottar.txt
Normal file
4
doc/rune/old/dottar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
.* %dttr "dottar"
|
||||
|
||||
gene:
|
||||
[%dttr p=*gene q=*gene]
|
||||
4
doc/rune/old/ketbon.txt
Normal file
4
doc/rune/old/ketbon.txt
Normal file
@ -0,0 +1,4 @@
|
||||
^= %ktbn "ketbon"
|
||||
|
||||
gene:
|
||||
[%ktbn p=*term q=*gene]
|
||||
4
doc/rune/old/ketdap.txt
Normal file
4
doc/rune/old/ketdap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
^- %ktdp "ketdap"
|
||||
|
||||
gene:
|
||||
[%ktdp p=*gene q=*gene]
|
||||
4
doc/rune/old/ketpad.txt
Normal file
4
doc/rune/old/ketpad.txt
Normal file
@ -0,0 +1,4 @@
|
||||
^+ %ktpd "ketpad"
|
||||
|
||||
gene:
|
||||
[%ktpd p=*gene q=*gene]
|
||||
4
doc/rune/old/ketsig.txt
Normal file
4
doc/rune/old/ketsig.txt
Normal file
@ -0,0 +1,4 @@
|
||||
^~ %ktsg "ketsig"
|
||||
|
||||
gene:
|
||||
[%ktsg p=*gene]
|
||||
4
doc/rune/old/mitbar.txt
Normal file
4
doc/rune/old/mitbar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%| %mtbr "mitbar"
|
||||
|
||||
gene:
|
||||
[%mtbr p=*twig q=*gene r=*(list &[p=*gene q=*gene])]
|
||||
4
doc/rune/old/mitbon.txt
Normal file
4
doc/rune/old/mitbon.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%= %mtbn "mitbon"
|
||||
|
||||
gene:
|
||||
[%mtbn p=*twig q=*(list &[p=*gene q=*gene])]
|
||||
4
doc/rune/old/mitdap.txt
Normal file
4
doc/rune/old/mitdap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%- "mitdap" %mtdp
|
||||
|
||||
gene:
|
||||
[%mtdp p=*gene q=*(list gene)]
|
||||
4
doc/rune/old/mitdeg.txt
Normal file
4
doc/rune/old/mitdeg.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%: %mtdg "mitdeg"
|
||||
|
||||
gene:
|
||||
[%mtdt p=*gene q=*gene]
|
||||
4
doc/rune/old/mitdot.txt
Normal file
4
doc/rune/old/mitdot.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%. %mtdt "mitdot"
|
||||
|
||||
gene:
|
||||
[%mtdt p=*gene q=*gene]
|
||||
4
doc/rune/old/mitket.txt
Normal file
4
doc/rune/old/mitket.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%^ %mtkt "mitket"
|
||||
|
||||
gene:
|
||||
[%mtkt p=*gene q=*gene r=*gene s=*gene]
|
||||
4
doc/rune/old/mitpad.txt
Normal file
4
doc/rune/old/mitpad.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%+ %mtpd "mitpad"
|
||||
|
||||
gene:
|
||||
[%mtpd p=*gene q=*gene r=*gene]
|
||||
4
doc/rune/old/mitsig.txt
Normal file
4
doc/rune/old/mitsig.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%~ %mtsg "mitsig"
|
||||
|
||||
gene:
|
||||
[%mtsg p=*twig q=*gene r=*gene]
|
||||
4
doc/rune/old/mittar.txt
Normal file
4
doc/rune/old/mittar.txt
Normal file
@ -0,0 +1,4 @@
|
||||
%* %mttr "mittar"
|
||||
|
||||
gene:
|
||||
[%mttr p=*gene]
|
||||
7
doc/rune/old/pambon.txt
Normal file
7
doc/rune/old/pambon.txt
Normal file
@ -0,0 +1,7 @@
|
||||
&= %pmbn "pambon"
|
||||
|
||||
gene:
|
||||
[%pmtr p=*gene q=*(map term foot)]
|
||||
|
||||
ap open:
|
||||
[%bnpd p.gen [%pmzp %gold q.gen]]
|
||||
7
doc/rune/old/pamdap.txt
Normal file
7
doc/rune/old/pamdap.txt
Normal file
@ -0,0 +1,7 @@
|
||||
&- %pmdp "pamdap"
|
||||
|
||||
gene:
|
||||
[%pmdp p=*gene q=*(map term foot)]
|
||||
|
||||
ap open:
|
||||
[%bnld [%pmdg q.gen] p.gen]
|
||||
7
doc/rune/old/pamdeg.txt
Normal file
7
doc/rune/old/pamdeg.txt
Normal file
@ -0,0 +1,7 @@
|
||||
&: %pmdg "pamdeg"
|
||||
|
||||
gene:
|
||||
[%pmdg p=*(map term foot)]
|
||||
|
||||
ap open:
|
||||
[%pmzp %lead p.gen]
|
||||
7
doc/rune/old/pamdot.txt
Normal file
7
doc/rune/old/pamdot.txt
Normal file
@ -0,0 +1,7 @@
|
||||
&. %pmdt "pamdot"
|
||||
|
||||
gene:
|
||||
[%pmdt p=*gene q=*(map term foot)]
|
||||
|
||||
ap open:
|
||||
[%bnpd p.gen [%pmzp %zinc q.gen]]
|
||||
7
doc/rune/old/pamtar.txt
Normal file
7
doc/rune/old/pamtar.txt
Normal file
@ -0,0 +1,7 @@
|
||||
&* %pmtr "pamtar"
|
||||
|
||||
gene:
|
||||
[%pmtr p=*gene q=*(map term foot)]
|
||||
|
||||
ap open:
|
||||
[%bnpd p.gen [%pmzp %wood q.gen]]
|
||||
4
doc/rune/old/pamzap.txt
Normal file
4
doc/rune/old/pamzap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
&= %pmzp "pamzap"
|
||||
|
||||
gene:
|
||||
[%pmbn p=*gene q=*(map term foot)]
|
||||
7
doc/rune/old/sigbar.txt
Normal file
7
doc/rune/old/sigbar.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~| %sgbr "sigbar"
|
||||
|
||||
gene:
|
||||
[%sgbr p=*gene q=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld [%bean p.gen] q.gen]
|
||||
7
doc/rune/old/sigbon.txt
Normal file
7
doc/rune/old/sigbon.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~= %sgbn "sigbon"
|
||||
|
||||
gene:
|
||||
[%sgbn p=*gene q=*gene] :: ~= sigbon
|
||||
|
||||
ap open:
|
||||
[%sgld [%germ p.gen] q.gen]
|
||||
7
doc/rune/old/sigdap.txt
Normal file
7
doc/rune/old/sigdap.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~- %sgdp "sigdap"
|
||||
|
||||
gene:
|
||||
[%sgdp p=@ q=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld [%sole %dtsg p.gen] q.gen]
|
||||
7
doc/rune/old/sigdax.txt
Normal file
7
doc/rune/old/sigdax.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~^ %sgdx "sigdax"
|
||||
|
||||
gene:
|
||||
[%sgdx p=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld %ping p.gen]
|
||||
7
doc/rune/old/sigdeg.txt
Normal file
7
doc/rune/old/sigdeg.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~: %sgdg "sigdeg"
|
||||
|
||||
gene:
|
||||
[%sgdg p=[p=@ q=@] q=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld [%bank %dtsg p.gen] q.gen]
|
||||
7
doc/rune/old/sigdel.txt
Normal file
7
doc/rune/old/sigdel.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~< %sgdl "sigdel"
|
||||
|
||||
gene:
|
||||
[%sgdl p=*term q=*gene r=*gene]
|
||||
|
||||
ap open:
|
||||
[%bndl [%sgld p.gen [~ 1]] q.gen]
|
||||
7
doc/rune/old/sigket.txt
Normal file
7
doc/rune/old/sigket.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~^ %sgkt "sigket"
|
||||
|
||||
gene:
|
||||
[%sgkt p=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld %keep p.gen]
|
||||
4
doc/rune/old/sigled.txt
Normal file
4
doc/rune/old/sigled.txt
Normal file
@ -0,0 +1,4 @@
|
||||
~> %sgld "sigled"
|
||||
|
||||
gene:
|
||||
[%sgld p=*term q=*gene r=*gene] :: ~> sigled
|
||||
17
doc/rune/old/sigmit.txt
Normal file
17
doc/rune/old/sigmit.txt
Normal file
@ -0,0 +1,17 @@
|
||||
~% %sgmt "sigmit"
|
||||
|
||||
gene:
|
||||
[%sgmt p=*seal q=*gene r=*(list &[p=*term q=*gene]) s=*gene]
|
||||
|
||||
ap open:
|
||||
:+ %sgdl
|
||||
:- %mine
|
||||
:+ [%dtsg p.gen]
|
||||
[%zpbn q.gen]
|
||||
:- %dgsg
|
||||
=+ nob=`*(list gene)`~
|
||||
|- ^- nob
|
||||
?~ r.gen
|
||||
nob
|
||||
[[[%dtsg p.i.r.gen] [%zpbn q.i.r.gen]] $(r.gen t.r.gen)]
|
||||
q.gen
|
||||
7
doc/rune/old/sigpad.txt
Normal file
7
doc/rune/old/sigpad.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~+ %sgpd "sigpad"
|
||||
|
||||
gene:
|
||||
[%sgpd p=@ q=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld [%memo %dtsg p.gen] q.gen]
|
||||
7
doc/rune/old/sigpam.txt
Normal file
7
doc/rune/old/sigpam.txt
Normal file
@ -0,0 +1,7 @@
|
||||
~& %sgpm "sigpam"
|
||||
|
||||
gene:
|
||||
[%sgpm p=*gene q=*gene]
|
||||
|
||||
ap open:
|
||||
[%sgld [%loaf p.gen] q.gen]
|
||||
4
doc/rune/old/tambon.txt
Normal file
4
doc/rune/old/tambon.txt
Normal file
@ -0,0 +1,4 @@
|
||||
;= %tmbn "tambon"
|
||||
|
||||
gene:
|
||||
[%tmbn p=*<%atom %noun %cell %flag %null>]
|
||||
4
doc/rune/old/tamdap.txt
Normal file
4
doc/rune/old/tamdap.txt
Normal file
@ -0,0 +1,4 @@
|
||||
;- %tmdp "tamdap"
|
||||
|
||||
gene:
|
||||
[%tmdp p=*gene]
|
||||
4
doc/rune/old/tampad.txt
Normal file
4
doc/rune/old/tampad.txt
Normal file
@ -0,0 +1,4 @@
|
||||
;+ %tmpd "tampad"
|
||||
|
||||
gene:
|
||||
[%tmpd p=*gene q=*gene]
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user