Compiler internals
Locked
 
|
Hi list,
I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. Specifically, I want: aBlockClosure smalltalkSource "gives [ :bar | bar * 2 ] " smalltalkSource: '[ :foo | foo + 42 ]' " sets & recompiles the source" I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? aBlockClosure scope "some sort of dictionary that lets us access the bound variables" Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? I see that Compiler >> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks not compiled directly? The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. best, Siemen ---- Siemen Baader PhD Fellow Department of Computer Science Aarhus University Aabogade 34 -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
Herby Siemen Baader wrote: > Hi list, > > I am constructing smalltalk expressions and saving them into an object > using Blocks in a Domain Specific Language. Later, I want to revise > the content of these Blocks, so I'm trying to modify the compiler to > access and revise the smalltalk source of existing BlockClosure > objects. But I don't have enough of a big picture of the compiler > architecture -- the IR, AST and the Compiler-Interpreter packages etc. > > Specifically, I want: > > aBlockClosure > smalltalkSource "gives [ :bar | bar * 2 ] " > smalltalkSource: '[ :foo | foo + 42 ]' " sets & recompiles the source" > > I guess this also requires us to have access to the closed-over local > variables in the BlockClosure, right? Is this possible with the VM? > > aBlockClosure scope "some sort of dictionary t > bound variables" > > Could anyone explain the compiler's design for me and point out where > to look to make the specific modifications to solve my problem? > > Does BlockClosure hold runtime references to the local and instance > variables that are bound when it is evaluated? > > I see that Compiler >> compileExpression uses the DoIt class and adds > a new method to it to encapsulate the current expression in a block. > Isn't that a detour / why are blocks not compiled directly? > > The class Compiler is a good starting point. What do you think of > putting the high-level documentation and links to the relevant > background references into the Compiler class documentation text? I > could do that if somebody helps me to understand it first. > > best, > Siemen > > > ---- > > Siemen Baader > PhD Fellow > > Department of Computer Science > Aarhus University > Aabogade 34 > DK-8200 Aarhus N > > office: ADA 125 > email: [hidden email] <mailto:[hidden email] > phone: +45 60 65 70 79 > > > > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi Herby,
On 07 Apr 2014, at 15:07, Herby Vojčík <[hidden email]> wrote: > BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. Any pointers to how to do it, anyone? best, Siemen > > Herby > > Siemen Baader wrote: >> Hi list, >> >> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. >> >> Specifically, I want: >> >> aBlockClosure >> smalltalkSource "gives [ :bar | bar * 2 ] " >> smalltalkSource: '[ :foo | foo + 42 ]' " sets & recompiles the source" >> >> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >> >> aBlockClosure scope "some sort of dictionary t > hat lets us access the >> bound variables" >> >> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >> >> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >> >> I see that Compiler >> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks not compiled directly? >> >> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >> >> best, >> Siemen >> >> >> ---- >> >> Siemen Baader >> PhD Fellow >> >> Department of Computer Science >> Aarhus University >> Aabogade 34 >> DK-8200 Aarhus N >> >> office: ADA 125 >> email: [hidden email] <mailto:[hidden email] > .dk> >> phone: +45 60 65 70 79 >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email] <mailto:[hidden email]>. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Siemen Baader wrote: > Hi Herby, > > On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]> wrote: > >> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. > > I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. It is not. All methods and blocks are clear, just JS functions, nothing more. They add context themselves when run. > Any pointers to how to do it, anyone? > > best, > Siemen > >> Herby >> >> Siemen Baader wrote: >>> Hi list, >>> >>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don >>> >>> Specifically, I want: >>> >>> aBlockClosure >>> smalltalkSource "gives [ :bar | bar * 2 ] " >>> smalltalkSource: '[ :foo | foo + 42 ]' " sets& recompiles the source" >>> >>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >>> >>> aBlockClosure scope "some sort of dictionary t >> hat lets us access the >>> bound variables" >>> >>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >>> >>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >>> >>> I see that Compiler>> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks >>> >>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >>> >>> best, >>> Siemen >>> >>> >>> ---- >>> >>> Siemen Baader >>> PhD Fellow >>> >>> Department of Computer Science >>> Aarhus University >>> Aabogade 34 >>> DK-8200 Aarhus N >>> >>> office: ADA 125 >>> email: [hidden email]<mailto:[hidden email] >> .dk> >>> phone: +45 60 65 70 79 >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]<mailto:[hidden email]>. >>> For more options, visit https://groups.google.com/d/optout. >> -- >> You received this message because you are subscribed to >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure. A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.
2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:
Thanks! I will go digging some more, this is definitely helpful! -- Siemen
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi!
I wrote a blog post about the new compiler some time ago. It doesn't go too much into details but it may help anyway: http://nicolas-petton.fr/blog/amber-compiler.html Cheers, Nico Siemen Baader writes: > On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote: > >> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure. >> >> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png >> >> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes. > > Thanks! I will go digging some more, this is definitely helpful! > > -- Siemen > >> >> >> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>: >> >> Siemen Baader wrote: >> Hi Herby, >> >> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]> wrote: >> >> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. >> >> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. >> >> It is not. All methods and blocks are clear, just JS functions, nothing more. >> They add context themselves when run. >> >> >> Any pointers to how to do it, anyone? >> >> best, >> Siemen >> >> Herby >> >> Siemen Baader wrote: >> Hi list, >> >> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don >> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. >> >> Specifically, I want: >> >> aBlockClosure >> smalltalkSource "gives [ :bar | bar * 2 ] " >> smalltalkSource: '[ :foo | foo + 42 ]' " sets& recompiles the source" >> >> >> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >> >> aBlockClosure scope "some sort of dictionary t >> hat lets us access the >> bound variables" >> >> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >> >> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >> >> I see that Compiler>> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks >> not compiled directly? >> >> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >> >> best, >> Siemen >> >> >> ---- >> >> Siemen Baader >> PhD Fellow >> >> Department of Computer Science >> Aarhus University >> Aabogade 34 >> DK-8200 Aarhus N >> >> office: ADA 125 >> email: [hidden email]<mailto:[hidden email] >> .dk> >> phone: +45 60 65 70 79 >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]<mailto:[hidden email]>. >> For more options, visit https://groups.google.com/d/optout. >> -- >> You received this message because you are subscribed to >> the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. -- Nicolas Petton http://nicolas-petton.fr -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi Nicolas,
thanks - that looks very promising! I will have a look and see if I can make the modification I need. Would it be a good idea to put a link to this blog post into the Compiler class documentation? cheers, Siemen On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote: > Hi! > > I wrote a blog post about the new compiler some time ago. It doesn't go > too much into details but it may help anyway: > http://nicolas-petton.fr/blog/amber-compiler.html > > Cheers, > Nico > > > Siemen Baader writes: > >> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote: >> >>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure. >>> >>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png >>> >>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes. >> >> Thanks! I will go digging some more, this is definitely helpful! >> >> -- Siemen >> >>> >>> >>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>: >>> >>> Siemen Baader wrote: >>> Hi Herby, >>> >>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]> wrote: >>> >>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. >>> >>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. >>> >>> It is not. All methods and blocks are clear, just JS functions, nothing more. >>> They add context themselves when run. >>> >>> >>> Any pointers to how to do it, anyone? >>> >>> best, >>> Siemen >>> >>> Herby >>> >>> Siemen Baader wrote: >>> Hi list, >>> >>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don >>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. >>> >>> Specifically, I want: >>> >>> aBlockClosure >>> smalltalkSource "gives [ :bar | bar * 2 ] " >>> smalltalkSource: '[ :foo | foo + 42 ]' " sets& recompiles the source" >>> >>> >>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >>> >>> aBlockClosure scope "some sort of dictionary t >>> hat lets us access the >>> bound variables" >>> >>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >>> >>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >>> >>> I see that Compiler>> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks >>> not compiled directly? >>> >>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >>> >>> best, >>> Siemen >>> >>> >>> ---- >>> >>> Siemen Baader >>> PhD Fellow >>> >>> Department of Computer Science >>> Aarhus University >>> Aabogade 34 >>> DK-8200 Aarhus N >>> >>> office: ADA 125 >>> email: [hidden email]<mailto:[hidden email] >>> .dk> >>> phone: +45 60 65 70 79 >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]<mailto:[hidden email]>. >>> For more options, visit https://groups.google.com/d/optout. >>> -- >>> You received this message because you are subscribed to >>> the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/d/optout. > > > -- > Nicolas Petton > http://nicolas-petton.fr > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Siemen Baader writes: > Hi Nicolas, > > thanks - that looks very promising! I will have a look and see if I can make the modification I need. > > Would it be a good idea to put a link to this blog post into the > Compiler class documentation? Maybe an even better idea would be to make a documentation page out of it? Cheers, Nico > > cheers, > Siemen > > > On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote: > >> Hi! >> >> I wrote a blog post about the new compiler some time ago. It doesn't go >> too much into details but it may help anyway: >> http://nicolas-petton.fr/blog/amber-compiler.html >> >> Cheers, >> Nico >> >> >> Siemen Baader writes: >> >>> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote: >>> >>>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure. >>>> >>>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png >>>> >>>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes. >>> >>> Thanks! I will go digging some more, this is definitely helpful! >>> >>> -- Siemen >>> >>>> >>>> >>>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>: >>>> >>>> Siemen Baader wrote: >>>> Hi Herby, >>>> >>>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]> wrote: >>>> >>>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. >>>> >>>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. >>>> >>>> It is not. All methods and blocks are clear, just JS functions, nothing more. >>>> They add context themselves when run. >>>> >>>> >>>> Any pointers to how to do it, anyone? >>>> >>>> best, >>>> Siemen >>>> >>>> Herby >>>> >>>> Siemen Baader wrote: >>>> Hi list, >>>> >>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don >>>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. >>>> >>>> Specifically, I want: >>>> >>>> aBlockClosure >>>> smalltalkSource "gives [ :bar | bar * 2 ] " >>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets& recompiles the source" >>>> >>>> >>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >>>> >>>> aBlockClosure scope "some sort of dictionary t >>>> hat lets us access the >>>> bound variables" >>>> >>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >>>> >>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >>>> >>>> I see that Compiler>> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks >>>> not compiled directly? >>>> >>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >>>> >>>> best, >>>> Siemen >>>> >>>> >>>> ---- >>>> >>>> Siemen Baader >>>> PhD Fellow >>>> >>>> Department of Computer Science >>>> Aarhus University >>>> Aabogade 34 >>>> DK-8200 Aarhus N >>>> >>>> office: ADA 125 >>>> email: [hidden email]<mailto:[hidden email] >>>> .dk> >>>> phone: +45 60 65 70 79 >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]<mailto:[hidden email]>. >>>> For more options, visit https://groups.google.com/d/optout. >>>> -- >>>> You received this message because you are subscribed to >>>> the Google Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. -- Nicolas Petton http://nicolas-petton.fr -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
On 08 Apr 2014, at 14:51, Nicolas Petton <[hidden email]> wrote:
Yes, that is a good idea! I would like to do it once I get the things working - I guess this will be a good test case for the documentation as well ;) best, Siemen
-- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Siemen Baader writes: > On 08 Apr 2014, at 14:51, Nicolas Petton <[hidden email]> wrote: > >> > Yes, that is a good idea! I would like to do it once I get the things > working - I guess this will be a good test case for the documentation > as well ;) The new repo for the documentation is here: https://github.com/amber-smalltalk/amber-documentation Cheers, Nico > > best, > Siemen > >> >> Cheers, >> Nico >> >>> >>> cheers, >>> Siemen >>> >>> >>> On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote: >>> >>>> Hi! >>>> >>>> I wrote a blog post about the new compiler some time ago. It doesn't go >>>> too much into details but it may help anyway: >>>> http://nicolas-petton.fr/blog/amber-compiler.html >>>> >>>> Cheers, >>>> Nico >>>> >>>> >>>> Siemen Baader writes: >>>> >>>>> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote: >>>>> >>>>>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure. >>>>>> >>>>>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png >>>>>> >>>>>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes. >>>>> >>>>> Thanks! I will go digging some more, this is definitely helpful! >>>>> >>>>> -- Siemen >>>>> >>>>>> >>>>>> >>>>>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>: >>>>>> >>>>>> Siemen Baader wrote: >>>>>> Hi Herby, >>>>>> >>>>>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]> wrote: >>>>>> >>>>>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler. >>>>>> >>>>>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there. >>>>>> >>>>>> It is not. All methods and blocks are clear, just JS functions, nothing more. >>>>>> They add context themselves when run. >>>>>> >>>>>> >>>>>> Any pointers to how to do it, anyone? >>>>>> >>>>>> best, >>>>>> Siemen >>>>>> >>>>>> Herby >>>>>> >>>>>> Siemen Baader wrote: >>>>>> Hi list, >>>>>> >>>>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don >>>>>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc. >>>>>> >>>>>> Specifically, I want: >>>>>> >>>>>> aBlockClosure >>>>>> smalltalkSource "gives [ :bar | bar * 2 ] " >>>>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets& recompiles the source" >>>>>> >>>>>> >>>>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM? >>>>>> >>>>>> aBlockClosure scope "some sort of dictionary t >>>>>> hat lets us access the >>>>>> bound variables" >>>>>> >>>>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem? >>>>>> >>>>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated? >>>>>> >>>>>> I see that Compiler>> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks >>>>>> not compiled directly? >>>>>> >>>>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first. >>>>>> >>>>>> best, >>>>>> Siemen >>>>>> >>>>>> >>>>>> ---- >>>>>> >>>>>> Siemen Baader >>>>>> PhD Fellow >>>>>> >>>>>> Department of Computer Science >>>>>> Aarhus University >>>>>> Aabogade 34 >>>>>> DK-8200 Aarhus N >>>>>> >>>>>> office: ADA 125 >>>>>> email: [hidden email]<mailto:[hidden email] >>>>>> .dk> >>>>>> phone: +45 60 65 70 79 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]<mailto:[hidden email]>. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> -- >>>>>> You received this message because you are subscribed to >>>>>> the Google Groups "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> -- >>>> Nicolas Petton >>>> http://nicolas-petton.fr >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/d/optout. -- Nicolas Petton http://nicolas-petton.fr -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |