[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: language translator help

From: Neil Jerram
Subject: Re: language translator help
Date: 18 May 2002 14:47:24 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "thi" == Thien-Thi Nguyen <address@hidden> writes:

    thi>    From: Neil Jerram <address@hidden>
    thi>    Date: 28 Apr 2002 19:21:49 +0100

    thi>    What tools are now available for writing parsers in Scheme?  Last 
    thi>    we had this conversation on the list, ISTR that there were many 
    thi>    but nothing quite complete.

    thi> ok, i've chosen this to be the "application test load" for
    thi> guile-1.4.2.  why?  because guile-lang-allover-0.1 needs to
    thi> install a private shared object library, which motivates
    thi> design of how to support that.  this design can be used for
    thi> guile itself.

Well, I was impressed by your NEWS list for 1.4.1, so perhaps your
approach is good.  And it will definitely be good to get
guile-lang-allover working.  BTW, is there any reason not to sync
guile-lang-allover back up with the guile-rgx-ctax module?

    thi> in the process, libguilereadline and libqthreads will also be moved to
    thi> $prefix/lib/guile/1.4.2 -- the only thing in $prefix/lib will be
    thi> libguile -- and scheme bindings to lt_* will be introduced (where it
    thi> makes sense).  this allows `load-extension' and ilk implementation
    thi> experimentation.

On this point I'd really like to see consensus (w.r.t. 1.6.x and 1.8.x
plans) before you proceed.

    thi> 1.4.2 also back-ports :select and :renamer, so it's a good
    thi> time to introduce the "user-defined interface" hook
    thi> mechanisms discussed (which is actually the original form the
    thi> :select and :renamer code when it was first posted), and
    thi> start closing the loop on not just loading sofiles but
    thi> building them too.  (1.4.3 back-ports scripts/ too, including
    thi> yet to be written "build-guile-module".)

    thi> (fyi, first module built suchly will be guile-doc-snarf
    thi> backend.)

Sounds nice, especially when compared with our ongoing failure to get
a 1.6.x out the door.  Important question, though: is it perhaps the
case that you are only able to do this because you're running with
1.4.x on your own and with hindsight?  In other words, do you think a
similarly planned model could apply to bleeding edge development?

    thi> i will unsubscribe from guile-devel to protest its existence.
    thi> i don't believe in standing away from the users like that.

Hmm.  Even though you may be right that this division is bad (which is
at least debatable), I don't see how you will achieve consensus on
1.4.x directions without being subscribed to guile-devel.  So this is
a bit too confrontational for my liking.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]