purr changed the topic of #elliottcable to: a _better_ cult || topics << 'gamedev'
Nuck has quit [Quit: Computer has gone to sleep.]
Nuck has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
jwilkins4 has joined #elliottcable
jwilkins4 has joined #elliottcable
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
Nuck has quit [Quit: Computer has gone to sleep.]
<eligrey>
did I post anything in here in the last 2 minutes?
<eligrey>
nvm
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
kaplan__ has quit [Ping timeout: 256 seconds]
eligrey has quit [Quit: Leaving]
Nuck has joined #elliottcable
kaplan has joined #elliottcable
Nuck has quit [Ping timeout: 256 seconds]
Nuck has joined #elliottcable
Nuck has quit [Quit: Computer has gone to sleep.]
kaplan has quit [Ping timeout: 256 seconds]
Nuck has joined #elliottcable
Nuck has quit [Quit: Computer has gone to sleep.]
glowcoil has quit [Ping timeout: 246 seconds]
glowcoil has joined #elliottcable
kaplan has joined #elliottcable
dskuza_ has joined #elliottcable
dskuza has quit [*.net *.split]
dskuza_ is now known as dskuza
jwilkins4 has quit [Read error: Connection reset by peer]
jwilkins5 has joined #elliottcable
alexgordon has joined #elliottcable
manveru has quit [Remote host closed the connection]
manveru has joined #elliottcable
<ELLIOTTCABLE>
ugh be my friend, guys
<ELLIOTTCABLE>
alexgordon: hi.
<ELLIOTTCABLE>
dskuza: hi!
<ELLIOTTCABLE>
glowcoil: talk in here so I can feel social
<kaplan>
hi ELLIOTTCABLE
<ELLIOTTCABLE>
or incomprehensibly or whoever you are right now
<dskuza>
ahoy there
<dskuza>
ELLIOTTCABLE:
<ELLIOTTCABLE>
kaplan: did I mention you should write a Paws to apply to college? :P
<kaplan>
ELLIOTTCABLE, no idea where to start
<ELLIOTTCABLE>
I can help with that! :D
<ELLIOTTCABLE>
I'm mostly joking. Paws is dead.
<dskuza>
Paws is dead, long live paws!
<ELLIOTTCABLE>
It'd be a waste of time, except literally as some code you're going to put on your GitHub and show off to say ‘I implemented a language!’
<ELLIOTTCABLE>
and then ignore forever, because it doesn't matter >:
<kaplan>
ELLIOTTCABLE, How about implementing a Swift compiler
<ELLIOTTCABLE>
still think that's pretty ambitious :P
<kaplan>
ELLIOTTCABLE, how about something like Lisp?
<incomprehensibly>
hi
<purr>
incomprehensibly: hi!
<incomprehensibly>
kaplan: lisps can be really tiny so that could be as ambitious or not as you want
<ELLIOTTCABLE>
incomprehensibly: already suggested that :P
<ELLIOTTCABLE>
‘Cool idea. Write a scheme first, then do it.’
<ELLIOTTCABLE>
incomprehensibly: did I tell you I'm doing the SICP over the next year?
<ELLIOTTCABLE>
like, ‘officially.’ with a big group and everything.
<ELLIOTTCABLE>
goddamn finally.
<ELLIOTTCABLE>
or were you the one who hates the siccough.
<kaplan>
ELLIOTTCABLE, rewrite SICP in clojure
<ELLIOTTCABLE>
kaplan: already done. kinda.
<kaplan>
ELLIOTTCABLE, nope
<incomprehensibly>
ELLIOTTCABLE: nice, do it
<ELLIOTTCABLE>
but that's not really appropriate; Clojure is bigger and more complex.
<ELLIOTTCABLE>
which vaguely defeats the point
<ELLIOTTCABLE>
like, the point of the SICP is that you learn an entire language in the first chapter, basically-ish, and move slowly towards having *implemented* that langauge, until at the end you're running your code on top of your own implementation of everything that you've learned. The entire book is like, recursive-learning.
<ELLIOTTCABLE>
apparently the last chapter is about implementing it on top of a register machine (so, compiling?), but idk *what* register machine, or … wtf. I asked the ‘instructor,’ (mentor?) and he didn't know.
<incomprehensibly>
like you probably make your own?
<incomprehensibly>
like the same way lua is built on a virtual register machine
<incomprehensibly>
which is just written in c
<ELLIOTTCABLE>
but *in what*? the SICP rather explicitly doesn't use anything other than a subset of MIT Scheme.
<ELLIOTTCABLE>
so are they going to have you implement a register machine on top of MIT Scheme, in Scheme, and then implement a scheme of your own on top of that register machine, and then have you write code targeting your Scheme-on-a-Scheme-VM-on-a-Scheme-compiler, which you then execute on a Scheme?
<ELLIOTTCABLE>
I mean, I guess that's rather appropriately recursive for a ‘Lisp community production’ :P
<ELLIOTTCABLE>
anyway. I'm excited, whatever the case.
<ELLIOTTCABLE>
omg micah watching the videos
<ELLIOTTCABLE>
Hal Abelson. Is an amazing teacher.
<ELLIOTTCABLE>
also, whenever they use the computer, I can't help but laugh out loud.
<ELLIOTTCABLE>
Edwin.
<ELLIOTTCABLE>
I'd never even *heard* of Edwin.
<ELLIOTTCABLE>
incomprehensibly: ↑
<incomprehensibly>
what
<ELLIOTTCABLE>
the MIT OpenCourseware videos for 6.001, the SICP class, are from like the goddamn '80s
<ELLIOTTCABLE>
and the teachers and students are wearing funny clothes; and yet I've still *never* had a more engaging class/teacher in my life than just watching that damn video
<ELLIOTTCABLE>
I've never heard of Hal Abelson before, but he's clearly a teaching legend.
<ELLIOTTCABLE>
I'm told the next video is Sussman, and they alternate
<ELLIOTTCABLE>
so that's exciting too
<ELLIOTTCABLE>
wish you were physically here, we could go to these meetings together. it'd rock-face.
<incomprehensibly>
haha nice
<incomprehensibly>
ya
<ELLIOTTCABLE>
or you could just watch the videos synchronously with me every time I go to the class. I could video-conference you into the discussion afterwards, or something. probably not necessary, you're smart. :P
<incomprehensibly>
:p
<ELLIOTTCABLE>
kaplan: but seriously.
<ELLIOTTCABLE>
kaplan: if you contribute to my language work in any way, I'm always happy to invest any amount of time into supporting you.
<kaplan>
ELLIOTTCABLE, I want to
<ELLIOTTCABLE>
kaplan: what do you mean by ‘I don't know where to start’, re: scheme or Paws?
<ELLIOTTCABLE>
talk me through what you already know, in your own words.
<kaplan>
ELLIOTTCABLE, I know basic programming
<kaplan>
That's all
<ELLIOTTCABLE>
first, at a high level (“what's the goal”), and second, at a lower level (*try* to answer the question “where will I start.”)
<ELLIOTTCABLE>
nonono
<ELLIOTTCABLE>
I mean, writing a Scheme. or a Paws.
<ELLIOTTCABLE>
not a compiler, a simple interpreter.
<kaplan>
Yeah, I could write a Paws interpreter
<ELLIOTTCABLE>
kaplan: incoming message.
Nuck has joined #elliottcable
<ELLIOTTCABLE>
kaplan: when you get that, dive right in.
<ELLIOTTCABLE>
it should arrive in ten days.
<ELLIOTTCABLE>
BUT BEFORE IT DOES, YOU NEED TO HAVE WRITTEN A PAWS OR SCHEME INTERPRETER :P
<ELLIOTTCABLE>
'cuz you should already know your shit. ;)
<kaplan>
ok
<kaplan>
ELLIOTTCABLE, Just tell me what to do
<kaplan>
and I'll push the code on github
<ELLIOTTCABLE>
kaplan: yes, Chicago
<ELLIOTTCABLE>
so, answer my questions above:
<ELLIOTTCABLE>
talk me through what you already know, in your own words.
<ELLIOTTCABLE>
first, at a high level (“what's the goal”), and second, at a lower level (*try* to answer the question “where will I start.”)
* ELLIOTTCABLE
pokes kaplan
<ELLIOTTCABLE>
I'm around, but not necessarily for long. Let me know if you want to talk later, though.
<ELLIOTTCABLE>
s/though/instead/
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<Cheery>
anyway one major reason I think for doing this would be making it easy to read and analyse computer programs by machine.
<ELLIOTTCABLE>
well, I mean, that's how static analyses work
<Cheery>
it's not been simple to implement. there's plenty of problems to solve. many I've already tackled somehow
<Cheery>
the first thing was representation.
<Cheery>
if you layout the code directly, as lisp, it's unreadable
<Cheery>
I defined a layout at first.
<Cheery>
basically had a function, which took in ast, produced graphical arrangement of boxes.
<Cheery>
boxes are fed to a renderer which draws them, it still works like this .
<Cheery>
after implementing some input, I realised that this kind of arrangement doesn't work.
<Cheery>
the input constantly keeps breaking the layout, distressing the user
<Cheery>
"oh my thing broke! I just typed a letter!"
<Cheery>
to fix this, I needed to define a schema. It solves several problems
<Cheery>
it lets my input figure out which modifications are 'safe'
<Cheery>
and allows nicer driving of the layout.. reduces it down to simple set of functions.
<Cheery>
also lets you to interpret the code and compile it, similar to how it's layouted.
<Cheery>
layout and compiling are similar functions.
<Cheery>
'projections'
<Cheery>
What the schema should be?
<Cheery>
I ended up to consider it from input perspective.
<ELLIOTTCABLE>
still \ confused.
<ELLIOTTCABLE>
still desperately confused*
<Cheery>
what are you confused about?
<Cheery>
is there something I fail to describe well?
<ELLIOTTCABLE>
“if you layout the code directly, as lisp, it's unreadable”
<ELLIOTTCABLE>
start there.
<ELLIOTTCABLE>
“ the input constantly keeps breaking the layout, distressing the user”
<ELLIOTTCABLE>
then that
<Cheery>
so consider my document model is something like lisp. Lisp is very near representation of the equivalent AST.
<Cheery>
very minimal too. basically just lists, strings. easy model to implement
<Cheery>
there are some things it isn't very good at.. It's because of homoiconicity
<Cheery>
the lists, strings, symbols, are actual data structures in the language of lisp
<Cheery>
but lisp is intrinsically difficult to read.
<Cheery>
It uses large amount of tokens to represent structure
<Cheery>
you could display it without those tokens, but it'd show no structure
<Cheery>
with those tokens it is a mixup of lists and symbols. I'm using that kind of layout when there's no another layout available.
<Cheery>
languages like python or C reduce the amount of structure tokens by using syntax
<Cheery>
but the order of symbols in their ast doesn't considerably change.
<Cheery>
(def name (arguments) body) -- equivalent to python's order of these symbols.
<Cheery>
I made layouting functions, from those lisp -style trees into boxes.
<Cheery>
box is a graphical unit stolen from TeX.
<ELLIOTTCABLE>
‘structure tokens’
<ELLIOTTCABLE>
the structure is still there; even if it's implicit.
<ELLIOTTCABLE>
if it's implicit, by definition, there's no syntax for it.
<Cheery>
yes.
<ELLIOTTCABLE>
if there's syntax for it, then it's not implicit, and there's just as many, er, ‘tokens?’
<ELLIOTTCABLE>
I'm still completely lost as to what you're trying to say. Like, I get you in the small; but I'm missing you in the large.
<ELLIOTTCABLE>
so, here's what I get so far:
<ELLIOTTCABLE>
1. graphical, instead of textual, code editor,
<ELLIOTTCABLE>
2. that assumes all languages are structured similarly,
<ELLIOTTCABLE>
3. … and what? you're having some sort of trouble with graphically laying out code?
<Cheery>
I have trouble with modelling a good keyboard input for producing and modifying code.
<Cheery>
that box model for layouting actually works like I intended
<Cheery>
I get stuff to look like python or C when I want to.
<ELLIOTTCABLE>
work with what people are familiar with. Put a caret in the box, and have it jump between boxes in the same fashion as it would if those boxes were a single document, laid out like normal code.
<ELLIOTTCABLE>
unless I misunderstand you.
<Cheery>
that's where I've started from. I noticed it's hard to grok operations in middle of the structure.
<Cheery>
so I made the caret to move in the text.
<Cheery>
it never leaves the text
<Cheery>
you select a structure by selecting the text it consists from
<Cheery>
but it's not a flat structure. It's still a tree structure.
<Cheery>
the tree structure must follow a schema, otherwise the layout fails and the structure 'explodes' back into lisp
<Cheery>
walking through the code in this manner is obviously easy.
<Cheery>
but modification needs some thought..
<Cheery>
there's certain operations that the user needs to carry through..
<Cheery>
he needs to be able to remove, and insert anywhere in the structure.
<Cheery>
and he needs to be able to construct new or mutate existing structures.
<Cheery>
We're getting to hard stuff here.
<Cheery>
removal is either simple or complex, depending how you're doing it.
<Cheery>
if you insist the removal must be an operation into single node, then it's simple. You find the nearest common parent of the selection carets.
<Cheery>
cut from that parent
<ELLIOTTCABLE>
‘scheme’
<ELLIOTTCABLE>
er, schema*
<ELLIOTTCABLE>
how do you mean ‘explodes’ back to lisp
<Cheery>
well consider you'd have a function written in something that is fed to python. It's been programmed to look like python.
<Cheery>
say you accidentally remove the symbol of the function definition entirely
<Cheery>
that means instead of (name arguments body), it's got only (arguments body)
<Cheery>
the layouter is unable to put that together
<Cheery>
it falls back to lisp-style representation of the code
<Cheery>
an 'explosion' occurs. the layout of the code changes and things fly unexpectedly.
<Cheery>
the user screams and presses undo
<Cheery>
if I have it implemented.. (I have)
<ELLIOTTCABLE>
back up again
<ELLIOTTCABLE>
“well consider you'd have a function written in something that is fed to python. It's been programmed to look like python.”
<ELLIOTTCABLE>
what does *any* of that mean
<ELLIOTTCABLE>
I'm obviously still not on the same page as you.
<ELLIOTTCABLE>
and ignoring that,
<ELLIOTTCABLE>
sounds to me like you don't have any problems that haven't been solved by every parser, well, ever.
<ELLIOTTCABLE>
“a function doesn't have (name arguments body), it's got only (arguments body)”
<ELLIOTTCABLE>
there. you have a problem. write code to know about that problem, and spit out an error.
<ELLIOTTCABLE>
if you're dead-set on letting the user *write* tree-structures that don't make sense in the language they're working in, then you can make it a warning instead of an error, and then add a sort of ‘ghost’ to the tree for the parts you know are missing.
<ELLIOTTCABLE>
but none of that can happen until your application knows How Python Works™, which is why I'm still confused about this whole thing:
<Cheery>
I did remove that 'feature', and instead made it easy to specify new structures prior using them
<ELLIOTTCABLE>
your whole project seems to assume that all programming languages look the same.
<ELLIOTTCABLE>
they really, really don't.
<ELLIOTTCABLE>
maybe if you're comparing JavaScript to C, or Ruby to Foundry, … but in the large, that's just not true …
<Cheery>
for that I've got modelines.
<Cheery>
holds the name of the 'schema' that's in use
<Cheery>
the schema describes the structures in the language
<Cheery>
also guides which layout function to use
<ELLIOTTCABLE>
so, a schema is a language parser.
<ELLIOTTCABLE>
and a layout function is a code beautifier / linter? ish.
<Cheery>
it drives parsing. but doesn't affect how they're stored.
<Cheery>
basically the layouter/compiler is using the schema file to recognize what each list means in the file
<ELLIOTTCABLE>
I think you'll need more than that. If you want a ‘native’ user-experience for Any Given Language, then people adding their language to your editor (writing an extension, or a plugin, or whatever you're providing for that) will need the flexibility to *also* mutate the storage format.
<ELLIOTTCABLE>
not necessarily in the large (away from the basics of ‘a list of textual strings’), but in the small.
<Cheery>
the schema imitates a structure of a context free grammar. also encodes the structure.
<Cheery>
a compiler writer gets lists to read from
<Cheery>
[name, [arguments...], [body...]]
<Cheery>
layouter gets the same
<ELLIOTTCABLE>
“compiler writer?”
<Cheery>
you compile into something from the storage.
<Cheery>
in case of python. there's an AST -module.
<Cheery>
it's a straightforward transformation.
<Cheery>
for C, you could produce the equivalent C source code
<ELLIOTTCABLE>
so, returning the document to source-code.
<Cheery>
yeah. but that's just because C compilers don't usually allow feeding in AST
<ELLIOTTCABLE>
is this completely transparent? if I type `function (){}`, will it ‘compile’ back to `function (){}`, or `function() {}`?