From: Bayley, A. <Ali...@ld...> - 2005-06-15 12:16:16
|
> From: Thiago Arrais [mailto:thi...@gm...] > > 1. write a parser in Java for a functional language and > integrate it with the plug-in we have to this point. This > parser should provide the execution engine (and UI > components) with the info needed to trace the execution back > and forth (to source code) > > 2. write a translator that gets a parser output and produces > executable code for the execution engine I was wondering if it would be a good idea to have GHC emit Core and use this as input to your execution engine, but then you wouldn't have the mapping from the debugger back to the source (Core is significantly de-sugared). Is is necessary to write the parser in Java? Wouldn't it be better to leverage existing work? What do you think about using GHC's Happy and Alex definitions to *generate* a Java parser? How would you handle calls to library functions i.e. the hierarchical libraries? > 3. write the execution engine (graph reducer), which should: > (a) accept breakpoint definition upon execution startup and > during it (i.e. we are not stuck to breakpoint definition > before program startup > only) > (b) be able to interpret all programs written in the chosen language > (c) provide an observer interface for components interested > on observing the execution > 4. write the UI components for showing the execution engine > output (i.e. debugger UI components) I think the system you've described is a lot like Vital: http://www.cs.kent.ac.uk/projects/vital/index.html They have a parser (for a subset of Haskell), and an execution engine. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** |
From: Bayley, A. <Ali...@ld...> - 2005-06-16 15:23:46
|
> -----Original Message----- > > I agree, if we could re-use an existing parser, that would be > very helpful. (Especially if we take into account that we > will need a parser that can give us the full AST for some of > the advanced functionalities that we plan.) When I searched > for one a year ago, I found none for Haskell that was > implemented in Java, though, or a grammar for a parser > generator that would generate one in Java (i.e. JavaCC or ANTLR). > > >What do you think about using GHC's Happy and Alex > > definitions to *generate* a Java parser? > Is it possible to have Happy generate a parser implementation > in Java? > Afaik it can only generate Haskell code. I was thinking more of writing a Parser in (say) Happy or Parsec that would parse the Haskell grammar spec (itself a Happy file), and then emit Java code. I was thinking of emitting Java code to do parsing, but your mention of JavaCC/ANTLR raises a new possibility: convert the Happy grammer to ANTLR or JavaCC input. > On the other hand, having a parser in Haskell might be fine, > provided we can find a way to marshal all information we need > back to the Java world. Well, what information DO we need? (All of it?) It looks as though for each AST data type in Haskell, we'd want a matching class in Java. That seems like a lot of work :-( Perhaps we can generate Java classes for each AST type from the Haskell sources in: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/hsSyn/ Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** |
From: Thiago A. <thi...@gm...> - 2005-06-17 16:51:27
|
> > I agree, if we could re-use an existing parser, that would be > > very helpful. (Especially if we take into account that we > > will need a parser that can give us the full AST for some of > > the advanced functionalities that we plan.) When I searched > > for one a year ago, I found none for Haskell that was > > implemented in Java, though, or a grammar for a parser > > generator that would generate one in Java (i.e. JavaCC or ANTLR). > > > > >What do you think about using GHC's Happy and Alex > > > definitions to *generate* a Java parser? > > Is it possible to have Happy generate a parser implementation > > in Java? > > Afaik it can only generate Haskell code. >=20 > I was thinking more of writing a Parser in (say) Happy or Parsec that wou= ld > parse the Haskell grammar spec (itself a Happy file), and then emit Java > code. I was thinking of emitting Java code to do parsing, but your mentio= n > of JavaCC/ANTLR raises a new possibility: convert the Happy grammer to AN= TLR > or JavaCC input. Let me try to draw a draft schema of what I've got of your idea. .Y (Happy grammar) File =3D> [Happy to JavaCC grammar file translator] =3D> .jj (JavaCC grammar) File =3D> [JavaCC - Java Parser Generator] =3D> .java File (Haskell parser written in Java) (Bracketed names are programs and non-bracketed names are inputs and outputs for them) This would be the best suited approach. A JavaCC grammar for Haskell would be a very good bridge between Haskell and Java world (at least for the AST construction problema). And besides that, we could improve our (now) Java parser to provide the info we need. And, of course, we would be free from having to adapt to language extensions, since this would be fulfilled by a simple a parser translator re-run. The main issue here is to write the grammar file translator. And I think the best approach to doing it is take the Happy.y grammar file itself and add the semantic actions for the translation. What do you think? For the time being, I am writing a JavaCC grammar file for a haskell subset (namely one that includeds only the most simple expressions and with no layout support). > Well, what information DO we need? (All of it?) It looks as though for ea= ch The debugger prototype should ideally answer us that question. > AST data type in Haskell, we'd want a matching class in Java. That seems > like a lot of work :-( Perhaps we can generate Java classes for each AST > type from the Haskell sources in: > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/hsSyn/ Perhaps the data types on the parser itself will be sufficient. But I really don't know what's inside hsSyn. Haskell (and GHC) itselft isn't my main area of expertise. Thiago Arrais thi...@gm... |
From: Bayley, A. <Ali...@ld...> - 2005-06-21 08:09:09
|
> From: Thiago Arrais [mailto:thi...@gm...] > > The main issue here is to write the grammar file translator. > And I think the best approach to doing it is take the Happy.y > grammar file itself and add the semantic actions for the > translation. What do you think? I'm not sure how well that would work. I was thinking along the lines of writing a parser for the Happy input grammar. It would take the Happy file directly from GHC's source, and would simply ignore the actions attached to each production. Of course, I'm assuming that each element of Happy's input grammar can be converted easily to JavaCC or ANTLR grammar. > For the time being, I am writing a JavaCC grammar file for a > haskell subset (namely one that includeds only the most > simple expressions and with no layout support). In a previous email I asked a scope-related question, which I think was missed: do you have a plan for handling calls to precompiled libraries i.e. prelude functions? For a debugger to be widely useful (i.e. more than just a research toy) it will have to solve this problem. How would this fit in with an "execution engine"? Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** |
From: Thiago A. <thi...@gm...> - 2005-06-21 17:04:46
|
2005/6/21, Bayley, Alistair <Ali...@ld...>: > > From: Thiago Arrais [mailto:thi...@gm...] > > > > The main issue here is to write the grammar file translator. > > And I think the best approach to doing it is take the Happy.y > > grammar file itself and add the semantic actions for the > > translation. What do you think? >=20 > I'm not sure how well that would work. I was thinking along the lines of > writing a parser for the Happy input grammar. It would take the Happy fil= e > directly from GHC's source, and would simply ignore the actions attached = to Then we are thinking the same. :-) Maybe I wasn't clear enough because of the 'Happy.y file'. I meant it is the .Y file that describes the Happy input file grammar itself. So let's draw another schema of the solution I though, just to make ourselves clear: (I have extended the last schema convention a little. The angle brackets indicate human intervention to produce output instead of program) 1. Happy.Y File (the one that describes the Happy input grammar itself) without the semantic actions =3D> 2. <Writer responsible for adding the semantic actions that convert Happy grammar to JavaCC grammars> =3D> 3. HappyToJavaCC.Y File (This one is the Happy.Y file, but its semantic actions were replaced to ones so that the parser produces a JavaCC compilation unit) =3D> 4. [Happy] =3D> 5. HappyToJavaCC.hs File (This is the haskell program that takes as input a Happy - i.e. .Y - Grammar and produces a JavaCC - i.e. JJ - grammar as output) So, the number 5 file/program is our so called 'translator'. Please let me know if i'm getting something wrong. And I just thought of another option. Instead of using a parser to produce JavaCC code, we could read the AST that is built upon its execution and produce the JavaCC code from there. Do we have the access to a parser that generates that tree? > each production. Of course, I'm assuming that each element of Happy's inp= ut > grammar can be converted easily to JavaCC or ANTLR grammar. I have worked for some time with JavaCC, but I don't know much of Happy grammars. AFAIK they share the same main idea and can be (fairly) easily exchanged. We need some studying in here. > > For the time being, I am writing a JavaCC grammar file for a > > haskell subset (namely one that includeds only the most > > simple expressions and with no layout support). >=20 > In a previous email I asked a scope-related question, which I think was > missed: do you have a plan for handling calls to precompiled libraries i.= e. > prelude functions? For a debugger to be widely useful (i.e. more than jus= t a > research toy) it will have to solve this problem. How would this fit in w= ith > an "execution engine"? Sorry for missing it... Shame on me. I have to agree that this feature is vital for the debugger usability. I'd say it is essencial. And the short answer for your question is: yes, I plan to handle this so-called builtin function calls, but not in this first prototype. The execution engine on the prototype that I am developing won't be able to handle these builtin function calls (actually the language that is being implemented doesn't even have a prelude) and is what you can call a research toy. Its purpose is to provide us with what we can call an 'Execution Engine Interface' that specifies what we will need from the underlying code executor to make debugging possible and, more importantly, worth. Then we could adapt this interface to (virtually) any execution engine we want (like ghc compiled code). What I am most concerned about is the capability of the existing tools to give us the info we need. At the moment I am mostly inclined to adopt buddha as the 'execution engine'. It actually modifies the source code to output debug specific information while yielding the same result. We could get the user program, give it as input to buddha, execute the output and gather the debug info buddha gives us to 'fake' the step-by-step execution of the code. When I say fake, I mean that the real code will be actually fully executed before we start our debug seession. But there's a problem if we use purely this approach: we won't be able to let the user change the program during the execution. And I mean something like trying to evaluate the expression: (\x -> (a x) * 2) 30 where 'a' is a user function. Let's say the user know that the result from the expression above is wrong, but he doesn't know whether the error is on the 'a' function or on the expression itself. In my opnion the user should be able to bypass the real evaluation of (a 30), replacing it with the expected result and then evaluating the new expression. This way he can be sure where the error is located. I think this feature would be a very good to support 'bug isolation' (which is the purpose of the debugger). But I don't know if we can have it as transparent as we want by using buddha. Thanks, Thiago Arrais thi...@gm... |
From: Bayley, A. <Ali...@ld...> - 2005-06-22 08:33:37
|
> From: Thiago Arrais [mailto:thi...@gm...] > > Then we are thinking the same. :-) > > Maybe I wasn't clear enough because of the 'Happy.y file'. I meant it > is the .Y file that describes the Happy input file grammar itself. So > let's draw another schema of the solution I though, just to make > ourselves clear: Sorry, I wasn't clear about what I was suggesting, and I also misunderstood your plan. I thought that you were planning to take this Happy input file (which describes the Haskell grammar) and change the actions associated with each production: the code inside the { }: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/Parser .y.pp?rev=1.30 Now I understand that you plan to use something like this: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/happy/src/Parser.ly?rev=1. 15 ... to write a parser to parse the Haskell Happy grammar and emit a JavaCC grammar. So we do agree on that. > And I just thought of another option. Instead of using a parser to > produce JavaCC code, we could read the AST that is built upon its > execution and produce the JavaCC code from there. Do we have the > access to a parser that generates that tree? Sorry, you've lost me here. Initially the goal was to create a Haskell parser in Java with minimal effort (hence the Happy -> JavaCC convolution). Now that we have (an imaginary) one, the next step is to create the AST. GHC obviously has one: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/hsSyn/ I assume that JavaCC is like other parser-generators, in that you specify the grammar and attach host language code to each production. > The execution engine [...] purpose is to provide us with what we can > call an 'Execution Engine Interface' that specifies what we will need > from the underlying code executor to make debugging possible and, more > importantly, worth. Then we could adapt this interface to (virtually) > any execution engine we want (like ghc compiled code). Oh, cool. > What I am most concerned about is the capability of the existing tools > to give us the info we need. At the moment I am mostly inclined to > adopt buddha as the 'execution engine'. It actually modifies the > source code to output debug specific information while yielding the > same result. We could get the user program, give it as input to > buddha, execute the output and gather the debug info buddha gives us > to 'fake' the step-by-step execution of the code. When I say fake, I > mean that the real code will be actually fully executed before we > start our debug seession. But there's a problem if we use purely this > approach: we won't be able to let the user change the program during > the execution. And I mean something like trying to evaluate the > expression: Yes, this sounds hard. Changing a value in an executing program would mean replacing the value inside the thunk/cell on the heap. This sounds like it would be quite runtime-specific (and possibly fragile). It also assumes that no optimisations (registerised arguments, unboxed values, etc) have taken place, which is a similar problem that HsDebug faced e.g. tail-calls and function-inlining destroys the call-stack. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** |
From: Thiago A. <thi...@gm...> - 2005-06-22 13:05:37
|
Hello, > > And I just thought of another option. Instead of using a parser to > > produce JavaCC code, we could read the AST that is built upon its > > execution and produce the JavaCC code from there. Do we have the > > access to a parser that generates that tree? >=20 > Sorry, you've lost me here. >=20 > Initially the goal was to create a Haskell parser in Java with minimal > effort (hence the Happy -> JavaCC convolution). Now that we have (an > imaginary) one, the next step is to create the AST. GHC obviously has one= : > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/hsSyn/ Actually, I think I didn't lose it. The AST I mentioned was the one outputed by parsing the .Y file. It is just another approach for the translator. Instead of parsing the .Y file, it could read just the (already parsed) AST. But it only works if we already have a parser that generates that tree. And we actually have it: the happy/src/Parser.ly actually does that. What I am talking about is to get the AST outputed by this parser and have a (convetional) haskell program process it to produce source code for the Java parser generator. Which one do you think is the fastest approach for making the translator? =20 > I assume that JavaCC is like other parser-generators, in that you specify > the grammar and attach host language code to each production. Yes, it is. > Yes, this sounds hard. Changing a value in an executing program would mea= n > replacing the value inside the thunk/cell on the heap. This sounds like i= t > would be quite runtime-specific (and possibly fragile). It also assumes t= hat > no optimisations (registerised arguments, unboxed values, etc) have taken > place, which is a similar problem that HsDebug faced e.g. tail-calls and > function-inlining destroys the call-stack. I have thought of feeding an interpreter with the program we want to debug and then giving it the expressions we want to evaluate (and this would be, of course, user controlled) step by step. This frees us from (re)implementing the library calls. Our adapter would solely do the translation process. But what would be the expressiveness power of this approach (I mean: what can we do not to have just an interpreter front-end)? And what would be our limitations? Thanks, Thiago Arrais |
From: Bayley, A. <Ali...@ld...> - 2005-06-27 10:40:36
|
> From: Thiago Arrais [mailto:thi...@gm...] > > > Sorry, you've lost me here. > > Actually, I think I didn't lose it. No, what I meant was: you've left me behind. I'm lost. (I'll have to monitor my use of English colloquialisms :-) Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** |
From: Thiago A. <thi...@gm...> - 2005-06-27 12:06:58
|
> No, what I meant was: you've left me behind. I'm lost. (I'll have to moni= tor > my use of English colloquialisms :-) Oh, right. (And now I make my Oh-why-didn't-I-get-it-in-the-first-place-fac= e) I think I will have to get more used to those. :-) This was just a little misundertanding. A very little one. Good thing is I can see you won't let the communication gap grow to the point we have a big one. And that's what we can't let happen: it would be *very* counterproductive, given the fact we already have a big communication gap that are the miles beetwen my workstation and yours. Let's go on. Thiago Arrais |
From: Leif F. <hi...@le...> - 2005-06-15 21:39:49
|
> Is is necessary to write the parser in Java? Wouldn't it be better to > leverage existing work? I agree, if we could re-use an existing parser, that would be very helpful. (Especially if we take into account that we will need a parser that can give us the full AST for some of the advanced functionalities that we plan.) When I searched for one a year ago, I found none for Haskell that was implemented in Java, though, or a grammar for a parser generator that would generate one in Java (i.e. JavaCC or ANTLR). >What do you think about using GHC's Happy and Alex > definitions to *generate* a Java parser? Is it possible to have Happy generate a parser implementation in Java? Afaik it can only generate Haskell code. On the other hand, having a parser in Haskell might be fine, provided we can find a way to marshal all information we need back to the Java world. > I think the system you've described is a lot like Vital: > http://www.cs.kent.ac.uk/projects/vital/index.html > > They have a parser (for a subset of Haskell), and an execution engine. I had a look at Vital a while ago. It seemed to me much more a spreadsheet-like approach than the source-code-oriented approach we have in the IDE. Nonetheless, it might be worth a fresh look. But I have never seen the sources of Vital, so far, and don't know how it is licensed. Ciao, Leif |