DrShoggoth has quit [Quit: Leaving]
e_dub has joined #opal
e_dub has quit [Ping timeout: 260 seconds]
e_dub has joined #opal
e_dub has quit [Ping timeout: 248 seconds]
e_dub has joined #opal
elia has joined #opal
meh` has joined #opal
e_dub has quit [Read error: Operation timed out]
adambeynon has joined #opal
adambeynon has quit [Read error: No route to host]
adambeynon has joined #opal
kludge` has quit [Ping timeout: 245 seconds]
kludge` has joined #opal
elia has quit [Ping timeout: 252 seconds]
elia has joined #opal
<meh`> adambeynon, yo
<adambeynon> hi meh`
<adambeynon> I got the email
<adambeynon> re parser and co
<meh`> thoughts?
<adambeynon> im keen to keep the lexer + parser part the same, or atleast based on mri lexer + parser stuff
<adambeynon> the codegen could definately do witha revamp
<adambeynon> with a*
<adambeynon> we need a better class system for that
<adambeynon> SymbolNode etc
<adambeynon> I dont like the process_foo() style
<meh`> adambeynon, the problem with keeping the current lexer + parser is that you are the only one that can get something done with it
<meh`> and having a parslet parser allows for easier sexp generation
<meh`> having a standard AST with classes and whatnot isn't really a good idea
<meh`> a sexp based processor is easier to do and maintain when it's done right
<meh`> aka not how it's done now
<adambeynon> meh`: not sure about that - the current lexer (lexer.rb) + parser (grammar.y) is very heavily based off the one in MRI
<adambeynon> the sexp stuff is good to keep
<adambeynon> but then we convert secps into classes when doing actual codegen
<adambeynon> meh`: like this:
<adambeynon> they have a dsl for the AST classes to say "this class handles this type of node/sexp"
<adambeynon> class SymbolNode < Node; handle :sym; def process; "#{target}"; end; end
<adambeynon> or something like that anyway
<adambeynon> so, basically the grammar.y still spits out sexps, but then our CodeGen class would just process them, but in a nicer way
<adambeynon> meh`: can parslet even parse ruby?
<meh`> adambeynon, yes
<adambeynon> you sure? looks like you would still need some internal context changing
<meh`> adambeynon, yes, I'm sure
elia has quit [Quit: (IRC Client: textualapp.com)]
elia has joined #opal
kludge` has quit [Ping timeout: 240 seconds]
kludge` has joined #opal
<adambeynon> meh`: how would you like to see the code generation handled?
meh` has quit [Ping timeout: 245 seconds]
meh` has joined #opal
<meh`> adambeynon, picture this
<meh`> adambeynon, we parse the Ruby code, get an AST, we have various Ruby optimization passes, then we convert that AST to a JavaScript AST
<meh`> then we pass over the possible JS optimization passes
<meh`> and then we emit the resulting source code
<meh`> my plan includes a Ruby and JavaScript parlset parser
<meh`> so we can analyze the inline JavaScript too and ensure it's proper
<meh`> adambeynon, also keep in mind you can extend Parslet parsers at runtime
<meh`> and this will give us superb tooling in the browser
<meh`> imagine what fkchang could do with that kind of tooling
<meh`> while right now it's just a pain in the ass to extract comments and source code and whatnot
<meh`> need source code for a method or a block? here you go, the Ruby AST attached as property to it
<meh`> the comment before a method or class can be attached to it as metadata
<meh`> and bam, godly introspection
<meh`> I think I'll work on it even if you don't want to merge it
<meh`> because it's just so cool thinking about it
<meh`> adambeynon, see it as the next generation of opal
<meh`> from source to source, to AST to AST
<adambeynon> meh`: very interesting indeed
<adambeynon> meh`: do you have an example of where parslet can be used to parse something as complex as ruby? It seems (to me) that it would be limited on that
<adambeynon> well, thats only the first part anyway
<adambeynon> the ast stuff could be attached in the current parser anyway
<meh`> adambeynon, just keep in mind Parslet is a PEG parser
<meh`> it can do what any other PEG parser can
<meh`> adambeynon, I know for sure someone made a Ruby parser with kpeg
<meh`> but I challenge you to find "ruby parser" without getting Ruby parser generators
<adambeynon> yeh.. googled that - didnt help much
<adambeynon> well
<adambeynon> the ast -> ast can be done before changes to the parser anyway
<meh`> yes
<meh`> let me work on the AST representation
<meh`> then you can kick in with the grammar -> ast thing
<adambeynon> so, to clarify, you are suggesting: source-code => sexp => ruby-ast => js-ast => javascript-code
<meh`> I'd skip the sexp part
<meh`> we have two choices
<meh`> 1) we use s-exps everywhere
<meh`> 2) we use AST nodes as Ruby classes
<meh`> and the process would be that, yes
<meh`> Ruby source -> AST -> optimization passes/analysys for Ruby -> JS AST emitter -> optimization passes/analysis for Javascript -> JS source emitter
<meh`> adambeynon, for example let's take a math block pragma
<meh`> right now you'd have to monkey patch the processor and make it even uglier
<meh`> with the design I propose it would just be an additional pass in the analysys and JS AST emitting
<meh`> this way we can easily plug new passes and features
<meh`> without complecting the existing infrastructure
<meh`> and this way we can also enable/disable passes at will
<meh`> or interrupt the generation at a certain pass
<meh`> right now we've been doing a fairly "dumb" compilation
<meh`> which isn't a bad thing, it's the fastest way to get something working and it isn't the most vital part in something like Opal
<meh`> but having a clear compilation process would allow more people to hack on it
<meh`> right now if you change one line in the compiler you tend to break the universe
<meh`> this design also allows for local passes, let's say you need a certain pragma in your project
<meh`> you just write the additional pass, register it in the compiler and you get your thing going
<meh`> right now you'd have to maintain your own fork of the compiler
elia has quit [Ping timeout: 252 seconds]
DrShoggoth has joined #opal
<adambeynon> meh`: agree with all that. but, it is fair to say that all those changes would take a lot of work. Im more than happy to help, but we are probably talking about a longer term target with this
<meh`> adambeynon, yeah, that's why I wanted to start with a parser I can understand :P
<adambeynon> lol
<adambeynon> be back at 9 .. bst ;)
adambeynon has quit [Quit: ["Textual IRC Client: www.textualapp.com"]]
e_dub has joined #opal
e_dub has quit [Quit: It's a hard knock life]
adambeynon has joined #opal
meh` has quit [Quit: I don't want to live on this planet anymore.]
hermeht has joined #opal
adambeynon has quit [Quit: Textual IRC Client: www.textualapp.com]
hermeht has quit [Ping timeout: 245 seconds]
DrShoggoth has quit [Ping timeout: 260 seconds]