#racket

my parser is missing few layers, but it seems to get really nice shape

added in some operator precedence parsing, added some space sensitivity for prefixes/postfixes so I wouldn't need to parse dumb things.

s/dumb things/commas/

basically it's got two layers now

the first layer parses sentences, blocks, parentheses

it's got some protection for rampartly forgotten parenthesis.

um. rampart wrong word.

rampant?

rampage

oh rampant yeah.

second layer parses expressions: 5 + 2 * 3 parses like arithmetic usually parses

5 +2 * 3 parses as if + was a prefix

it avoids placing in commas in this manner

x [15] - a symbol and a list.

x[15] - indexing operation

between these two layers I should have some more parsers.

for different expressions for example.

also, should have pattern parsers.

for doing some cool assignments or such.

thinking about a name though.. it's eventually going to resemble some mix of python, coffeescript, and lisp maybe.

would like to add some support for custom syntax.

while at same time giving myself chance to implement primitives similar to those in python.

that is.. giving a chance, not necessarily implement them myself.

oh geez, x[15] and x [15] being different is going to be... a bit nasty. especially if the end-user doesn't expect it

how about x[ 15 ]

how about x [ 15 ]

Someone made called pyket recently, but all it makes me think of is a russian trying to say 'racket'.

if I stick in a unicode byte order marker into a commit, stealthily, will I cause someone endless hours of frustration as they attempt to locate it?

*made a lang called

TEttinger: the cue is x[ vs. x [

if they're tightly written, they're parsed in as single terminal

that's not much cue...

using the mechanism because it allows to avoid inserting comma everywhere.

and it's going to be mentioned in manuals if I like to work in the language.

also. if I mean call/indexing, I'm never inserting space there anyway.

maybe I get to name it if I list some of the requirements I have for it

the main requirement is that it should be fairly easy to change, if some things turn out to be sour.

but there shouldn't be excess syntax if it can be avoided. this invalidates lisp notation.

the parsing mechanism should be easy to plug into an IDE, perhaps allow interactive updates without having to do a full parse

if the grammar is extended, it should provide files for the IDE to function properly in presence of extra syntax.

It sounds like you're reinventing honu?

Not that that's a bad thing.

took inspiration, but it's not much reinventing.

factorial might look like this: http://pastebin.com/ATRE9REb

'return' is a bit tricky. Don't you need escape continuations for that?

got an interpreter I can use for this.

..which got a lisp syntax right now

I guess I'll apply a kind of 'terminals first' -parsing.

if x >= 10: would be if x >= 10 block when it arrives to statement parsing

if there's cues in place 'if' and a block

it would then recognize itself as if-clause and parse as such.

got the output from the current parsing.. thinking out a bit what I want out from it.

I sort of want rich, minimum hassle syntax with configurability.

guessing I'll implement equals -sign next. and maybe multiline syntax for parentheses.

mrmyers: pycket isn't a new lang, it's a different implementation of the runtime

samth: Ah, I got that and pyonR switched.

samth: So, bearing in mind that 'Because I could.' is an acceptable answer, why?

mrmyers: to investigate how well tracing jit compilers work for racket, especially for contracts