language translator help

language translator help

[John W. Eaton]

Although there has been much inactivity in the year or so since I
first asked this list for comments about the possibility of some kind
of Guile/Octave merger, I've not given up.

Right now, my ideas are that I would eventually modify Octave's parser
to emit Guile code, and then pass that off to Guile to interpret.  My
reasons for wanting to do this include

 * improving the performance of Octave's interpreter

 * immediately gaining some functionality that would otherwise be hard
   to get (object-oriented programming with goops, an interface to
   external packages like gtk, etc.)

 * allowing me to avoid having to maintain yet another scripting
   language interpreter (though it remains to be seen whether a
   translator will be any simpler than the current interpreter).

Obviously, making the new system fully functional would require not
only writing the translator, but also creating a run-time library of
Octave primitives that could be called from Guile.

As I see it, adapting Octave's core functions (the stuff written in C,
C++, and Fortran) for use with Guile is a big job, but one that is
certainly possible.  Even just having that capability inside of Guile
would probably be quite useful to some.  For the Octave users who are
more comfortable programming in Octave rather than Scheme (and this
includes me, at least currently), having the translator is essential.

Before jumping in and doing a lot of coding, I'm trying to get a
clearer idea about how the translation would work.  Some questions:

 * Is it a good idea for the translator to parse Octave code and emit
   Scheme code as strings that are then reinterpreted by Guile?  Is
   there a better way of doing that?  My guess is that this is OK, and
   the overhead of parsing twice is not so important.

 * I originally thought that translating the syntax would be trivial,
   but now I find that I'm really quite clueless when it comes right
   down to doing this part.

   For example, Octave has C-like break and continue statements for
   breaking out of or jumping to the end of a loop.  What is a
   reasonable way to translate them to Scheme?  I came up with a way
   to handle both, but they involve call/cc and seem much more
   complicated than the corresponding Octave code.  I'm left thinking
   that there must be a better way.  However, solutions that
   completely rewrite the structure of the loop are not so interesting
   to me unless there is a way to do that in a way that doesn't
   require the translator to do a lot of analysis of the incoming code.

   Can anyone offer some clues about these kinds of translation
   problems?  Failing that, is there a "Scheme for C Programming
   Dummies" kind of document somewhere?

 * If syntax can trip me up, I know semantics will too.  For example,
   it's not clear to me how to handle the differences in Octave and
   Scheme scoping rules for variables.

Any pointers or discussion (public or private) would be most
appreciated.

Thanks,

jwe

-- 
www.octave.org        | Unfortunately we were hoplessly optimistic in 1954
www.che.wisc.edu/~jwe | about the problems of debugging FORTRAN programs.
                      |                                       -- J. Backus

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

My translator is a Scheme program that parses and reads Python, and
turns it into Scheme.  "Turns it into scheme" means not that it writes
ASCII and uses the Scheme reader; of course it just uses cons to make
forms.  That's the Right Thing.

The way to translate break, goto, and such is indeed with call/cc (or,
if you're a fan of it, using call/ec).

Scoping is best handled by doing it by hand.  I have python variables
*not* as scheme variables, but rather as just indexes in a table.  A
python variable ref is then compiled into a lookup in that table.  A
more clever compiler could detect safe cases where it can just be a
Scheme variable.

Global variables are handled differently: each language's globals show
up as a subset of the globals of the other language, and compilation
of Python into Scheme replaces the pythony names with the Schemey
ones.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Neil Jerram]

>>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:

    John> Although there has been much inactivity in the year or so
    John> since I first asked this list for comments about the
    John> possibility of some kind of Guile/Octave merger, I've not
    John> given up.

That's good news; I'd love to see this idea succeed.  Would you like
some help?

(Background: I recently wrote the prototype Elisp translator in CVS
unstable, so I have a little relevant experience.)

    John> Right now, my ideas are that I would eventually modify
    John> Octave's parser to emit Guile code, and then pass that off
    John> to Guile to interpret.  My reasons for wanting to do this
    John> include

    John>  * improving the performance of Octave's interpreter

If Elisp is a guide, this will only happen if you make N Octave
executions turn into 1 translation + N evaluations (for N>>1).
Current Elisp experience is that 1 translation + 1 Guile evaluation is
_slower_ than 1 native Elisp evaluation.

    John>  * immediately gaining some functionality that would otherwise be hard
    John>    to get (object-oriented programming with goops, an interface to
    John>    external packages like gtk, etc.)

Absolutely.

    John>  * allowing me to avoid having to maintain yet another scripting
    John>    language interpreter (though it remains to be seen whether a
    John>    translator will be any simpler than the current interpreter).

Yes, but two caveats here:

- You have to believe that implementing your language constructs in
  Scheme is easier to maintain than implementing them in C.

- Because of the performance issue mentioned above, I'd say it's still
  an open question whether you'll get adequate performance
  implementing the language in Scheme.  You might end up wanting to
  keep it in C anyway (but switch to using Guile data types).

    John> Obviously, making the new system fully functional would
    John> require not only writing the translator, but also creating a
    John> run-time library of Octave primitives that could be called
    John> from Guile.

Right, but this is just a matter of wrapping existing code, isn't it?

    John> As I see it, adapting Octave's core functions (the stuff
    John> written in C, C++, and Fortran) for use with Guile is a big
    John> job, but one that is certainly possible.  Even just having
    John> that capability inside of Guile would probably be quite
    John> useful to some.

(use-modules (octave)) - would be wonderful.

    John> For the Octave users who are more comfortable programming in
    John> Octave rather than Scheme (and this includes me, at least
    John> currently), having the translator is essential.

Totally agree; this is what Guile is supposed to be about: providing
language flexibility to its users.  And who knows, it may turn out
that the Octave language syntax is convenient for tasks unrelated to
mathematics, too.

    John> Before jumping in and doing a lot of coding, I'm trying to
    John> get a clearer idea about how the translation would work.
    John> Some questions:

    John>  * Is it a good idea for the translator to parse Octave code and emit
    John>    Scheme code as strings that are then reinterpreted by Guile?  Is
    John>    there a better way of doing that?  My guess is that this is OK, and
    John>    the overhead of parsing twice is not so important.

This is what I'd begin with.  Performance-wise I can't guarantee it'll
work out, but we have to try it and see.

    John>  * I originally thought that translating the syntax would be trivial,
    John>    but now I find that I'm really quite clueless when it comes right
    John>    down to doing this part.

    John>    For example, Octave has C-like break and continue statements for
    John>    breaking out of or jumping to the end of a loop.  What is a
    John>    reasonable way to translate them to Scheme?  I came up with a way
    John>    to handle both, but they involve call/cc and seem much more
    John>    complicated than the corresponding Octave code.  I'm left thinking
    John>    that there must be a better way.  However, solutions that
    John>    completely rewrite the structure of the loop are not so interesting
    John>    to me unless there is a way to do that in a way that doesn't
    John>    require the translator to do a lot of analysis of the incoming code.

    John>    Can anyone offer some clues about these kinds of translation
    John>    problems?  Failing that, is there a "Scheme for C Programming
    John>    Dummies" kind of document somewhere?

I'm not aware of such a document.  Suggest you post the translation
code that you've tried already.  I'll certainly take a look, and I
guess you'll get a deluge of suggestions from others as well.

    John>  * If syntax can trip me up, I know semantics will too.  For example,
    John>    it's not clear to me how to handle the differences in Octave and
    John>    Scheme scoping rules for variables.

What are the Octave scoping rules?  For dynamic scoping (a la Elisp),
Guile has the `@bind' macro for setting and restoring such variables'
values.  In the Elisp case, this allows Elisp variables to be Guile
variables directly.  (Except that it doesn't cope with buffer-local,
etc.)

As Thomas says, other more explicit approaches are possible - you have
full control over how you translate an Octave variable reference.

Regards,
        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[John W. Eaton]

On 27-Apr-2002, Neil Jerram <neil@ossau.uklinux.net> wrote:

| >>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:
| 
|     John> Although there has been much inactivity in the year or so
|     John> since I first asked this list for comments about the
|     John> possibility of some kind of Guile/Octave merger, I've not
|     John> given up.
| 
| That's good news; I'd love to see this idea succeed.  Would you like
| some help?

Yes, absolutely!  I am really a novice when it comes to Scheme, so I
could really use some pointers there.

|     John>  * improving the performance of Octave's interpreter
| 
| If Elisp is a guide, this will only happen if you make N Octave
| executions turn into 1 translation + N evaluations (for N>>1).
| Current Elisp experience is that 1 translation + 1 Guile evaluation is
| _slower_ than 1 native Elisp evaluation.

I think it performance might be better in most cases because Octave's
interpreter is known to be really slow for many operations.

|     John>  * allowing me to avoid having to maintain yet another scripting
|     John>    language interpreter (though it remains to be seen whether a
|     John>    translator will be any simpler than the current interpreter).
| 
| Yes, but two caveats here:
| 
| - You have to believe that implementing your language constructs in
|   Scheme is easier to maintain than implementing them in C.

Well, I'm not sure.  But it is a lot of work to write an maintain an
interperter for a special language, and much of that effort is
duplicated by every scripting language.  People using Octave and Guile
both want access to OS system calls and library functions (from basic
stuff to GUI toolkits) so it seems wasteful to me that we build many
interfaces to all these different libraries.  I think it would be much
better to take advantage of existing work that's already been done.

| - Because of the performance issue mentioned above, I'd say it's still
|   an open question whether you'll get adequate performance
|   implementing the language in Scheme.  You might end up wanting to
|   keep it in C anyway (but switch to using Guile data types).

Along with a way to call Guile functions, this would offer a lot, but
I would still like to get away from having to maintain the low-level
details of an interpreter.

|     John> Obviously, making the new system fully functional would
|     John> require not only writing the translator, but also creating a
|     John> run-time library of Octave primitives that could be called
|     John> from Guile.
| 
| Right, but this is just a matter of wrapping existing code, isn't it?

Yes and no.  There is the opportunity to correct some of the mistakes
of the past too, which might mean more than just wrapping the current
Octave classes.

|     John> For the Octave users who are more comfortable programming in
|     John> Octave rather than Scheme (and this includes me, at least
|     John> currently), having the translator is essential.
| 
| Totally agree; this is what Guile is supposed to be about: providing
| language flexibility to its users.

Yes, but there seem to be no fully functional examples of actually
doing this yet.  If that's correct, why not?  What's keeping people
from doing this?

One problem that I can imagine is that for languages like Perl, or
Python, which are starting to be quite large, it's not enough to just
translate the syntax to scheme, you need the run-time.  Integrating
all of that could be a lot of work.  But I think that a bigger problem
is that there is no standard for these languages, so the language
definition is whatever the real Perl or Python interpreters do today.
Unless the authors of those tools integrate the Guile interpreter in
their own code, the fork becomes difficult to maintain.

These sorts of problems would not cause trouble for Octave, because I
would be integrating Guile completely.  I'm just trying to understand
what might be the reasons that we don't have many translators.

|     John>  * Is it a good idea for the translator to parse Octave code and emit
|     John>    Scheme code as strings that are then reinterpreted by Guile?
| 
| This is what I'd begin with.  Performance-wise I can't guarantee it'll
| work out, but we have to try it and see.

I think this would be the simplest thing to start with, because it
would be easy to debug.  You could simply look at the Scheme code that
is generated and see whether it was correct.

Thomas Bushnell also suggested generating Scheme forms using cons
instead of writing ASCII text.  Can this be done easily from C for
every language construct?  If so, it seems that it would be easy
enough to switch to this method once the translate-and-emit-text
system works.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> Thomas Bushnell also suggested generating Scheme forms using cons
> instead of writing ASCII text.  Can this be done easily from C for
> every language construct?  If so, it seems that it would be easy
> enough to switch to this method once the translate-and-emit-text
> system works.

Don't use C at all!  My compiler is a Scheme program.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[John W. Eaton]

On 27-Apr-2002, Thomas Bushnell, BSG <tb@becket.net> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > Thomas Bushnell also suggested generating Scheme forms using cons
| > instead of writing ASCII text.  Can this be done easily from C for
| > every language construct?  If so, it seems that it would be easy
| > enough to switch to this method once the translate-and-emit-text
| > system works.
| 
| Don't use C at all!  My compiler is a Scheme program.

That's a possibility.  I can see an advantage if you could have the
entire language implemented in Scheme, because then your language
works wherever Guile works, with no compiling necessary.

I have a significant amount of existing code in C/C++/Fortran for the
Octave parser, interpreter, and run-time that I was hoping to take
advantage of.  It may still make sense to reimplement most of the
parser in Scheme if the interpreter is replaced with Guile. It is
quite unlikely that the run-time library (including lots of things
like linear algebra subroutines that people expect to run as fast as
possible) will be rewritten in Scheme.  So, if there are significant
bits of the run-time library that will be written in C/C++/Fortran,
does it make a big difference if some of the parser is also written in
C/C++?

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> So, if there are significant bits of the run-time library that will
> be written in C/C++/Fortran, does it make a big difference if some
> of the parser is also written in C/C++?

Python also has an extensive library.  I think the best way to deal is
to make the features of that library available to Guile: as ordinary
Guile extensions.  Then write wrappers for them.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[John W. Eaton]

On 27-Apr-2002, Thomas Bushnell, BSG <tb@becket.net> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > So, if there are significant bits of the run-time library that will
| > be written in C/C++/Fortran, does it make a big difference if some
| > of the parser is also written in C/C++?
| 
| Python also has an extensive library.  I think the best way to deal is
| to make the features of that library available to Guile: as ordinary
| Guile extensions.  Then write wrappers for them.

Sure.  But this doesn't really answer my question.  If the wrapper for
the library and the library itself are written in C, then that is
something that must be compiled before it can be used with Guile, and
may need to be ported if it contains platform-dependent bits.  So if
you already have that dependency on compiled C code, why is it
important that the parser/translator be written in Scheme instead of
C?

jwe


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> Sure.  But this doesn't really answer my question.  If the wrapper for
> the library and the library itself are written in C, then that is
> something that must be compiled before it can be used with Guile, and
> may need to be ported if it contains platform-dependent bits.  So if
> you already have that dependency on compiled C code, why is it
> important that the parser/translator be written in Scheme instead of
> C?

Right, but then I'd put that library as part of the standard Gnome
set.  In other words, extend Gnome first, then provide the
conventional interface from Python.

Thomas

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[John W. Eaton]

On 28-Apr-2002, Thomas Bushnell, BSG <tb@becket.net> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > Sure.  But this doesn't really answer my question.  If the wrapper for
| > the library and the library itself are written in C, then that is
| > something that must be compiled before it can be used with Guile, and
| > may need to be ported if it contains platform-dependent bits.  So if
| > you already have that dependency on compiled C code, why is it
| > important that the parser/translator be written in Scheme instead of
| > C?
| 
| Right, but then I'd put that library as part of the standard Gnome
| set.  In other words, extend Gnome first, then provide the
| conventional interface from Python.

I assume you meant Guile, not Gnome.

What if the run-time library for the translator isn't something that
belongs as part of standard Guile?  Where is the benefit then?  And if
the run-time library for the translator does belong in the standard
Guile, why wouldn't the parser also belong there?

The point is that if a language translator extension for Guile already
requires significant bits of possibly platform-dependent C code, I
don't think it matters whether the parser is written in Scheme, C, or
some other compiled language.  The complete translator still requires
compiled C code to implement, so I don't see a reason that using
Scheme instead of C is necessarily better (other than "Scheme is cool,
use Scheme!").

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> | Right, but then I'd put that library as part of the standard Gnome
> | set.  In other words, extend Gnome first, then provide the
> | conventional interface from Python.
> 
> I assume you meant Guile, not Gnome.

Yes, sorry for the confusion.

> What if the run-time library for the translator isn't something that
> belongs as part of standard Guile?  Where is the benefit then?  And if
> the run-time library for the translator does belong in the standard
> Guile, why wouldn't the parser also belong there?

Guile needs a facility to build such things itself, no doubt.
Ultimately, it needs to be a shared library--whether part of guile
directly or not, depending on how sophisticated the guile foreign
function interface is (something I'm not up-to-speed about).

The answer to your question is: Scheme is a convenient and pleasing
language.  Why implement things in a suckier language when you can do
it in Scheme?!

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[John W. Eaton]

On 28-Apr-2002, Thomas Bushnell, BSG <tb@becket.net> wrote:

| The answer to your question is: Scheme is a convenient and pleasing
| language.  Why implement things in a suckier language when you can do
| it in Scheme?!

I don't want to start a language war, but while there are certainly
some objective arguments that could be made about the capabilities of
various computer languages, I think that whether Scheme is convenient
and pleasing is mostly a matter of what problems you are trying to
solve with the language, and of course, personal preference.

FWIW, my mind has apparently been corrupted by procedural languages
which have nice (to me at least, and I suspect I'm not the only one)
looping constructs, to the point that the equivalent forms for looping
in Scheme seem pretty "sucky" by comparison.  :-)

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: "John W. Eaton" <jwe@bevo.che.wisc.edu>
   Date: Mon, 29 Apr 2002 11:36:57 -0500

   I don't want to start a language war, but while there are certainly
   some objective arguments that could be made about the capabilities of
   various computer languages, I think that whether Scheme is convenient
   and pleasing is mostly a matter of what problems you are trying to
   solve with the language, and of course, personal preference.

   FWIW, my mind has apparently been corrupted by procedural languages
   which have nice (to me at least, and I suspect I'm not the only one)
   looping constructs, to the point that the equivalent forms for looping
   in Scheme seem pretty "sucky" by comparison.  :-)

this is getting away from the real point that normally arises from these
kinds of discussions: the more translation (i.e., parsing and downstream
ilk) and execution can be separated, the easier the whole system is to
design, implement, extend and maintain.  i'm sure this is recognized, so
the question is: how to reflect that in the artifacts and build on it?

here's an artifact of my procrastination (on other guile duties):

                      octave-xlat-env     octave-exec-env
  
  use-modules         (lang octave xlat)  (lang octave exec)

  input               source (text)       procs/vars/"main" 
  
  operations          loop transforms     eval
                      other transforms
  
  side-effects        -                   "octave code" execution
  
  output              procs/vars/"main"   -

here, the procs/vars/"main" are scheme objects and structures.  perhaps
these can be serialized and written to disk (if it is desired to truly
demonstrate separation).  if the disk image has the appropriate header
it could be invoked from the command-line directly.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

John W. Eaton <jwe@bevo.che.wisc.edu> wrote:
> FWIW, my mind has apparently been corrupted by procedural languages
> which have nice (to me at least, and I suspect I'm not the only one)
> looping constructs, to the point that the equivalent forms for looping
> in Scheme seem pretty "sucky" by comparison.  :-)

"Recursion versus Looping" is one of the great performance hindrances in
most languages, as their compilers often optimise them differently.  You can
see this in the number of times replacing one with the other crops up in the
refactoring documentation.  The distinction is largely artificial, so by
removing one of them, Scheme comes out ahead.  

What I want to know is whether it is possible to parallelise "map", which
could have huge performance boosts on multi-processor systems.  Will I trip
up from code that assumes map is an iterator?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> What I want to know is whether it is possible to parallelise "map", which
> could have huge performance boosts on multi-processor systems.  Will I trip
> up from code that assumes map is an iterator?

Hrm.  In general, yes, you will trip up.  Code cannot assume that the
functions are called in any particular order, but it can assume that
they are called one at a time.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> I don't want to start a language war, but while there are certainly
> some objective arguments that could be made about the capabilities of
> various computer languages, I think that whether Scheme is convenient
> and pleasing is mostly a matter of what problems you are trying to
> solve with the language, and of course, personal preference.

Yeah, but this is the Guile mailing list, you know.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Neil Jerram]

>>>>> "Thomas" == Thomas Bushnell, BSG <tb@becket.net> writes:

    Thomas> "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
    >> Thomas Bushnell also suggested generating Scheme forms using cons
    >> instead of writing ASCII text.  Can this be done easily from C for
    >> every language construct?  If so, it seems that it would be easy
    >> enough to switch to this method once the translate-and-emit-text
    >> system works.

    Thomas> Don't use C at all!  My compiler is a Scheme program.

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

On the other hand, you (presumably) already have a working parser in
C, and, yes, it should be easy to make it produce Scheme forms
directly from C.  (BTW, I meant generation of Scheme forms before, not
ASCII text.)

I'd expect this to work roughly as follows.  Suppose your parser has a
Bison-like structure and you're parsing a binary operator expression:

 <expr> := <subexpr> <binop> <subexpr>

If $1, $2 and $3 contain previously constructed Scheme forms for
<subexpr>, <binop> and <subexpr>, you can construct the Scheme form
for the whole lot by:

 scm_list_3 ($2, $1, $3);

This assumes that $2 already holds a Scheme symbol, variable or
procedure object.  So, when the token for <binop> was read, you should
have returned the appropriate Scheme object by mapping from the token
string - no big deal there.  The choice between symbol, variable and
procedure is interesting ...

- Using a symbol, say `+', means that the constructed Scheme
  expression will need to be evaluated in a module that has a binding
  for `+'.  Depending on what else you might want to use module
  bindings for, it might be inconvenient for the module namespace to
  include such bindings.  Hence you might prefer ...

- Using a variable means that the constructed expression can be
  evaluated in a module without builtin bindings, but the variable's
  value can still be modified by any code that can get to that
  variable.  In Scheme, for example:

  (define (f)
    (+ 3 4))

  (define + -)

  (f) => -1

  So, should Octave expressions like "3 + 4" be subject to code being
  able to redefine + ?

- Using a procedure means that redefinitions of + won't affect this
  expression.

It also assumes that $1 and $3 are either lists themselves, or
instances of `Octave data'.  This raises another important question:
how is Octave data represented in Guile?

- At one end of the possibility spectrum, you could define an
  `octave-data' smob type, and handle Octave typing internally inside
  this smob, thus keeping Guile and Octave data completely separate.

- At the other end, you could force as many existing Octave types as
  possible into the nearest available Guile types: floats, uniform
  arrays and so on.  Do the Guile types have sufficient precision for
  you to do this?  Is the uniform array interface convenient?  Etc.

In summary, you can produce Scheme forms for every possible Scheme
language construct from C, and it is pretty easy to do so.  But there
are still lots of questions about exactly what those Scheme forms
should contain.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thomas Bushnell, BSG]

Neil Jerram <neil@ossau.uklinux.net> writes:

>     Thomas> Don't use C at all!  My compiler is a Scheme program.
> 
> What tools are now available for writing parsers in Scheme?  Last time
> we had this conversation on the list, ISTR that there were many ideas
> but nothing quite complete.

I didn't bother with fancy tools.  A straightfoward recursive descent
parser is not too hard to write, so I did.

> On the other hand, you (presumably) already have a working parser in
> C, and, yes, it should be easy to make it produce Scheme forms
> directly from C.  (BTW, I meant generation of Scheme forms before, not
> ASCII text.)

No, I have a parser written in Scheme, just like I said.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Neil Jerram]

>>>>> "Thomas" == Thomas Bushnell, BSG <tb@becket.net> writes:

    >> On the other hand, you (presumably) already have a working parser in
    >> C, and, yes, it should be easy to make it produce Scheme forms
    >> directly from C.  (BTW, I meant generation of Scheme forms before, not
    >> ASCII text.)

    Thomas> No, I have a parser written in Scheme, just like I said.

My comments here were directed at John; sorry for not being clear.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 28 Apr 2002 19:21:49 +0100

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

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

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

the two dirs

  $prefix/lib/guile/VERSION/site/
  $prefix/lib/guile/site/

will be reserved for third party programs.

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

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

i encourage 1.5.x to continue, 1.6.x to be recast as 2.x (which allows
all the deprecated stuff to be removed and compatibility to be thrown
out the window w/ a clear conscience -- i.e., ttn will shut up), and
pushed out until at least the $prefix/lib/guile design is validated
(through 1.4.2 release and user feedback) and incorporated.  this gives
time to redo execution model right, too.  don't settle for poor quality,
folks; that gives GNU a bad name and you will burn in Programmer Hell
for it.

i will be communicating intent through modifying TODO, and findings and
opinions through checkins under workbook/.  i will unsubscribe from
guile-devel to protest its existence.  i don't believe in standing away
from the users like that.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

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

Please don't do this in the context of 1.4 releases.  We have the 1.7
series for experiments like that.  Please keep the 1.4 releases
(if you feel that you must divert resources to them) as bug fixing
releases.

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

On the specific point of what exactly a Guile extension or plugin is,
where to install it, how to link to it, etc, I remain convinced that
Guile itself should continue to treat its extensions as standard
operating system shared libraries, using libtool as the interface to
the operating system.

Experimentation can occur outside of Guile.  Packages that need to go
beyond the simplistic shared library view of the core Guile and want
to impose additional rules on the use of their shared libraries can do
so to a very large degree without needing any cooperation from Guile
itself.

For example, when we say that extension libraries should be installed
in $(libdir), a package can ignore this and install its libraries into
a special location and use 'load-extension' with an absolute filename.

> i encourage 1.5.x to continue, 1.6.x to be recast as 2.x (which allows
> all the deprecated stuff to be removed and compatibility to be thrown
> out the window w/ a clear conscience -- i.e., ttn will shut up),

Negative.  I don't have the feeling that we are dangerously
incompatible in the 1.6 series.  What do others think?  It would be
bad to switch strategies at this point, even if you have a point.

> and pushed out until at least the $prefix/lib/guile design is
> validated (through 1.4.2 release and user feedback)

What is wrong with Guile's current approach other than that you don't
like it?

> and incorporated.  this gives time to redo execution model right,
> too.  don't settle for poor quality, folks; that gives GNU a bad
> name and you will burn in Programmer Hell for it.

Well, Thien, there is enough opportunity for coding heros like
yourself to help us poor souls out.  Go and add interface versions to
lt_dlopen, for example.

> i will be communicating intent through modifying TODO, and findings and
> opinions through checkins under workbook/.  i will unsubscribe from
> guile-devel to protest its existence.  i don't believe in standing away
> from the users like that.

What?  The split is there so that people can choose not to be bothered
with developers chit chat.  You don't need a license to subscribe to
guile-devel.  It's a tool of organization, you process junkie, not of
dividing and conquering people.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 15 May 2002 22:49:06 +0200

   Please don't do this in the context of 1.4 releases.  We have the 1.7
   series for experiments like that.  Please keep the 1.4 releases
   (if you feel that you must divert resources to them) as bug fixing
   releases.

who uses libguilereadline independent of using libguile?  who uses
libqthreads independent of using libguile?  moving these things inside
is a bugfix; the user experience is not changed incompatibly.  overall
maintenance is eased.  (all 1.4.x releases aim for this -- sorry, i was
not clear about that goal.)

   On the specific point of what exactly a Guile extension or plugin is,
   where to install it, how to link to it, etc, I remain convinced that
   Guile itself should continue to treat its extensions as standard
   operating system shared libraries, using libtool as the interface to
   the operating system.

of course you do (because you don't take user feedback into account on
this issue perhaps), and because of this, no third party can produce
guile plug-ins cleanly w/o major hassle, and over time fewer and fewer
third parties take the trouble.  big lose.

even more telling is distributors (who have well-articulated criteria
for evaluating how packages can be good neighbors) refusing to upgrade.
mega lose (for end users of apps that may benefit from newer guile
versions had not the newer version been rejected).

   Experimentation can occur outside of Guile.  Packages that need to go
   beyond the simplistic shared library view of the core Guile and want
   to impose additional rules on the use of their shared libraries can do
   so to a very large degree without needing any cooperation from Guile
   itself.

you don't get it.  packages WANT cooperation from guile (otherwise guile
is seen as un-cooperative and a PITA to work with -- duh!).  i can harp
on this more, but because you don't take user feedback into account on
this issue, what's the point?

   Negative.  I don't have the feeling that we are dangerously
   incompatible in the 1.6 series.  What do others think?  It would be
   bad to switch strategies at this point, even if you have a point.

if you can articulate your strategy in the first place, that would be a
good start for discussion.  if you can record this, that would be best.

   What is wrong with Guile's current approach other than that you don't
   like it?

guile has a bunch of people working on it for their own ego fulfillment
(self-included), w/ varying levels of organization and maturity.  this
is not to like or dislike but to understand and work through.

   What?  The split is there so that people can choose not to be
   bothered with developers chit chat.  You don't need a license to
   subscribe to guile-devel.  It's a tool of organization, you process
   junkie, not of dividing and conquering people.

it's a tool of insulation, and fosters this kind of dialogue:

 developer-1: hey, what do you think of BRAINDEAD-IDEA?
 developer-2: THOUGHTLESS-AFFIRMATION.
 user-1: i don't understand.
 developer-1 and developer-2: don't worry, we are the experts;
                              you'll love it, really!

 [6mo later]
 developer-1: well, we have to start over again.
 developer-2: THOUGHTLESS-AFFIRMATION.
 user-2: hey, that breaks my code.
 developer-1 and developer-2: you're a user, go away!

all guile users are programmers; if you can't see how guile developers
have something in common w/ guile users (and structure the dialogue to
be beneficial to everyone by exploiting pooled experience), that's not
good process, and doesn't earn respect from process junkies.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Bill Gribble]

On Wed, 2002-05-15 at 18:13, Thien-Thi Nguyen wrote:
> even more telling is distributors (who have well-articulated criteria
> for evaluating how packages can be good neighbors) refusing to upgrade.
> mega lose (for end users of apps that may benefit from newer guile
> versions had not the newer version been rejected).

I guess you're talking about Red Hat sticking with guile-1.3.4.   From
what I've heard, the policy of Red Hat is "no changes in minor version
number of core software without a major version number change of Red
Hat".  Therefore, there is no hope of any 1.4.x release getting into Red
Hat until at least 8.0.   Hopefully, by then there will be a guile-1.6
that is stable and available, and they will skip the 1.4 series
entirely.  

What does this have to do with guile's extension system?  guile-1.4 is
uniformly better than 1.3.4 and I'm fairly sure it wasn't rejected on
merit.  Just version-number policy. 

b.g.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 15 May 2002 19:26:13 -0500

   I guess you're talking about Red Hat sticking with guile-1.3.4.

and personal anecdote (people tell me privately they won't install 1.5.x
because it breaks their apps (which is their primary interest, after all)).
they are afraid to mention this publically because of poor reception of
their concerns in the past.

   What does this have to do with guile's extension system?

it has to do w/ overall lack of feedback loop causing un-neighborly
decisions to be implemented, which triggers other policies (besides
version number check) which cause userbase atrophy.

guile maintainers need to stop acting like the typical insular american
and get in sync w/ the world beat.  (see i try my best to cause userbase
atrophy in creative ways...  :-)

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Per Bothner]

Bill Gribble wrote:
> I guess you're talking about Red Hat sticking with guile-1.3.4.   From
> what I've heard, the policy of Red Hat is "no changes in minor version
> number of core software without a major version number change of Red
> Hat".

Where did you get from?  They added KDE 3.0 for Red Hat 7.3.

They do have a policy of not breaking APIs in minor versions numbers.
Thus they're not switching to gcc 3.x until RH 8.0.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 15 May 2002 22:49:06 +0200
> 
>    Please don't do this in the context of 1.4 releases.  We have the 1.7
>    series for experiments like that.  Please keep the 1.4 releases
>    (if you feel that you must divert resources to them) as bug fixing
>    releases.
> 
> who uses libguilereadline independent of using libguile?  who uses
> libqthreads independent of using libguile?  moving these things inside
> is a bugfix; the user experience is not changed incompatibly.

What is the bug?

The point is not to allow linking to libguilereadline without also
linking to libguile.  We want to support linking to libguilereadline
and to the other extension libraries together with libguile using the
ld linker.

I don't know nearly as much about shared libraries as the libtool guys
do, but I do know that treating them right is far from trivial.  So my
position is that without good reasons we should keep our shared
libraries things as simple as possible and deviate as little from the
usual way of handling shared libraries as possible.

Unix shared libraries are in a flat namespace with versioning, cobbled
together via some environment variables.  I don't like this design
either, but putting our extension libraries into this namespace poses
no problems (that I could see).  We can't use the versioning from
'dynamic-link' yet, and that is a problem, but we should ideally fix
this by making the versioning available to all users of lt_dlopen, not
by working around it via implementing our own versioning on top of the
existing one (by putting shared libraries outside their natural
namespace).

The hack for 1.6 to include the versioning information explicitely in
the filename is such a workaround, and will hopefully be very
temporary.

> overall maintenance is eased.  (all 1.4.x releases aim for this --
> sorry, i was not clear about that goal.)

I don't think we should have an extended 1.4.x series.  If anything,
the fixes should be backported from the HEAD branch.  But I haven't
heard enough convincing arguments for continuing the 1.4.x release
series, yet.

>    On the specific point of what exactly a Guile extension or plugin is,
>    where to install it, how to link to it, etc, I remain convinced that
>    Guile itself should continue to treat its extensions as standard
>    operating system shared libraries, using libtool as the interface to
>    the operating system.
> 
> of course you do (because you don't take user feedback into account on
> this issue perhaps),

I like to think I do.

> and because of this, no third party can produce guile plug-ins
> cleanly w/o major hassle,

The "Guile plug-in" is just a shared library.  Where is the major
hassle in producing it?

>    Experimentation can occur outside of Guile.  Packages that need to go
>    beyond the simplistic shared library view of the core Guile and want
>    to impose additional rules on the use of their shared libraries can do
>    so to a very large degree without needing any cooperation from Guile
>    itself.
> 
> you don't get it.  packages WANT cooperation from guile (otherwise guile
> is seen as un-cooperative and a PITA to work with -- duh!).

Yes, they want cooperation and the are entitled to it, of course.  I
said "experimentation".  Package developers that are dissatisfied with
Guile's approach can try to do better without cooperation from Guile.
Being able to proceed without needing explicit cooperation from Guile
is a feature.  Not needing to proceed on ones own because there
already just the right cooperation from Guile is even better, of
course.

I'm not saying that the last word on the extension/plugin issue has
been said.  The first thing I ask you to is to not engage in private,
isolated experiments in the 1.4.x series.  Maybe I have misunderstood
your intentions.

> i can harp on this more, but because you don't take user feedback
> into account on this issue, what's the point?

As I said, I think I do take feedback into account (from users _and_
developers ;).  That's how I arrived at the position that I'm
currently taking.

>    Negative.  I don't have the feeling that we are dangerously
>    incompatible in the 1.6 series.  What do others think?  It would be
>    bad to switch strategies at this point, even if you have a point.
> 
> if you can articulate your strategy in the first place, that would be a
> good start for discussion.  if you can record this, that would be best.

The strategy that I was talking about is to release 1.6 from the
'stable' branch in th immediate future.  Maybe strategy is the wrong
word for this.

>    What is wrong with Guile's current approach other than that you don't
>    like it?
> 
> guile has a bunch of people working on it for their own ego fulfillment
> (self-included), w/ varying levels of organization and maturity.  this
> is not to like or dislike but to understand and work through.

I meant Guile's specific approach towards the extension/plugin issue.

>    What?  The split is there so that people can choose not to be
>    bothered with developers chit chat.  You don't need a license to
>    subscribe to guile-devel.  It's a tool of organization, you process
>    junkie, not of dividing and conquering people.
> 
> it's a tool of insulation, and fosters this kind of dialogue:
> 
>  developer-1: hey, what do you think of BRAINDEAD-IDEA?
>  developer-2: THOUGHTLESS-AFFIRMATION.
>  user-1: i don't understand.
>  developer-1 and developer-2: don't worry, we are the experts;
>                               you'll love it, really!
> 
>  [6mo later]
>  developer-1: well, we have to start over again.
>  developer-2: THOUGHTLESS-AFFIRMATION.
>  user-2: hey, that breaks my code.
>  developer-1 and developer-2: you're a user, go away!

Is that really how things typically are?  And they would stop with
just one mailing list?  I don't think so, on both points.

> all guile users are programmers;

(but not developers of guile itself)

> if you can't see how guile developers have something in common w/
> guile users

Of course they have.  We have two _mailing lists_, not two strictly
divided groups of people.

We must be talking past each other here.

Anyway, you can't really have write privs and be unsubscribed from
guile-devel at the same time.  So even if you protest the existence of
guile-devel, do it by not posting to it instead of ignoring it
completely.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 16 May 2002 23:57:54 +0200

   I don't think we should have an extended 1.4.x series.  If anything,
   the fixes should be backported from the HEAD branch.  But I haven't
   heard enough convincing arguments for continuing the 1.4.x release
   series, yet.

look, i am not here to convince you, only to learn.  what i have learned
is that your decision making process resulted in actions that render the
formerly usable guile unusable (you broke my app).  what i see is that
you don't examine your process carefully enough to see how to prevent
this from happening again (you will break many more apps).

what i wish to do now is let other people carry the conversation, and go
take steps to learning about and fixing guile so that i can go back to
playing w/ my app.  i hope other users gain write privs and can help.
i hope you get well soon.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 16 May 2002 23:57:54 +0200
> 
>    I don't think we should have an extended 1.4.x series.  If anything,
>    the fixes should be backported from the HEAD branch.  But I haven't
>    heard enough convincing arguments for continuing the 1.4.x release
>    series, yet.
> 
> look, i am not here to convince you, only to learn. 

The way I see it, you will have to convince me if you want to continue
working on the GNU hosted Guile project.  Either that, or vote me out
of office.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 22 May 2002 14:37:20 +0200

   The way I see it, you will have to convince me if you want to continue
   working on the GNU hosted Guile project.  Either that, or vote me out
   of office.

ah, veiled threats again.  what Office?  what Badge?  who cares, let's
just exercise the Power to excise the Problem.

no one wants to remove you, mvo, just cure your sickness.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 22 May 2002 14:37:20 +0200
> 
>    The way I see it, you will have to convince me if you want to continue
>    working on the GNU hosted Guile project.  Either that, or vote me out
>    of office.
> 
> ah, veiled threats again.

There is nothing veiled about it, I hope.  From my point of view, you
are behaving in a dangerous way, dangerous to the Guile project.  I'm
not categorically saying that you are wrong, but you are side-stepping
the maintainer too bluntly.

The points you raise are quite important and I _do_ need to get better
at documenting what's in me head.  The dynamic linking issue is not in
its final state.  The bug-fixing 1.4.1 release was right on.  We are
enormously slow in releasing 1.6.  It is good to talk about this and
(by pointing out weaknesses) to encourage people to do better.

While you may be good at identifying problems, you are bad at actually
encouraging people to do better.  What you do looks to me mostly like
standing on the side, accusing people of 'obvious' stupidities and
pumping out philosophical dribble when asked to provide concreteness.

This is not a good way to encourage volunteers.

I can't seem to cut thru to the meat of most of your comments.  I
don't think I ignore users like you say.  I don't think you have a
better grasp of good design than I do.  That can very well be a
problem of mine, and not of yours.  If your message would be really
serious I would expect you to try to present it so that I can
understand it better.  Others would surely see the denseness of mine
and support you.  This does not seem to happen, or maybe I'm blind to
that as well.

The gist is that we two don't seem to communicate effectively, and
don't trust each other.  That is bad and hopefully we can _both_ get
over it.  I have to rely on the judgment of others who is right in our
little dispute.  So, if anyone is listening, please enlighten me.

> no one wants to remove you, mvo, just cure your sickness.

Your medicine does not seem to do me any good, thi.

Please believe me, my main interest is not to stay maintainer of
Guile.  But at the moment, I have that position and I really believe
that in the best interests of the Guile project I can't allow it
that you play your own game.  You can't just decide that you continue
with a 1.4.x series and implement all your favorite things in it
without consensus from the rest of the developers.

At least, that is how I interpret your plan.  You did nothing to
convince otherwise as of yet.

But note also that "your favorite things" might actually be good and
valuable stuff for Guile.  I'm not saying that they are not.


What I would like you to do, is to convince me that you are a
constructive member of our little community, rather than a destructive
one.  For that, please agree not to work on a 1.4.x release series
without my approval (which I will give based on user and developer
feedback), and to subscribe to guile-devel until we have agreed that
guile-devel is counterproductive and should be closed completely.

Please address these two points directly and so that I can understand
whether you will obey or not.

You see, I'm still open to run along with you, thi, when the community
wants me to, but please don't run away on your own and leave everyone
wondering where that little gremlin is heading.


You might think that I act way beyond my competencies here, and that
I'm abusing that little extra power that I have.  That might be the
case, but we two are not the ones to decide this.

> thi

Gesundheit!

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 22 May 2002 22:50:51 +0200

   There is nothing veiled about it, I hope.  From my point of view, you
   are behaving in a dangerous way, dangerous to the Guile project.  I'm
   not categorically saying that you are wrong, but you are side-stepping
   the maintainer too bluntly.

ummm, i'm a maintainer as are all the people w/ write privs.  the only
difference between a maintainer and a user is those write privs.  you
additionally have administrative duties (tending the mailing list, etc),
that you seem to be carrying out quite capably.

these privs imply certain responsibilities.  when you say "little
community", you are basically avoiding the responsibilities to the
larger community, the users.  perhaps you don't know how to be properly
responsible; it's up to you to recognize the extent of that and take
steps to widen your viewpoint.  "i think not" is inadequate, sorry.

   While you may be good at identifying problems, you are bad at actually
   encouraging people to do better.  What you do looks to me mostly like
   standing on the side, accusing people of 'obvious' stupidities and
   pumping out philosophical dribble when asked to provide concreteness.

   This is not a good way to encourage volunteers.

again, "on the side" is not quite correct; you (and all maintainers) are
already standing in the middle of a crowd.  the more you cannot see this
the more you react against when one those crowd members (who might also
have the accidental property of having write privs) shouts loud enough
to penetrate your meditations.

what is the right way to encourage volunteers?  is it right to encourage
the mindset that volunteers must be in some little clique and not listen
to users?  is it right to ask for concreteness and yet not see it?  is
it right to not even provide concreteness yourself?

   I can't seem to cut thru to the meat of most of your comments.  I
   don't think I ignore users like you say.  I don't think you have a
   better grasp of good design than I do.  That can very well be a
   problem of mine, and not of yours.  If your message would be really
   serious I would expect you to try to present it so that I can
   understand it better.  Others would surely see the denseness of mine
   and support you.  This does not seem to happen, or maybe I'm blind to
   that as well.

sometimes it's difficult to see if you aren't motivated to look around.
do you think these mailing lists are the only place you are permitted to
look at?  be careful of logical fallacy: (smoke -> fire) does not mean
(no smoke -> no fire).

   The gist is that we two don't seem to communicate effectively, and
   don't trust each other.  That is bad and hopefully we can _both_ get
   over it.  I have to rely on the judgment of others who is right in our
   little dispute.  So, if anyone is listening, please enlighten me.

when i want to find trust in someone, i look at their actions, and don't
put much weight in their words only.  in this case, i can trust you to
break interfaces w/o consideration for people and programs using those
interfaces (and then maintaining unproductive us-vs-them attitude in the
ensuing outcry (should you choose to inform people), and then turning a
blind eye on your own practice so that the next time this happens the
outcry is muted and you can declare self-righteous victory -- just look
at this thread).

this is exactly the same way i trust usloth, btw.  it's a proprietary
mindset that really goes against the spirit of the GNU project (as well
as generally accepted principles of good software design and delivery).

   Your medicine does not seem to do me any good, thi.

obviously.  everyone is their own doctor.  what is your medicine?

   Please believe me, my main interest is not to stay maintainer of
   Guile.  But at the moment, I have that position and I really believe
   that in the best interests of the Guile project I can't allow it
   that you play your own game.  You can't just decide that you continue
   with a 1.4.x series and implement all your favorite things in it
   without consensus from the rest of the developers.

your premise is wrong (see below).

   At least, that is how I interpret your plan.  You did nothing to
   convince otherwise as of yet.

can you define "compatibility"?  answering that helps you to understand
and classify different changes as compatible or incompatible (or some
mixture).  from this understanding you can convince yourself.

   But note also that "your favorite things" might actually be good and
   valuable stuff for Guile.  I'm not saying that they are not.

   What I would like you to do, is to convince me that you are a
   constructive member of our little community, rather than a destructive
   one.  For that, please agree not to work on a 1.4.x release series
   without my approval (which I will give based on user and developer
   feedback), and to subscribe to guile-devel until we have agreed that
   guile-devel is counterproductive and should be closed completely.

what i would like you to do, is to write down under $workbook what you
consider "our little community" so that it can be logically refuted.
please understand that i don't consider your approval very worthwhile in
the scheme of things, but that may change depending on what you do.

   You might think that I act way beyond my competencies here, and that
   I'm abusing that little extra power that I have.  That might be the
   case, but we two are not the ones to decide this.

dude, it's my opinion that you are frantically grasping at straws in a
very uncool way.  perhaps you're stressed over something.  why not relax
w/ a cool beverage somewhere hot (or vice versa) and write down your
"guile developer guidelines" so that you can interview the next person
you want to extend write privs.  be sure to include "must obey the
Commander's orders", "must not question authority", and the like.  there
is a "rules of the evil overlord" series on the net that might provide a
good template.

or, you can strike out in a predictably juvenile way and raise your
blood pressure.  hopefully your medication compensates for that somehow.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 22 May 2002 22:50:51 +0200
> 
>    There is nothing veiled about it, I hope.  From my point of view, you
>    are behaving in a dangerous way, dangerous to the Guile project.  I'm
>    not categorically saying that you are wrong, but you are side-stepping
>    the maintainer too bluntly.
> 
> ummm, i'm a maintainer as are all the people w/ write privs.

You engage in the act of maintaining software, true, but you are not
one of the official appointed "maintainers" of the Guile project, as
far as I know.  The people who have write privs are not automatically
appointed as "maintainers" in the project-organizational sense of the word.

> these privs imply certain responsibilities.  when you say "little
> community", you are basically avoiding the responsibilities to the
> larger community, the users.

I was including the users, actually.

> perhaps you don't know how to be properly responsible; it's up to
> you to recognize the extent of that and take steps to widen your
> viewpoint.  "i think not" is inadequate, sorry.

I can only say "I think".  I don't have absolute knowledge about
something.  I guess(!) it's only polite not to pretend to have the
ultimate wisdom.

>    While you may be good at identifying problems, you are bad at actually
>    encouraging people to do better.  What you do looks to me mostly like
>    standing on the side, accusing people of 'obvious' stupidities and
>    pumping out philosophical dribble when asked to provide concreteness.
> 
>    This is not a good way to encourage volunteers.
> 
> again, "on the side" is not quite correct; you (and all maintainers) are
> already standing in the middle of a crowd.  the more you cannot see this
> the more you react against when one those crowd members (who might also
> have the accidental property of having write privs) shouts loud enough
> to penetrate your meditations.

I am aware of the crowd, but I am not aware of the shouting.  Guile
has a bad reputation, I know, but I don't see the immediate connection
between this, and my actions.  This is the big problem, I guess.
Maybe there is a connection, but you don't make me see it as well.
You will have to try another way of reaching me.  I'm not trying to
sound superior here, I really do not see the foundation for your
claims.

> what is the right way to encourage volunteers?  is it right to encourage
> the mindset that volunteers must be in some little clique and not listen
> to users?  is it right to ask for concreteness and yet not see it?  is
> it right to not even provide concreteness yourself?

Of course not.  But at least I try to be polite.

> sometimes it's difficult to see if you aren't motivated to look around.
> do you think these mailing lists are the only place you are permitted to
> look at?

Where should I look at in addition?

> when i want to find trust in someone, i look at their actions, and don't
> put much weight in their words only.  in this case, i can trust you to
> break interfaces w/o consideration for people and programs using those
> interfaces

I object to the "without consideration".

>    Your medicine does not seem to do me any good, thi.
> 
> obviously.  everyone is their own doctor.  what is your medicine?

I'm not even sure I'm feeling ill.

>    At least, that is how I interpret your plan.  You did nothing to
>    convince otherwise as of yet.
> 
> can you define "compatibility"?  answering that helps you to understand
> and classify different changes as compatible or incompatible (or some
> mixture).  from this understanding you can convince yourself.

Convince me about what?  About what your plan is?  Whether your plan is
any good?

>    What I would like you to do, is to convince me that you are a
>    constructive member of our little community, rather than a destructive
>    one.  For that, please agree not to work on a 1.4.x release series
>    without my approval (which I will give based on user and developer
>    feedback), and to subscribe to guile-devel until we have agreed that
>    guile-devel is counterproductive and should be closed completely.
> 
> what i would like you to do, is to write down under $workbook what you
> consider "our little community" so that it can be logically refuted.
> please understand that i don't consider your approval very worthwhile in
> the scheme of things, but that may change depending on what you do.

Sigh.

>    You might think that I act way beyond my competencies here, and that
>    I'm abusing that little extra power that I have.  That might be the
>    case, but we two are not the ones to decide this.
> 
> dude, it's my opinion that you are frantically grasping at straws in a
> very uncool way.

I grasp at straws so that I don't need to revoke your write privs.
I'm not feeling good about this, and it does induce doubts into me
whether I'm doing the right thing.  But you do not seem to want to
give me the little signs of willingness to cooperate that I asked of
you.  So I will remove your write privs from the GNU CVS repository.

That is decidedly uncool, yes.

Feel free to start a ruckus about this juvenile behavior.  I'm always
willing to reconsider.

If you have things lying around that you need to commit for
completeness, just let me know.

> perhaps you're stressed over something.

Yeah, I'm stressed over this whole issue.  Other than that, I'm fine.

> why not relax w/ a cool beverage somewhere hot (or vice versa) and
> write down your "guile developer guidelines" so that you can
> interview the next person you want to extend write privs.  be sure
> to include "must obey the Commander's orders", "must not question
> authority", and the like.

For your information, "must obey" is not at all the same as "must not
question authority" in my book.  In the context of this project, I
want everybody to "obey" and everyone is free, even welcome, to
"question authority".  But you need to be successful at questioning
the authority before it allows you to not obey.

> or, you can strike out in a predictably juvenile way and raise your
> blood pressure.  hopefully your medication compensates for that
> somehow.

Ahh, what's nobler than to ruin ones health for the better of the
community.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 23 May 2002 02:23:22 +0200

   you don't make me see it as well

who makes you see anything but you?
who makes you do anything but you?

kirk to enterprise, we have a robot here.
highly intelligent, broken free-will module.
master unknown.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Bill Gribble]

On Wed, 2002-05-22 at 23:59, Thien-Thi Nguyen wrote:
> who makes you see anything but you?
> who makes you do anything but you?
> 
> kirk to enterprise, we have a robot here.
> highly intelligent, broken free-will module.
> master unknown.
> 
> thi

Thien-Thi, is there something going on in your personal life that has
changed from a talented hacker into a poo-flinging zoo monkey, or is
this a conscious decision you have made of your own free will?  

Maybe you had better take a break from Guile for a while if it is
aggravating you so much.  You certainly are making the Guile community
much less enjoyable to be a part of. 

b.g.





_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 23 May 2002 06:37:23 -0500

   Thien-Thi, is there something going on in your personal life that has
   changed from a talented hacker into a poo-flinging zoo monkey, or is
   this a conscious decision you have made of your own free will?  

   Maybe you had better take a break from Guile for a while if it is
   aggravating you so much.  You certainly are making the Guile community
   much less enjoyable to be a part of. 

what is aggravating me is this old machine (w/ flakey SDRAMs) always
segfaulting on eval.c and similarly hairy compilation chores.  also its
monitor has recently absorbed enough dust that it blew up!  now i'm
faced w/ venturing out of 80x34 console mode and using my gf's laptop
(running X + fvwm), which would actually be good for emacs development
and may be good for guile development, too.

i'm actually using screen(1) and still working on the old machine --
pretty comfortable combination.  as a bonus my neighbor's father dumped
on him (and subsequently him on me) an sgi 4d/35 "personal iris" (circa
1991), including a honkin' big monitor.  another platform for emacs and
guile hacking, if i can figure out how to clear the long-forgotten root
password.

evolution of people from poo-flinging zoo monkeys onward is interesting
to observe; many times people forget their roots and don't see how it
shapes their outlook and behavior.  that some people are expressive
enough to commit their ideas to code is just another venue for this
phenomenon.

where does joy fit into the scheme of things except between your sensory
nerves and your limbic system?  what else goes on in that cranium?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> ummm, i'm a maintainer as are all the people w/ write privs.  the only
> difference between a maintainer and a user is those write privs.  [...]

FWIW, just from a user's point of view: I'd like to see Thi continue working
on Guile, but whoever is the release manager (mvo?) has to be kept informed
and cannot be blamed for trying to act in the long-term interest of the
project.

mvo, if you can't see what Thi is doing, please ask small direct questions. 
Try to avoid confrontation where possible (easier said than done, I know).

Thi, if you're doing stuff that you think the release manager isn't going to
grok, explain it properly.  You may wish to maintain guile, but if you're
not explaining, it isn't very helpful for maintaining.  Of course, these
comments are true for all contributors.

My Opinion Only.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> FWIW, just from a user's point of view: I'd like to see Thi continue working
> on Guile,

Me too, actually, and everybody I talked to agree that Thi is doing
good work.

> but whoever is the release manager (mvo?) has to be kept informed
> and cannot be blamed for trying to act in the long-term interest of the
> project.

The setup right now is that Ron Browning is the release manager for
1.6, and I'm the appointed maintainer of Guile.

Rob (and me) do not only have to be informed (which we are), but also
need to approve.  That was the main point: Thi did not make it
sufficiently clear to me that he will accept this.

> mvo, if you can't see what Thi is doing, please ask small direct
> questions.

IMO I did that, and I think it's a good suggestion nevertheless.

> Try to avoid confrontation where possible (easier said than done, I
> know).

Normally, I avoid confrontation by ignoring people (and hope that
drives them a little mad), but I don't think that avoiding
confrontation is always the best idea.  I do not enjoy it, of
course...

> My Opinion Only.

Very much valued.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

> Rob (and me) do not only have to be informed (which we are), but also
> need to approve.  That was the main point: Thi did not make it
> sufficiently clear to me that he will accept this.

Aiouauou.  Needs to approve what?  If this is about leaving 1.4 for
stability and performance improvements only, then I think that's right and
proper (I hate APIs changing, even subtly, during a stable series).  If it's
a desire to approve every commit, that's insane.

> > mvo, if you can't see what Thi is doing, please ask small direct
> > questions.
> IMO I did that, and I think it's a good suggestion nevertheless.
> > Try to avoid confrontation where possible (easier said than done, I
> > know).
> Normally, I avoid confrontation by ignoring people (and hope that
> drives them a little mad), but I don't think that avoiding
> confrontation is always the best idea.  I do not enjoy it, of
> course...

Those two were intended to be taken together: try to avoid confrontation
while asking the small direct questions.  Sorry for being unclear.
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> > Rob (and me) do not only have to be informed (which we are), but also
> > need to approve.  That was the main point: Thi did not make it
> > sufficiently clear to me that he will accept this.
> 
> Aiouauou.  Needs to approve what?  If this is about leaving 1.4 for
> stability and performance improvements only, then I think that's
> right and proper (I hate APIs changing, even subtly, during a stable
> series).  If it's a desire to approve every commit, that's insane.

It is not about every single commit per se, but about every single
'work item' that is carried out in the stable branch.  We are at the
point (within the stable branch), where the permitted work items are
pretty small, like fixing a bug that has an obvious and simple fix or
workaround.  So (for the stable branch), Rob needs to approve almost
every single commit.

In the unstable branch, pretty much everything is possible.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 27 May 2002 22:26:06 +0200

   It is not about every single commit per se, but about every single
   'work item' that is carried out in the stable branch.  We are at the
   point (within the stable branch), where the permitted work items are
   pretty small, like fixing a bug that has an obvious and simple fix or
   workaround.  So (for the stable branch), Rob needs to approve almost
   every single commit.

   In the unstable branch, pretty much everything is possible.

what does this have to do w/ "Guile 1.4.2" (see TODO).  it looks like
you've got that confused w/ something else.

next on the plate under that top-level TODO item is to write a proposal
given the recent research into libltdl capabilities and the plug-in arch
survey, hardly so dangerous a task as to require yanking write privs.
maybe you ought to figure out what you're trying to defend here; it
isn't stability or progress.  what are you afraid of?  someone wanting
1.4.x more than 1.6.x?

in any case, good news: libltdl has been stable for two years and there
are usages of lt_dlsetsearchpath in GNU software that we can consult for
guidance.  additionally, lt_* supports user loading discipline, so that
abstraction level is already there; no need to reinvent anything.  mutex
support built-in makes things very nice.  my opinion of libltdl has gone
up dramatically after reading its info pages and doing some mailing list
archive digging.  we are at best under-utilizing it presently.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 27 May 2002 22:26:06 +0200
> 
>    It is not about every single commit per se, but about every single
>    'work item' that is carried out in the stable branch.  We are at the
>    point (within the stable branch), where the permitted work items are
>    pretty small, like fixing a bug that has an obvious and simple fix or
>    workaround.  So (for the stable branch), Rob needs to approve almost
>    every single commit.
> 
>    In the unstable branch, pretty much everything is possible.
> 
> what does this have to do w/ "Guile 1.4.2" (see TODO).  it looks like
> you've got that confused w/ something else.

The text you quote is not about 1.4.2, but the general statement (that
I need not only be informed but also need to approve) is valid also
for the question whether there will be a 1.4.2.

> next on the plate under that top-level TODO item is to write a proposal
> given the recent research into libltdl capabilities and the plug-in arch
> survey, hardly so dangerous a task as to require yanking write privs.

I asked you to agree that we will first get consensus about whether
there will be a 1.4.2.  You did not do that, so I had to conclude that
you will not accept that I need to approve before you can work on a
1.4.2 release.  I think I have made the rules very simple and made it
easy for you to do the things that I want you to do.

Although I am currently of the opinion that we should not have a 1.4.x
release series, I am not saying that I can't be convinced or
out-numbered.

> in any case, good news: libltdl has been stable for two years and there
> are usages of lt_dlsetsearchpath in GNU software that we can consult for
> guidance.

Let me just mention again that the shared libraries are not only
loaded via lt_dlopen, but also by ld.so and ld.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 29 May 2002 20:56:27 +0200

   the question whether there will be a 1.4.2.

there will be a 1.4.2 if someone does the work; the question is whether
or not it will be "official".  that's where your blockage comes into
play, and where only you can teach yourself how to get along w/ those
who do the work.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> there will be a 1.4.2 if someone does the work; the question is whether
> or not it will be "official".  that's where your blockage comes into
> play, and where only you can teach yourself how to get along w/ those
> who do the work.

I'm not blocking 1.4.2 at the moment, I'm blocking you.  If you get
people to tell me that they want a 1.4.x series with the things in it
that you propose, I will probably let you do the work in the savannah
repo.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 29 May 2002 21:46:55 +0200

   I'm not blocking 1.4.2 at the moment, I'm blocking you.  If you get
   people to tell me that they want a 1.4.x series with the things in it
   that you propose, I will probably let you do the work in the savannah
   repo.

no, you block yourself, at the expense of your growth.

i don't have a desire to get people to tell you things.  i'm not
interested in controlling them.  life is too short for that.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 29 May 2002 21:46:55 +0200
> 
>    I'm not blocking 1.4.2 at the moment, I'm blocking you.  If you get
>    people to tell me that they want a 1.4.x series with the things in it
>    that you propose, I will probably let you do the work in the savannah
>    repo.
> 
> no, you block yourself, at the expense of your growth.

Whatever.

> i don't have a desire to get people to tell you things.  i'm not
> interested in controlling them.  life is too short for that.

Sorry, I wanted to say that you might want to find people who support
your idea of a 1.4.x series.  Whether they do this because you have
convinced them, or because you have bribed them, I don't care.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 30 May 2002 14:16:12 +0200

   you might want to find people who support
   your idea of a 1.4.x series.

i found one user and a capable (though still somewhat ignorant)
programmer -- there might be others.  now i just have to find the time
to structure productive engagement of these aligned interests.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Christopher Cramer]

On Wed, May 29, 2002 at 12:17:31PM -0700, Thien-Thi Nguyen wrote:
>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 29 May 2002 20:56:27 +0200
> 
>    the question whether there will be a 1.4.2.
> 
> there will be a 1.4.2 if someone does the work; the question is whether
> or not it will be "official".

Why do we need a 1.4.2? Why would anyone do the work for a 1.4.2?

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
On résiste à l'invasion des armées; on ne résiste pas à l'invasion
des idées.  -- Victor Hugo

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Christopher Cramer <crayc@pyro.net>
   Date: Wed, 29 May 2002 21:28:46 -0500

   Why do we need a 1.4.2? Why would anyone do the work for a 1.4.2?

users define their own need, so this can't be answered generally.
it's a very good question, though.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> there will be a 1.4.2 if someone does the work; the question is whether

Sorry thi, maybe I've missed something: why don't you want to work on adding
new things for the next stable branch instead of an old one?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Tue, 04 Jun 2002 22:58:00 GMT

   why don't you want to work on adding new things for the next stable
   branch instead of an old one?

whether or not it is "stable" is debatable.  more important to me, the
next branch breaks code that i use or maintain, and the trend continues
in HEAD.  i don't want to further contribute to a trend that makes more
work for me (and any other guile fashion victims) than necessary.

too, the guile admin can't seem to write down a sane policy or roadmap,
nor be able to apply whatever ad-hoc policy secreted from his limbic
system consistently, which (to any process junkie sick of petty tyrants)
indicates rough road ahead for those that play in that mud hole.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

ttn:
> whether or not it is "stable" is debatable.

It is anointed "stable" by the release manager, so no major new work should
go into it.  Believe me, nothing angers developers as much as large changes
during a stable series.

> more important to me, the next branch breaks code that i use or maintain,

What code, was reasoning given and have you tried to get the breakage
backed out?  If it's "irreconcilable differences" over the project's future,
maybe there is no choice but to fork.  Sad, but it happens.

> too, the guile admin can't seem to write down a sane policy or roadmap,
> nor be able to apply whatever ad-hoc policy secreted from his limbic
> system consistently, which (to any process junkie sick of petty tyrants)
> indicates rough road ahead for those that play in that mud hole.

Is the person the process?

Seriously, is there A Plan for Guile?
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Wed, 05 Jun 2002 09:22:51 +0100

   Is the person the process?

is typing words into emacs "programming"?

   Seriously, is there A Plan for Guile?

that's a good question.  for me, the plan is to do what i posted
upstream on this thread and mostly embodied by current 1.4.2 TODO items,
and then use that.  (patches against branch_release-1-4 will be provided
on glug.org.)  further 1.4.x will factor some of the features (posix,
net_db, etc), and back-port desirable bits from other branches and HEAD.

currently, libguilereadline has been made to install under $pkglibdir
and i'm looking at libqthreads (which is "relatively losing" according
to Tom Tromey, i note).  lt_dl{set,get}searchpath are wrapped and work
(via experimental convenience procs) to load libguilereadline both in
pre-inst-guile and installed cases.  there is a new test case for this.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> that's a good question.  for me, the plan is to do what i posted
> upstream on this thread and mostly embodied by current 1.4.2 TODO items,

Who wrote that bit of workbook/tasks/TODO?  It looks like you alone from
ViewCVS diffs.  Some committers are writing empty log messages, though :-(

Do you really want to be backporting forever?  And one more time: have you
tried to argue against the "breakages" as you see them in the current HEAD?
I didn't see anything obvious in recent guile-devel messages, but maybe this
is an old discussion.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Wed, 05 Jun 2002 22:59:37 GMT

   Who wrote that bit of workbook/tasks/TODO?  It looks like you alone from
   ViewCVS diffs.  Some committers are writing empty log messages, though :-(

you answer your own question and make a good observation on the practice
of those w/ write privs.

   Do you really want to be backporting forever?

when did i express that?

   And one more time: have you tried to argue against the "breakages" as
   you see them in the current HEAD?

   I didn't see anything obvious in recent guile-devel messages, but
   maybe this is an old discussion.

again you answer your own question.  you don't need me around this
discussion anymore.  ;->

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Wed, 05 Jun 2002 22:59:37 GMT

   Some committers are writing empty log messages, though :-(

fyi, cvs annotate command (`C-x v g' in emacs) shows specifics when the
log is insufficient.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

ttn:
>    Who wrote that bit of workbook/tasks/TODO? [...]
> you answer your own question [...]

So when did you get agreement on the contentious changes going into 1.4.2? 

>    And one more time: have you tried to argue against the "breakages" as
>    you see them in the current HEAD?
> 
>    I didn't see anything obvious in recent guile-devel messages, but
>    maybe this is an old discussion.
> 
> again you answer your own question.  you don't need me around this
> discussion anymore.  ;->

Sorry, I was trying to prompt you into pointing me at the right bits of the
discussion ;-)
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Thu, 06 Jun 2002 00:54:49 +0100

   So when did you get agreement on the contentious changes going into 1.4.2?

agreement w/ whom?  people who don't use 1.4.x?  what's the point of
that?  do you ask taxi drivers for agreement on your destination?  (yes
if you don't know the city, no if you do.)

   Sorry, I was trying to prompt you into pointing me at the right bits
   of the discussion ;-)

are you sure you wouldn't better served by google or whatnot?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Bill Gribble]

On Wed, 2002-06-05 at 19:23, Thien-Thi Nguyen wrote:
> are you sure you wouldn't better served by google or whatnot?

Are you sure you wouldn't be better served by Python or whatnot?

b.g.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 05 Jun 2002 21:44:44 -0500

   Are you sure you wouldn't be better served by Python or whatnot?

to be comfortable programming python i would need to find or write
python-forward-sexp (for hideshow).  maybe that's done already.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 05 Jun 2002 21:44:44 -0500

   Are you sure you wouldn't be better served by Python or whatnot?

if python can fulfill Guile 1.4.x goals (see ROADMAP), that would be
fine, but i doubt that will happen any time soon.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

>    So when did you get agreement on the contentious changes going into 1.4.2?
> agreement w/ whom?  people who don't use 1.4.x?  what's the point of
> that?  do you ask taxi drivers for agreement on your destination?  (yes
> if you don't know the city, no if you do.)

Agreement with anyone would be nice to see, but really I meant the
releasers.  Are they just "taxi drivers" to you, or are they stewards
responsible for Guile?

> are you sure you wouldn't better served by google or whatnot?

Google has not your particular domain knowledge.  Is there anything, or is
your continued dislike of 1.6.x a surprise to the releasers?
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Thu, 06 Jun 2002 10:24:32 +0100

   Agreement with anyone would be nice to see, but really I meant the
   releasers.  Are they just "taxi drivers" to you, or are they stewards
   responsible for Guile?

they are stewards responsible for something, hopefully their own growth.
if that something produces a guile that doesn't break old code, that's
welcome relief to this releaser of guile-1.4.1.  otherwise, learning to
drive a taxi is no big deal, really (not the same as Pizza Deliverator,
but one can dream...).

(responsibility for others must begin w/ responsibility for oneself.  if
the latter is blocked, it is difficult to find the way for the former.)

   Google has not your particular domain knowledge.  Is there anything,
   or is your continued dislike of 1.6.x a surprise to the releasers?

why do you ask me things about other people's mental state?  why do you
limit your questions to either-or constructs?  what are your plans to
improve guile?  what are your plans to improve yourself using guile?
what feedback can you give me on the 1.4.x portion of the ROADMAP?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> why do you ask me things about other people's mental state?

Perhaps because you show little inclination to disclose details of your own.

> why do you limit your questions to either-or constructs?

OK, then:

- How did you agree 1.4.2 with other developers, especially mvo?
- How did you inform them of your plans for the 1.4.x line?
- How did you inform them of the problems you find with 1.6?
- What alternatives have been offered to the 1.6 problem changes (by
anyone)?  If none, have you tried to encourage development of alternatives
and what has resulted from that?

[Of course, archive refs for any of the above would rock.]

If you care about Guile (and you seem to), helping to cause fixes for any
problems with 1.6 is particularly important.

> what are your plans to improve guile?  what are your plans to improve
> yourself using guile?

Write more things using it.  I need to look at guile-www more, particularly,
to see what things from my libraries can be added sensibly to it.  In
general, I think my contribution can be to scheme in general rather than to
one implementation.  Guile is important to me now mainly because guile and
guile-gtk has a large-ish installation base.

> what feedback can you give me on the 1.4.x portion of the ROADMAP?

Grouping a few:

Abstracting -- should that really be done in a stable series?

Integrate docs, determine/document policy -- fine

Compatibility header -- huh?

Back-ports -- perhaps, but only if 1.6 is too far away

Add/incorporate/support -- not during a stable series, do these for 1.6

Fix bugs -- of course

My opinion only, but you did ask.

MJR


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Fri, 07 Jun 2002 23:25:22 GMT

   Perhaps because you show little inclination to disclose details of your own.

well i've been told i spew both too much and too little.  tough crowd!

   - How did you agree 1.4.2 with other developers, especially mvo?

in the previous message you'll note i called into question the value of
agreement w/ someone who is not interested (who outright abandoned 1.4
to be precise).  can you explain why agreement in such a circumstance is
important to you?

   - How did you inform them of your plans for the 1.4.x line?
   - How did you inform them of the problems you find with 1.6?
   - What alternatives have been offered to the 1.6 problem changes (by
   anyone)?  If none, have you tried to encourage development of alternatives
   and what has resulted from that?

   [Of course, archive refs for any of the above would rock.]

why do you ask me to do this research for you?  i have other things to
learn today (e.g., studying Dirk Herrmann's threads internal interface
separation to take it to its logical conclusion (load a libguileqthreads
at runtime)) besides how ineffectively verbose i've been.

   If you care about Guile (and you seem to), helping to cause fixes for
   any problems with 1.6 is particularly important.

when you say "particularly" it implies "as opposed to alternatives" and
thus some prioritization scheme comes into play.  in your estimate what
would make something particularly UNimportant to work on?  could you
describe your personal prioritization scheme (as it relates to guile /
in general)?

   Write more things using it.

guile lovers use guile...

   I need to look at guile-www more, particularly, to see what things
   from my libraries can be added sensibly to it.

people have asked for ssl support.

   [ROADMAP feedback]

   My opinion only, but you did ask.

yes, opinions are easy to share w/ others (less so code, less so
process, less so power).  i'm glad to see you recognizing them as such.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Fri, 07 Jun 2002 23:25:22 GMT

   Abstracting -- should that really be done in a stable series?

to answer this, first see $workbook/build/stability.text, choose some
attributes (or make up your own), and characterize this "abstracting"
change in those terms.  consider other changes that might have similar
term sets and how you feel about them.  tell everyone how you render
your decision if so inclined -- you be the judge!

   Compatibility header -- huh?

i don't understand this question.

   Back-ports -- perhaps, but only if 1.6 is too far away

how far away is it?  how far is too far?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[rm]

On Fri, Jun 07, 2002 at 11:25:22PM +0000, MJ Ray wrote:
> [...] 
> 
> Compatibility header -- huh?

Probably refering to a suggestion i made a while ago: porting
an existing application to newer versions of guile will be a rather
large task - there are a lot of API changes (for some more than one
would expect in a minor version change ...). Live of application 
developers could be considerably made easier with a header file 
that provides cpp macros that fake vanished functions/types.

I do see the beauty and neccessity of consistently named types and
functions, but from my own experience i know that having to wade through
my code  replacing renamed symbols when i'd rather be hunting for the
'real' changes can get rather frustrating. A compatibility header would
lessen the pain:

#define scm_sizet size_t 

 Ralf Mattes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Marius Vollmer]

rm@fabula.de writes:

> I do see the beauty and neccessity of consistently named types and
> functions, but from my own experience i know that having to wade through
> my code  replacing renamed symbols when i'd rather be hunting for the
> 'real' changes can get rather frustrating. A compatibility header would
> lessen the pain:
> 
> #define scm_sizet size_t 

We do have this already (but maybe not totally consequently):

    $ grep -C scm_sizet *.h
    __scm.h-
    __scm.h-#if (SCM_DEBUG_DEPRECATED == 0)
    __scm.h:# define scm_sizet size_t
    __scm.h-#endif
    __scm.h-

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

>    - How did you agree 1.4.2 with other developers, especially mvo?
> in the previous message you'll note i called into question the value of
> agreement w/ someone who is not interested (who outright abandoned 1.4
> to be precise).  can you explain why agreement in such a circumstance is
> important to you?

The buck always stops somewhere and for guile, it looks like it stops with
mvo right now.  Moving the development focus away from 1.4 may have been
done for good reasons: if it is not critically buggy and there is pressure
to actually develop new features, then it is better to start towards 1.6
than try to introduce major changes during a stable series.

[...]
> why do you ask me to do this research for you?  

Because you were involved and my casual research found no matches.  This
makes me think that those things never happened in public, but you have
better information to start a search from (your memories of the events). 
Even just giving dates, possible subject lines, other participant names,
etc, would help to locate them.

[...]
> when you say "particularly" it implies "as opposed to alternatives" and
> thus some prioritization scheme comes into play.  

Language lawyer.  :P

> in your estimate what would make something particularly UNimportant to
> work on?

Stuff that breaks non-bug compatibility during a stable series is
particularly unimportant because such things should not be introduced during
a stable series.

> could you describe your personal prioritization scheme (as it relates to
> guile / in general)?

"Heuristic."

>    I need to look at guile-www more, particularly, to see what things
>    from my libraries can be added sensibly to it.
> people have asked for ssl support.

That's not in this bag, sadly.  Unfortunately, I can't find guile-www to
look and compare right now.  I suspect xexprxml and fasttemplate to be two
of the more likely unique parts of my collection.

> yes, opinions are easy to share w/ others (less so code, less so
> process, less so power).  i'm glad to see you recognizing them as such.

The danger is when opinions are left unstated and used as the motivation for
divisive actions.
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Sat, 08 Jun 2002 23:45:13 +0100

   The buck always stops somewhere and for guile, it looks like it stops
   with mvo right now.

uh oh, my management buzzword bingo sheet is starting to fill up.  how
would you distinguish between the buck stopping and the buck sailing off
into the void?

   Moving the development focus away from 1.4 may have been done for
   good reasons: if it is not critically buggy and there is pressure to
   actually develop new features, then it is better to start towards 1.6
   than try to introduce major changes during a stable series.

what is the development focus?  what are the reasons for moving it?  hey
these questions are starting to sail off -- let's see where they stop...

   Because you were involved and my casual research found no matches.  This
   makes me think that those things never happened in public, but you have
   better information to start a search from (your memories of the events). 
   Even just giving dates, possible subject lines, other participant names,
   etc, would help to locate them.

if a tree falls in the forest and your seismograph is broken or too far
away to detect it, would you ask the tree to fall again?  why would the
tree want to do that?  take a library-sciences course if you want to
improve your research skillz...

   Language lawyer.  :P

   > yes, opinions are easy to share w/ others (less so code, less so
   > process, less so power).  i'm glad to see you recognizing them as such.

   The danger is when opinions are left unstated and used as the
   motivation for divisive actions.

is there a way to safeguard against this danger?

   Stuff that breaks non-bug compatibility during a stable series is
   particularly unimportant because such things should not be introduced
   during a stable series.

how do you judge compatibility (w/o using the word "compatible")?

   > could you describe your personal prioritization scheme (as it
   > relates to guile / in general)?

   "Heuristic."

that's a given.  what kind of heuristic?

(hey, if you pass this interview, i'll nominate you for guile
maintainer! ;-)

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> if a tree falls in the forest and your seismograph is broken or too far
> away to detect it, would you ask the tree to fall again?

No, I'd find someone who was there.  You're the only person in this case who
I can be sure was there, but you don't want to provide data.  Therefore,
there is little possibility to gather data on this event and we are left
working from prior beliefs.  My prior belief is that the events probably did
not occur.  Am I a good Bayesian?  Probably not.

> why would the tree want to do that?  take a library-sciences course if you
> want to improve your research skillz...

There's a reply to that, but it's not polite.

> is there a way to safeguard against this danger?

State the opinions before acting upon them, but I can't find that that has
occurred.

>    Stuff that breaks non-bug compatibility during a stable series is
>    particularly unimportant because such things should not be introduced
>    during a stable series.
> how do you judge compatibility (w/o using the word "compatible")?

Do interfaces change?  ie, Do returns change for the same calls?  Are new
calls introduced?  Are calls removed?

>    > could you describe your personal prioritization scheme (as it
>    > relates to guile / in general)?
>    "Heuristic."
> that's a given.  what kind of heuristic?

A genetic algorithm, most likely ;-)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> if a tree falls in the forest and your seismograph is broken or too far
> away to detect it, would you ask the tree to fall again?

No, I'd find someone who was there.  You're the only person in this case who
I can be sure was there, but you don't want to provide data.  Therefore,
there is little possibility to gather data on this event and we are left
working from prior beliefs.  My prior belief is that the events probably did
not occur.  Am I a good Bayesian?  Probably not.

> why would the tree want to do that?  take a library-sciences course if you
> want to improve your research skillz...

There's a reply to that, but it's not polite.

> is there a way to safeguard against this danger?

State the opinions before acting upon them, but I can't find that that has
occurred.

>    Stuff that breaks non-bug compatibility during a stable series is
>    particularly unimportant because such things should not be introduced
>    during a stable series.
> how do you judge compatibility (w/o using the word "compatible")?

Do interfaces change?  ie, Do returns change for the same calls?  Are new
calls introduced?  Are calls removed?

>    > could you describe your personal prioritization scheme (as it
>    > relates to guile / in general)?
>    "Heuristic."
> that's a given.  what kind of heuristic?

A genetic algorithm, most likely ;-)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Mon, 10 Jun 2002 12:31:31 GMT

   No, I'd find someone who was there.  You're the only person in this
   case who I can be sure was there, but you don't want to provide data.

if you are looking for public data look in public archives, which do not
need to be provided by me -- they are there for review.

   Therefore, there is little possibility to gather data on this event
   and we are left working from prior beliefs.  My prior belief is that
   the events probably did not occur.  Am I a good Bayesian?  Probably
   not.

"there is little possibility" means "i have asked someone else to think
for me but they don't want to so i'm giving up".  too bad.

the possibility for you to reach some well-informed conclusion is always
there, but the probability is directly proportional to your personal
effort.  the alternative is that you hold to "i didn't see FOO so FOO
didn't happen" which means you don't believe in your own birth (unless
you were born w/ your eyes open :-).

   There's a reply to that, but it's not polite.

someday you'll be old and impatient like me and view certain forms of
politeness w/ disdain, but i understand if that's not the case now.
librarians have even more fun than pizza deliverators, i suspect (on the
other hand, shared-object librarians have a hell of a job :-).

   State the opinions before acting upon them, but I can't find that
   that has occurred.

people have opinions, but programmers have opinions expressed in code.

so before we get to far, this course of action that you have embarked
upon (researching 1.4.2 motivations), what is your underlying opinion?

   Do interfaces change?  ie, Do returns change for the same calls?  Are
   new calls introduced?  Are calls removed?

good questions -- so now you've posited some system of judgement, could
you apply this to code, specifically the tuples {guile, some-app} over
the set of versions available?  if you prefer to avoid the abstract,
choose some actual app that you find interesting or useful (that uses
guile).

   A genetic algorithm, most likely ;-)

what is the fitness function?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[MJ Ray]

ttn:
> if you are looking for public data look in public archives, which do not
> need to be provided by me -- they are there for review.

Arrogant swine.  I've already done that and it seems that I have
insufficient data to specify a search that locates the required information,
so I was asking you for further data (in this case some date range, or some
subject snippet perhaps) to try.  I can find lots of interesting things
about 1.4.x and 1.6, but not what I seek.

> the possibility for you to reach some well-informed conclusion is always
> there, but the probability is directly proportional to your personal
> effort.

Hardly.  This simplistic view ignores that there is another probability
involved in the search, so it is not necessarily directly proportional. 
Maybe your degree didn't include enough probability theory?

> the alternative is that you hold to "i didn't see FOO so FOO didn't
> happen" which means you don't believe in your own birth (unless you were
> born w/ your eyes open :-).

Again, this is an incorrect analogy.  I have reasonable evidence that my
birth occurred and that births are the normal way for new people to enter
this world, so the prior belief is quite different.

> someday you'll be old and impatient like me [...]

You are not *that* much older than I am, if you are who I think you are. 
You do seem to be considerably more impatient, though.

Then again, maybe not:
[snip!]
-- 
MJR

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Tue, 11 Jun 2002 00:30:40 +0100

   I can find lots of interesting things about 1.4.x and 1.6, but not
   what I seek.

perhaps what you seek can be found if sought in a different way.

   Hardly.  This simplistic view ignores that there is another probability
   involved in the search, so it is not necessarily directly proportional. 

you control the introduction of terms by controlling the search method.
choose a method that doesn't have undesirable terms and you won't have
to worry about them.

   [...] so the prior belief is quite different.

what is your prior belief for this search here?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Robert Uhl <ruhl@4dv.net>]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> 
> perhaps what you seek can be found if sought in a different way.

Do you think you're a flipping Magic Eight Ball?  Look, someone has
asked for references to discussions regarding your decision to fork
guile.  That decision may have been the correct one; you may have had
excellent reasons for doing so.  But your lack of co-operation biases
folks against you.  You are acting irrationally and
self-destructively.  Why not help those who might help you?

-- 
Robert Uhl <ruhl@4dv.net>
Christ is Risen!  Truly He is Risen!

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>)
   Date: 11 Jun 2002 11:50:58 -0600

   Do you think you're a flipping Magic Eight Ball?

"future uncertain".

   someone has asked for references to discussions regarding your
   decision ...

this is clear.

   ... to fork guile.

this is not clear.

   lack of co-operation biases folks against you.

that's clear also.

   Why not help those who might help you?

i try to help everyone think independently and to practice sufficient
reflection so that they can hone their thought process (down to code,
preferably).  sometimes this helps me directly but most of the time it
helps me indirectly.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[news]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> I've already done that and it seems that I have
> insufficient data to specify a search that locates the required information,
> so I was asking you for further data (in this case some date range, or some
> subject snippet perhaps) to try.  I can find lots of interesting things
> about 1.4.x and 1.6, but not what I seek.

I'm  not sure  what  you're looking  for.

You can generate your own data points, as I did, by downloading
some of tnn's scheme:

  http://www.glug.org/people/ttn/software/

and seeing how it runs under recent releases of guile.

Guile's recent versions seem to break the guile programs he uses
for maintenance and development.  That's almost like perl
development gratuitously breaking the scripts that run CPAN, the
perl code archive.

I can also point you to some discussions which would lead one to
understand tnn's motivation to continue developing along the
1.4.x branch.  Here are some links to the guile archives:

_bound? changes noticed in release candidate 1.5.6 beta_:

  http://mail.gnu.org/pipermail/guile-user/2002-March/002741.html

_invitation by ttn to discuss definition of stability and release
conditions_:

  http://mail.gnu.org/pipermail/guile-user/2002-March/002752.html

_invitation by ttn to a design and roadmap review ( you participated
in the thread )_:

  http://mail.gnu.org/pipermail/guile-user/2002-April/002822.html

_interface summary and comment_:

  http://mail.gnu.org/pipermail/guile-user/2002-April/002837.html

_Questions about guile's roadmap_:

  http://mail.gnu.org/pipermail/guile-user/2002-April/002888.html

_guile 1.6.1 release discussion_:

  http://mail.gnu.org/pipermail/guile-user/2002-April/002918.html

_guile roadmap request_:

  http://mail.gnu.org/pipermail/guile-devel/2002-April/005140.html

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Forking stables. was Re: language translator help

[MJ Ray]

(Chris Beggy ) news@kippona.com <news@kippona.com> wrote:
> _guile 1.6.1 release discussion_:
> 
>   http://mail.gnu.org/pipermail/guile-user/2002-April/002918.html

Thanks for this one -- it's closest to what I was looking for, but I seem to
have ignored that discussion.  I had no idea it was so recent.  From what
ttn was saying, I was thinking it was something dating from some point in
the 1.5 series, so I'd been looking much further back.

I note with amusement that ttn is doing something he grumbled about in
http://mail.gnu.org/pipermail/guile-user/2002-April/002927.html by answering
"obliquely at best".

To answer your comment at
http://mail.gnu.org/pipermail/guile-user/2002-April/002933.html

I think that stable series releases should not break *any* programs unless
they rely on a clearly buggy behaviour.  Upgrading between stable series
may.  Isn't that the normal definition of stable series?

MJR


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Rob Browning]

MJ Ray <markj@cloaked.freeserve.co.uk> writes:

> I think that stable series releases should not break *any* programs
> unless they rely on a clearly buggy behaviour.  Upgrading between
> stable series may.  Isn't that the normal definition of stable
> series?

It's the one I'm used to.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Wed, 12 Jun 2002 17:44:43 GMT

   I think that stable series releases should not break *any* programs
   unless they rely on a clearly buggy behaviour.  Upgrading between
   stable series may.

if this is the premise, you can think of each "stable series" as a high
mountain w/ rickety rope bridges crossing the chasms between them.  in
that case don't you think it would be a good idea to grow your crops on
each, rather than asking people to risk life and limb for every meal?

sure, you may be a god and have ability to transport yourself through
the air w/ greatest of ease (and consort w/ similar beings who see
nothing of jumping a thousand leagues for breakfast).  that's not the
question.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Clinton Ebadi]

On Friday 14 June 2002 15:32, Thien-Thi Nguyen wrote:
>    From: MJ Ray <markj@cloaked.freeserve.co.uk>
>    Date: Wed, 12 Jun 2002 17:44:43 GMT
> 
>    I think that stable series releases should not break *any* programs
>    unless they rely on a clearly buggy behaviour.  Upgrading between
>    stable series may.
>
> if this is the premise, you can think of each "stable series" as a high
> mountain w/ rickety rope bridges crossing the chasms between them.  in
> that case don't you think it would be a good idea to grow your crops on
> each, rather than asking people to risk life and limb for every meal?
>
> sure, you may be a god and have ability to transport yourself through
> the air w/ greatest of ease (and consort w/ similar beings who see
> nothing of jumping a thousand leagues for breakfast).  that's not the
> question.
>
> thi

How hard is it to rewrite code from 1.4 to 1.6? It wasn't too hard with 
glame...I mean, all of gh is still there except for the the lazy modules 
registering stuff (but then you have scm_c_define_module, you just have to 
make sure to scm_c_export everything). This is no reason to fork. Get over 
it, spend a few hours updating your code, and move on with life. Wow, that 
was easy.

-- 
http://unknownlamer.org
Facts do not cease to exist because they are ignored.
                -- Aldous Huxley
Flag Burner.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Thien-Thi Nguyen]

   From: Clinton Ebadi <unknown_lamer@unknownlamer.org>
   Date: Fri, 14 Jun 2002 16:08:12 -0400

   How hard is it to rewrite code from 1.4 to 1.6?

how do you handle code you can't rewrite?

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Clinton Ebadi]

On Friday 14 June 2002 16:21, Thien-Thi Nguyen wrote:
>    From: Clinton Ebadi <unknown_lamer@unknownlamer.org>
>    Date: Fri, 14 Jun 2002 16:08:12 -0400
>
>    How hard is it to rewrite code from 1.4 to 1.6?
>
> how do you handle code you can't rewrite?
>
> thi


The reverse engineer and write your own version of the program. It would just 
be another example of proprietary software be left behind. Proprietary 
software is bad anyway, and no one should care about people that use or write 
proprietary software.

-- 
http://unknownlamer.org
Facts do not cease to exist because they are ignored.
                -- Aldous Huxley
Flag Burner.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Robert Uhl <ruhl@4dv.net>]

Clinton Ebadi <unknown_lamer@unknownlamer.org> writes:
>
> It would just be another example of proprietary software be left
> behind.

Agreed there.  That's the chance one takes with proprietary software.

> Proprietary software is bad anyway, and no one should care about
> people that use or write proprietary software.

I wouldn't go that far, or phrase it that way.  There are sometimes
reasons to use proprietary software.  But I'd not go out of my way to
accomodate it over-much.

-- 
Robert Uhl <ruhl@4dv.net>
Fatum Iustum Stultorum--The Just Fate of Fools/The Just Fate of the Foolish

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[news]

Clinton Ebadi <unknown_lamer@unknownlamer.org> writes:

> The reverse engineer and write your own version of the program. It would just 
> be another example of proprietary software be left behind. Proprietary 
> software is bad anyway, and no one should care about people that use or write 
> proprietary software.

Guy Steele, a computer programming language designer, delivered
a talk titled "Growing a Language."  It's available here:

  http://www.research.avayalabs.com/user/wadler/steele-oopsla98.pdf 

See what he has to say about:

  1. language versioning 
  2. compatibility between versions
  3. interface stability

Chris


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Neil Jerram]

>>>>> "Chris" == Chris Beggy <news@kippona.com> writes:

    Chris> Guy Steele, a computer programming language designer,
    Chris> delivered a talk titled "Growing a Language."  It's
    Chris> available here:

Guy Steele???  Who he?

    Chris>   http://www.research.avayalabs.com/user/wadler/steele-oopsla98.pdf 

    Chris> See what he has to say about:

    Chris>   1. language versioning 
    Chris>   2. compatibility between versions
    Chris>   3. interface stability

Er... not a lot.  It's a great article, but I noticed nothing in
particular on these subjects.  Rather, it's all about designing a
language so that the community can help grow it, and in particular
about why he thinks that Java needs overloaded operators.

(Oh, perhaps that was your point ...?)

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Clinton Ebadi]

On Monday 17 June 2002 18:37, Neil Jerram wrote:
> >>>>> "Chris" == Chris Beggy <news@kippona.com> writes:
>
>     Chris> Guy Steele, a computer programming language designer,
>     Chris> delivered a talk titled "Growing a Language."  It's
>     Chris> available here:
>
> Guy Steele???  Who he?

Ever heard of a little language called Common-Lisp...

-- 
http://unknownlamer.org
Facts do not cease to exist because they are ignored.
                -- Aldous Huxley
Flag Burner.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Clinton Ebadi]

On Monday 17 June 2002 19:06, Clinton Ebadi wrote:
> On Monday 17 June 2002 18:37, Neil Jerram wrote:
> > >>>>> "Chris" == Chris Beggy <news@kippona.com> writes:
> >
> >     Chris> Guy Steele, a computer programming language designer,
> >     Chris> delivered a talk titled "Growing a Language."  It's
> >     Chris> available here:
> >
> > Guy Steele???  Who he?
>
> Ever heard of a little language called Common-Lisp...

Ack..I also forgot to mention the lambda papers...(hint: Guile implements the 
other language he worked on and that was defined in the lambda papers) :).

-- 
http://unknownlamer.org
Facts do not cease to exist because they are ignored.
                -- Aldous Huxley
Flag Burner.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Bill Gribble]

On Mon, 2002-06-17 at 17:37, Neil Jerram wrote:
> Er... not a lot.  It's a great article, but I noticed nothing in
> particular on these subjects.  Rather, it's all about designing a
> language so that the community can help grow it, and in particular
> about why he thinks that Java needs overloaded operators.

Java *does* need overloaded operators... 

if it's got even half a chance of overtaking c++ as the most bletcherous
abortion of a half-specified "oops, um, well actually what we REALLY
meant was" of a language ever. 

ba dump <ching> 

b.g.

who just today got a very hearty belly laugh out of this: there's no way
to determine at compile time or run time if a particular g++-compiled
library was compiled with either RTTI or exception support, so you can't
actually distribute *any* program that depends on 3rd party c++
libraries and expect it to work unless it's statically linked and
includes the complete source to all 3rd party libs in its own source
tree, so it can make sure they get built with the same RTTI/exception
conventions... but of course templates' "generic programming" model
makes shared libraries, um, "obsolete" anyway...







> 
> (Oh, perhaps that was your point ...?)
> 
>         Neil
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[news]

Neil Jerram <neil@ossau.uklinux.net> writes:

>     Chris> See what he has to say about:
>
>     Chris>   1. language versioning 
>     Chris>   2. compatibility between versions
>     Chris>   3. interface stability
>
> Er... not a lot.  It's a great article, but I noticed nothing in
> particular on these subjects.  Rather, it's all about designing a
> language so that the community can help grow it, and in particular
> about why he thinks that Java needs overloaded operators.
>
> (Oh, perhaps that was your point ...?)

Right :-) Thanks for reading and commenting.

Steele doesn't talk about these because they are already decided
issues, whose treatment is widespread in engineering and design
cultures that I've seen.

For lots of language/system designers (and users too), there's
nothing interesting about language versioning, compatibility
between versions, and interface stability:

   1. A language release with a new version number is an improvement.  
   2. There is backward compatibility to old versions in the new system
   3. Interfaces are stable.  

Deviations from any of these features are compensated by
emulation modes, compiler, interpreter, or usage warnings; or a
rename of the language or system.  Progress is difficult without
these features.

This is my roundabout way of saying that stability, backward
compatibility, and emulation are ways to continue using code you
can't modify. That's an answer to ttn's (rhetorical?) question.

These features ensure the ability to reuse and learn from working
code someone, like ttn, has offered to share as well.  The
surprising difficulty to do that is my complaint about guile.

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Thien-Thi Nguyen]

   From: (Chris Beggy ) news@kippona.com
   Date: Tue, 18 Jun 2002 14:40:57 -0400

   This is my roundabout way of saying that stability, backward
   compatibility, and emulation are ways to continue using code you
   can't modify. That's an answer to ttn's (rhetorical?) question.

thanks (the question was not rhetorical).  lots of new and even some old
programmers don't see things this way; perhaps they'll learn over time.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Forking stables. was Re: language translator help

[Thien-Thi Nguyen]

   From: Clinton Ebadi <unknown_lamer@unknownlamer.org>
   Date: Fri, 14 Jun 2002 17:03:26 -0400

   The reverse engineer and write your own version of the program. It
   would just be another example of proprietary software be left
   behind. Proprietary software is bad anyway, and no one should care
   about people that use or write proprietary software.

there is important proprietary software we use every time a packet goes
through a router.  we should care for those programmers even though they
may not be immediately in support of free software, for our own good,
and maintain communication.  ignorance is strength only in a society of
slaves.

it is the proprietary software mindset that is to be exposed for its
impoverishing nature rather than the people who (perhaps w/ incomplete
understanding) traffic in it.  people can change their minds.

this is the underlying principle of the guile license, btw.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile 1.4.1.86 (snap) available

[MJ Ray]

>>   How does this relate to greg and/or SchemeUnit?  Not at all?
> see comments in (ice-9 testing-lib).

Which branch of the guile CVS is that in?  I'm having trouble finding it.
-- 
MJR


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile 1.4.1.86 (snap) available

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Sun, 08 Sep 2002 19:48:36 +0100

   Which branch of the guile CVS is that in?  I'm having trouble finding it.

sorry, can't help you w/ this trouble.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Neil Jerram]

>>>>> "thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    thi>    From: Neil Jerram <neil@ossau.uklinux.net>
    thi>    Date: 28 Apr 2002 19:21:49 +0100

    thi>    What tools are now available for writing parsers in Scheme?  Last time
    thi>    we had this conversation on the list, ISTR that there were many ideas
    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.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 18 May 2002 14:47:24 +0100

   BTW, is there any reason not to sync guile-lang-allover back up with
   the guile-rgx-ctax module?

not in this case.  the changes are mostly documentation (adding README),
style adaptations (using parens for module names instead of something
#/like/this), and similar packaging.[1]

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

this is why there is TODO item "write $w/modules/compiled-modules.text".
it's easy to avoid consensus through m.l. rehash.  w/ something written
down, the design and its decisions can be thoroughly vetted (which helps
build consensus).  for lt_* bindings availability, the way to judge that
is to ask if lt_* interface is stable.

       thi> 1.4.2 also back-ports :select and :renamer [...],
       thi> [...] first module built suchly will be guile-doc-snarf

   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?

i don't know how to answer this.  what is hindsight to some is foresight
to others.  project development train-wreck is easy to predict for the
switch-yard controller but perhaps not for the passenger, conductor or
engineer.  it all depends on your relationship w/ the train(s) and of
course experience.

   In other words, do you think a similarly planned model could apply to
   bleeding edge development?

this is another question entirely!

bleeding edge doesn't usually tolerate planning but for bleeding edge to
stop bleeding, its fruits must be served w/ the wine of planning, else
the meal is unpalatable.  what makes a good wine?

what this means is that if you are project manager at war against time
the enemy, you form both a forward flank and a rear guard, and structure
communication between these groups to be subject to moderation by the
generals back at HQ.  what makes a good general?

   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.

it is my way of retiring to the rear guard, where at least one principle
is clear (maintain compatibility).  i don't expect forward flank to value
these efforts.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Thien-Thi Nguyen]

[1] here's a simple script (modify dir to taste) to compare components:

    rm guile-rgx-ctax
    ln -s /home/ttn/build/GNU/guile/guile-rgx-ctax

    for f in *.[hc] ; do
        echo -n $f '...'
        diff $f guile-rgx-ctax/rx/$f | wc -l
    done

    for f in lang/*.scm ; do
        echo -n $f '...'
        diff $f guile-rgx-ctax/$f | wc -l
    done

    for f in lang/ctax/*.scm ; do
        echo -n $f '...'
        g=`echo $f | sed 's/^.....//g'`
        diff $f guile-rgx-ctax/$g | wc -l
    done

    rm guile-rgx-ctax

output below.  looks like there are some non-trivial changes in
lang/*.scm and lang/ctax/*.scm.  perhaps guile-lang-allover Author can
comment.

thi


___________________________________________
cd /home/ttn/local/src/.ttn/build/guile-lang-allover-0.1/
sh .ttn.compare
_rx.h ...      0
hashrexp.c ...      0
inst-rxposix.h ...      0
rgx.c ...     36
rgx.h ...      4
runtests.c ...      0
rx.c ...      0
rx.h ...      0
rxall.h ...      0
rxanal.c ...      0
rxanal.h ...      0
rxbasic.c ...      0
rxbasic.h ...      0
rxbitset.c ...      0
rxbitset.h ...      0
rxcontext.h ...      0
rxcset.c ...      0
rxcset.h ...      0
rxdbug.c ...      0
rxgnucomp.c ...      0
rxgnucomp.h ...      0
rxhash.c ...      0
rxhash.h ...      0
rxnfa.c ...      0
rxnfa.h ...      0
rxnode.c ...      0
rxnode.h ...      0
rxposix.c ...      0
rxposix.h ...      0
rxproto.h ...      0
rxsimp.c ...      0
rxsimp.h ...      0
rxspencer.c ...      0
rxspencer.h ...      0
rxstr.c ...      0
rxstr.h ...      0
rxsuper.c ...      0
rxsuper.h ...      0
rxunfa.c ...      0
rxunfa.h ...      0
testcases.h ...      0
lang/grammar.scm ...      4
lang/lex.scm ...     14
lang/lr0.scm ...    101
lang/lr1.scm ...    102
lang/pp.scm ...      0
lang/ctax/c-ops.scm ...      4
lang/ctax/grammar.scm ...      4
lang/ctax/hashtabs.scm ...      4
lang/ctax/lexer.scm ...     36
lang/ctax/macros.scm ...      4
lang/ctax/reader.scm ...     12
lang/ctax/scm-ops.scm ...      4

Compilation finished at Sat May 18 19:56:26

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Per Bothner]

John W. Eaton wrote:
> Well, I'm not sure.  But it is a lot of work to write an maintain an
> interperter for a special language, and much of that effort is
> duplicated by every scripting language.  People using Octave and Guile
> both want access to OS system calls and library functions (from basic
> stuff to GUI toolkits) so it seems wasteful to me that we build many
> interfaces to all these different libraries.  I think it would be much
> better to take advantage of existing work that's already been done.

Well, to toot my own horn:  The Kawa systems is not only a featureful
Scheme implementation that translates Scheme to Java bytecodes, it is
also a framework for compiling other languages into Java bytecodes.
Other languages handled by Kawa in addition to Scheme include a
non-trivial chunk of Emacs Lisp (see http://JEmacs.sourceforge.net/),
a smaller sub-set of Common Lisp, the  XQuery language for XML data
(see http://www.gnu.org/software/kawa/xquery/), and the Beautiful Report
Language (http://brl.sourceforge/net/).

All of these use the Java Virtual Machine as the interpreter.  E.g.
JEmacs uses Java bytecode where normal Emacs uses Emacs bytecodes.
However, Jawa translates one-the-fly and quickly to bytecodes.

See http://www.gnu.org/software/kawa/ and
http://www.gnu.org/software/kawa/internals.html.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: language translator help

[Neil Jerram]

>>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:

    John> On 27-Apr-2002, Neil Jerram <neil@ossau.uklinux.net> wrote:
    John> | If Elisp is a guide [...]

    John> I think it performance might be better in most cases because Octave's
    John> interpreter is known to be really slow for many operations.

OK, let's hope so.

    John> | - You have to believe that implementing your language constructs in
    John> |   Scheme is easier to maintain than implementing them in C.

    John> Well, I'm not sure.  But it is a lot of work to write an maintain an
    John> interperter for a special language, and much of that effort is
    John> duplicated by every scripting language.  People using Octave and Guile
    John> both want access to OS system calls and library functions (from basic
    John> stuff to GUI toolkits) so it seems wasteful to me that we build many
    John> interfaces to all these different libraries.  I think it would be much
    John> better to take advantage of existing work that's already been done.

Agreed - there is duplication that can be removed, and it will be cool
to have, e.g., a gnuplot interface available in Guile in general.

But I think the point about Scheme vs. C is still important.  If your
language has a `for' construct, you have to implement it somehow,
unless you are lucky enough that the target language already has an
identical construct.  IMO, Scheme is easier for this than C in
individual cases (e.g. compare unwind-protect in CVS
guile-core/lang/elisp/primitives/syntax.scm and in the Emacs source
eval.c).  And, where there is a pattern in the way that a group of
constructs maps from your language to the target, Scheme has more ways
than C of allowing you to express that pattern in your construct
definitions.

    John> | [...] might end up wanting to
    John> |   keep it in C anyway (but switch to using Guile data types).

    John> Along with a way to call Guile functions, this would offer a lot, but
    John> I would still like to get away from having to maintain the low-level
    John> details of an interpreter.

Agreed.  The low-level details I can think of that Guile could handle
for you are:

- memory allocation and GC

- evaluation, function and macro dispatching

- having to have a representation for the code that you have read in

- bignums, if Guile's bignum meet Octave's existing needs

- other basic data types like numbers and strings

- arrays, if you think that Guile's uniform array implementation is
  suitable.

Any others?

    John> | Right, but this is just a matter of wrapping existing code, isn't it?

    John> Yes and no.  There is the opportunity to correct some of the mistakes
    John> of the past too, which might mean more than just wrapping the current
    John> Octave classes.

OK.

    John> |     John> [...] having the translator is essential.
    John> | 
    John> | Totally agree; this is what Guile is supposed to be about: providing
    John> | language flexibility to its users.

    John> Yes, but there seem to be no fully functional examples of actually
    John> doing this yet.  If that's correct, why not?  What's keeping people
    John> from doing this?

    John> One problem that I can imagine is that for languages like Perl, or
    John> Python, which are starting to be quite large, it's not enough to just
    John> translate the syntax to scheme, you need the run-time.  Integrating
    John> all of that could be a lot of work.  But I think that a bigger problem
    John> is that there is no standard for these languages, so the language
    John> definition is whatever the real Perl or Python interpreters do today.
    John> Unless the authors of those tools integrate the Guile interpreter in
    John> their own code, the fork becomes difficult to maintain.

    John> These sorts of problems would not cause trouble for Octave, because I
    John> would be integrating Guile completely.  I'm just trying to understand
    John> what might be the reasons that we don't have many translators.

This is my analysis too.  In the Elisp case, FWIW, it's certainly true
that you need the runtime to have a useful system, and that the best
way to get (most of) it is to build the Emacs source in a modified
form.  This is what Ken Raeburn's Guile-based Emacs project is doing.

Therefore, it's a codebase management issue (or, equivalently, a
not-wanting-to-fork issue).  Tracking a separately managed project is
already very hard even if your aim is only to copy its syntax and
semantics.  When you want to reuse a lot of that project's source code
as well, but in a modified form, but also stay in sync as new releases
come out, it gets harder.  Cf. Ken's project, which was put back some
way by Emacs 21 coming out.

Ideally, serious political will is needed on the part of the project
that you are trying to track.  (Note that this does not exist in the
Emacs case, AFAIK.)  Barring that, I imagine it helps if the target is
standardized or changing very slowly.

My guess is that writing a good translator without full Guile
integration may prove impossible.  But perhaps Thomas Bushnell's
Python will provide a counter-example - I hope so.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

loop translations (was: Re: language translator help)

[John W. Eaton]

On 27-Apr-2002, Neil Jerram <neil@ossau.uklinux.net> wrote:

| I'm not aware of such a document.  Suggest you post the translation
| code that you've tried already.  I'll certainly take a look, and I
| guess you'll get a deluge of suggestions from others as well.

OK, here goes.

I'd like to understand how to translate some simple loops.  For
example, the following loop is valid in Octave.

  for i = 1:3
    disp (i);
    if (i == 2)
      break;
    endif
  endfor

This should print

  1
  2

Note that this sequence of statements doesn't return any value.  For
Guile, the best I've come up with is

  (let for ((i 1))
    (call-with-current-continuation
     (lambda (break)
       (if (<= i 5)
           (begin
             (display i)
             (newline)
             (if (= i 2)
                 (break (if #f #f)))
             (for (+ 1 i)))))))

This works, but seems quite complex to me.  Is there a simpler way?

Here is another:

  for i = 1:4
    if (i < 4)
      disp ("foo-i-hithere");
      if (i == 2)
	continue;
      endif
    endif
    disp (i);
  endfor

This should print

  foo-i-hithere
  1
  foo-i-hithere
  foo-i-hithere
  3
  4

For Guile, I came up with

  (let for ((i 1))
    (call-with-current-continuation
     (lambda (continue)
       (if (<= i 4)
           (begin
             (if (< i 4)
                 (begin
                   (display "foo-i-hithere")
                   (newline)
                   (if (= i 2)
                       (continue (for (+ 1 i))))))
             (display i)
             (newline)
             (for (+ 1 i)))))))

Again, this works but is there a better way?  It seems undesirable to
duplicate the (for (+ 1 i)) bit.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Thien-Thi Nguyen]

   From: "John W. Eaton" <jwe@bevo.che.wisc.edu>
   Date: Sat, 27 Apr 2002 19:53:33 -0500

     for i = 1:3
       disp (i);
       if (i == 2)
	 break;
       endif
     endfor

you could use `do' for this:

(do ((keep-going? #t)
     (i 1 (1+ i)))
    ((or (not keep-going?) (= i 3)))	; maybe (> i 3) ?
  (format #t "~A\n" i)
  (and (= i 2) (set! keep-going? #f)))

i suppose this would offend some purists, but it works...

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[David Pirotte]

I would do this:

1. defining a 'do' whatever module, mine has the following 2 defs;

;; this is my 'do.scm' file, in 'alto' directory accessible
;; which means a subdirectory of the ones listed in GUILE_LOAD_PATH

(define-module (alto do))

(export dotimes
	dolist)

(use-modules (ice-9 syncase))

(define-syntax dolist
  (syntax-rules ()
    ((dolist (?var ?ls) . ?body)
     (for-each (lambda (?var) . ?body) ?ls))
    ((dolist (?var ?ls ?result) . ?body)
     (begin (for-each (lambda (?var) . ?body) ?ls)
            ?result))))

(define-syntax dotimes
  (syntax-rules ()
    ((dotimes (?var ?count . ?result) . ?body)
     (let ((limit ?count))
       (do ((?var 0 (+ ?var 1)))
           ((>= ?var limit) . ?result)
         . ?body)))))

;; end of file

now it is 'very' simple, as simple as:

(use-modules (alto do))

(dotimes (i 3)
  ;; here comes what ever and how many sexp you wanado ...
  (display i) (display "\n")
  )

hope this helps
david


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[rm]

On Sun, Apr 28, 2002 at 01:06:52AM -0400, David Pirotte wrote:
If you are looking for common lisp like loop constructs,
Rick Taube has written a set of macros. I've wrapped them as a guile
module, send me mail if you need them (orig. code is GPL).

Ralf Mattes

> I would do this:
> 
> 1. defining a 'do' whatever module, mine has the following 2 defs;
> 
> ;; this is my 'do.scm' file, in 'alto' directory accessible
> ;; which means a subdirectory of the ones listed in GUILE_LOAD_PATH
> 
> (define-module (alto do))
> 
> (export dotimes
> 	dolist)
> 
> (use-modules (ice-9 syncase))
> 
> (define-syntax dolist
>   (syntax-rules ()
>     ((dolist (?var ?ls) . ?body)
>      (for-each (lambda (?var) . ?body) ?ls))
>     ((dolist (?var ?ls ?result) . ?body)
>      (begin (for-each (lambda (?var) . ?body) ?ls)
>             ?result))))
> 
> (define-syntax dotimes
>   (syntax-rules ()
>     ((dotimes (?var ?count . ?result) . ?body)
>      (let ((limit ?count))
>        (do ((?var 0 (+ ?var 1)))
>            ((>= ?var limit) . ?result)
>          . ?body)))))
> 
> ;; end of file
> 
> now it is 'very' simple, as simple as:
> 
> (use-modules (alto do))
> 
> (dotimes (i 3)
>   ;; here comes what ever and how many sexp you wanado ...
>   (display i) (display "\n")
>   )
> 
> hope this helps
> david
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> I'd like to understand how to translate some simple loops.

Spot on.  I think loops with break and continue are the most confusing
point for people who aren't yet deep into Scheme.

Your approach is essentially right.  Let me try to formalize it a bit
with some macros:

    ;;;; How to loop, with break and continue.

    ;;; 'with-exit' lets you break out of a computation.

    (define-macro (with-exit sym . body)
      `(call-with-current-continuation (lambda (,sym) ,@body)))

    ;;; 'while'.  BODY can call a function named 'break' to exit the loop,
    ;;; and a function 'continue' to skip to the next iteration.  You
    ;;; don't have to call 'break' or 'continue' in a tail context.

    (define-macro (while test . body)
      (let ((loop-sym (gensym "loop")))
        `(with-exit break
           (let ,loop-sym ()
             (cond
              (,test
               (with-exit continue
                 ,@body)
               (,loop-sym)))))))

    ;;; 'for', like 'while'.  Also, each iteration gets a fresh binding
    ;;; for the iteration variable.

    ;; range is (var start stop)

    (define-macro (for range . body)
      (let ((var (car range))
            (start (cadr range))
            (stop (caddr range))
            (loop-sym (gensym "loop")))
        `(with-exit break
           (let ,loop-sym ((,var ,start))
             (cond
              ((< ,var ,stop)
               (with-exit continue
                 ,@body)
               (,loop-sym (1+ ,var))))))))

When you compare this with your code, you see that I put the
'continue' exit point immediately around the body, excluding the test.
The effect is that a call to 'continue' will skip the rest of the body
and call the loop function again the normal way.  Your way of
implementing 'continue' does work, but in a weird way: it first
executes the rest of the loop (by calling 'for' in the argument to
'continue') and then exits the loop by behaving like a 'break'.  The
functions created by '(let loop ...)' are totally ordinary functions
and calling them in a non-tail context will 'push stack' and they will
eventually return to the caller.  Thus, as you noticed, calling the
loop function does not behave like 'continue' in other languages.  If
you want to, you can use named let for things other than loops, for
example for tree walking.

The immediate problem with your way of implementing 'continue' is that
loops that use it do no longer run in constant space.

The problem with the macros above is that they are not hygienic, and
call/cc is quite inefficient in Guile.  Making them hygienic should
not be a problem, but avoiding call/cc is not so easy and is hopefully
not really necessary.  One could generate continuation-passing code
and hope that Guile will execute it more efficiently than the
occasional call/cc, or one could implement a cheaper version of
call/cc that is not as powerful but is sufficient for 'with-exit'.  I
think we should do the latter, if performance of call/cc turns out to
be too bad.

> For example, the following loop is valid in Octave.
> 
>   for i = 1:3
>     disp (i);
>     if (i == 2)
>       break;
>     endif
>   endfor

This would be, using the macros from above

    (for (i 1 4)
      (display i) (newline)
      (if (= i 2)
          (break)))

Or without:

    (with-exit break
     (let for ((i 1))
       (cond
        ((< i 4)
         (with-exit continue
           (display i) (newline)
             (if (= i 2)
             (break)))
         (for (1+ i))))))

> This works, but seems quite complex to me.  Is there a simpler way?

When using some macros, it's not really complex, I'd say.

> Here is another:
> 
>   for i = 1:4
>     if (i < 4)
>       disp ("foo-i-hithere");
>       if (i == 2)
> 	continue;
>       endif
>     endif
>     disp (i);
>   endfor

    (for (i 1 5)
      (if (< i 4)
          (begin
            (display "foo-i-hithere") (newline)
            (if (= i 2)
                (continue))))
      (display i) (newline))

> For Guile, I came up with
> 
>   (let for ((i 1))
>     (call-with-current-continuation
>      (lambda (continue)
>        (if (<= i 4)
>            (begin
>              (if (< i 4)
>                  (begin
>                    (display "foo-i-hithere")
>                    (newline)
>                    (if (= i 2)
>                        (continue (for (+ 1 i))))))
                                   ^^^^^^^^^^^^^

This is where you recursively call the loop function 'for' and wait
for it to return.  This uses stack space.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[John W. Eaton]

On 28-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
|
| Your approach is essentially right.  Let me try to formalize it a bit
| with some macros:

Thanks.  With the macros, the loops are much more readable to me, but
there is still the (apparent, at least to a Scheme novice) complexity
of call/cc.

| The functions created by '(let loop ...)' are totally ordinary functions
| and calling them in a non-tail context will 'push stack' and they will
| eventually return to the caller.

OK, I thought that might be the case.  But I didn't see the way to use
call/cc to jump to the end of the loop and keep going.

| The problem with the macros above is that they are not hygienic,

Sorry, I'm not sure I understand what that means.

| avoiding call/cc is not so easy and is hopefully
| not really necessary.  One could generate continuation-passing code
| and hope that Guile will execute it more efficiently than the
| occasional call/cc,

What is continuation passing?

| or one could implement a cheaper version of
| call/cc that is not as powerful but is sufficient for 'with-exit'.  I
| think we should do the latter, if performance of call/cc turns out to
| be too bad.

It's important to me that looping not be any slower than it already is
in Octave.  It might be possible to scan loops for break/continue
statements and generate simpler loops when they are not present, but
I'd really rather avoid that if possible.  It would be much better if
break and continue statements did not generate a large performance
penalty.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> On 28-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:
> 
> | "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
> |
> | Your approach is essentially right.  Let me try to formalize it a bit
> | with some macros:
> 
> Thanks.  With the macros, the loops are much more readable to me, but
> there is still the (apparent, at least to a Scheme novice) complexity
> of call/cc.

Yes, but I think it is properly encapsulated with 'with-exit'.

> | The problem with the macros above is that they are not hygienic,
> 
> Sorry, I'm not sure I understand what that means.

They can shadow identifiers from the user.  Code like

    (let ((continue #t))
      (while continue
        (set! continue #f)))

wont work since the 'continue' identifier inside the while does not
refer to the one introduced by the let.  A good solution would be to
make the continue feature optional and let the user choose the name of
the function.  Much like 'with-exit', where the name of the exiting
function is determined by the user, not the macro.

> | avoiding call/cc is not so easy and is hopefully
> | not really necessary.  One could generate continuation-passing code
> | and hope that Guile will execute it more efficiently than the
> | occasional call/cc,
> 
> What is continuation passing?

Start here:

    http://www.scheme.com/tspl2d/further.html#g1849

> It's important to me that looping not be any slower than it already is
> in Octave.

I'd say you should first do the simple thing (using call/cc) and later
worry about performance.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> A good solution would be to make the continue feature optional and
> let the user choose the name of the function.  Much like
> 'with-exit', where the name of the exiting function is determined by
> the user, not the macro.

And, of course, to use (ice-9 syncase) instead of define-macro.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Clinton Ebadi]

On Sunday 28 April 2002 14:48, Marius Vollmer wrote:
> Marius Vollmer <mvo@zagadka.ping.de> writes:
> > A good solution would be to make the continue feature optional and
> > let the user choose the name of the function.  Much like
> > 'with-exit', where the name of the exiting function is determined by
> > the user, not the macro.
>
> And, of course, to use (ice-9 syncase) instead of define-macro.

Which brings me to my problem...I tried to redefine the for macro as a 
syncase macro (so I could add (break) and (continue) inside of the macro, 
which wasn't working with define-macro)...and I have a problem:

(define-syntax for 
  (syntax-rules ()
    ((for (var start end) ....)
     (catch 'break
       (lambda ()
	 (let loop ((var start))
	   (catch 'continue
	     (lambda ()
	       (cond ((<= var end)
		      ...
		      (throw 'continue))))
	     (lambda ignored
	       (loop (+ var 1))))))
       (lambda ignored
	 (if #f #f #f))))))

(well, I had one problem before that--with-mutex wasn't defined, and yes, I 
did remember the --with-threads and I do have threading support, but I had to 
add :use-module (ice-9 threads) to syncase.scm to work with Guile 1.7...maybe 
this is a bug that others will experience?).

But when I try to load for.scm, I get this error:
ERROR: missing ellipsis in syntax form (syntax (catch (quote break) (lambda 
() (let loop ((var start)) (catch (quote continue) (lambda () (cond ((<= var 
end) ... (throw (quote continue))))) (lambda ignored (loop (+ var 1)))))) 
(lambda ignored (if #f #f #f))))
ABORT: (misc-error)

So, what are the rules for using ... exactly ? If I remove the parens around 
(var start end), it almost works, instead I get:

guile> (load "for.scm")
guile> (for i 1 10 (display i))
1
Backtrace:
In current input:
   3: 0* (for i 1 10 (display i))
   3: 1  [catch break #<procedure #f ()> #<procedure #f syntmp-ignored-18>]
   ?: 2* [#<procedure #f ()>]
   ?: 3* [syntmp-loop-15 1]
   ?: 4  [catch continue #<procedure #f ()> #<procedure #f syntmp-ignored-17>]
   ?: 5* [#<procedure #f ()>]
   ?: 6* (cond ((<= syntmp-i-16 #) (<= syntmp-i-16 #) (throw #)))
   ?: 7* [<= 1 #<unspecified>]

<unnamed port>: In procedure <= in expression (<= syntmp-i-16 (display 
syntmp-i-16)):
<unnamed port>: Wrong type argument in position 2: #<unspecified>
ABORT: (wrong-type-arg)
guile> 

so it works for the first time, but then fails...the lack of documentation 
about "new" macros doesn't help me either :-)

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: loop translations (was: Re: language translator help)

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Clinton Ebadi <unknown_lamer@unknownlamer.org> writes:


[...]

> Which brings me to my problem...I tried to redefine the for macro as a 
> syncase macro (so I could add (break) and (continue) inside of the macro, 
> which wasn't working with define-macro)...and I have a problem:

[...]

> So, what are the rules for using ... exactly ? If I remove the parens around 
> (var start end), it almost works, instead I get:

Basically there needs to be a plain identifier before them, that needs
to appear before the corresponding ... in the replacement.  Rather
than thinking of the pattern think of the pattern <something> ... 

you want something more like:

(define-syntax for 
  (syntax-rules ()
    ((for (var start end) body ...)
     (catch 'break
       (lambda ()
	 (let loop ((var start))
	   (catch 'continue
	     (lambda ()
	       (cond ((<= var end)
                      body ...
		      (throw 'continue))))
	     (lambda ignored
	       (loop (+ var 1))))))
       (lambda ignored
	 (if #f #f #f))))))


> so it works for the first time, but then fails...the lack of documentation 
> about "new" macros doesn't help me either :-)

The r5rs description is... less than transparant, I'll grant :)

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: loop translations (was: Re: language translator help)

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Eric E Moore <e.e.moore@sheffield.ac.uk> writes:

> Basically there needs to be a plain identifier before them, that needs
> to appear before the corresponding ... in the replacement.  Rather
> than thinking of the pattern think of the pattern <something> ... 

This isn't *quite* right, you can have other things besides a plain
identifier, but there still needs to be something before the ... that
contains pattern variables from the pattern.  So you can do:

(define-syntax append-one
  (syntax-rules ()
    ((append-one (form ...) ...)
     (begin
       (form ... 1) ...))))

Which will append 1 to all the forms in the append-one clause, such that:

(append-one (set! x) (+ x 3))

will expand to:

(begin 
  (set! x 1)
  (+ x 3 1))

and have the value of 6.....

Still, my correction to your code is probably what you want :)

> The r5rs description is... less than transparant, I'll grant :)

This still applies ;)

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: loop translations (was: Re: language translator help)

[Neil Jerram]

>>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:

    John>   (let for ((i 1))
    John>     (call-with-current-continuation
    John>      (lambda (break)
    John>        (if (<= i 5)
    John>            (begin
    John>              (display i)
    John>              (newline)
    John>              (if (= i 2)
    John>                  (break (if #f #f)))
    John>              (for (+ 1 i)))))))

    John> This works, but seems quite complex to me.  Is there a
    John> simpler way?

Depends what you mean by simpler.  There are certainly ways that you
could make it _look_ simpler :-).

For example, if you had a general `for' macro defined like this:

(define-macro (for varspec . body)
  (let ((varsym (car varspec))
        (vari (cadr varspec))
        (varf (caddr varspec)))
    `(catch 'break
       (lambda ()
         (let loop ((,varsym ,vari))
           (catch 'continue
             (lambda ()
               (if (<= ,varsym ,varf)
                   (begin
                     ,@body
                     (throw 'continue))))
             (lambda ignored
               (loop (+ ,varsym 1))))))
       (lambda ignored
         (if #f #f)))))

then the translation for this particular case could look like this:

(for (i 1 4)
  (display i)
  (newline)
  (if (= i 2)
      (throw 'break)))

Note that I've used catch and throw rather than call/cc here.  call/cc
is slow and expensive in Guile; wherever the jump is once-only and
upwards-only, it's more efficient to use catch/throw.

    John> Here is another:

    John>   for i = 1:4
    John>     if (i < 4)
    John>       disp ("foo-i-hithere");
    John>       if (i == 2)
    John> 	continue;
    John>       endif
    John>     endif
    John>     disp (i);
    John>   endfor

(for (i 1 4)
  (if (< i 4)
      (begin
        (display "foo-i-hithere\n")
        (if (= i 2)
            (throw 'continue))))
  (display i)
  (newline))

Does this help?

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

translators and scoping rules (was: Re: language translator help)

[John W. Eaton]

On 27-Apr-2002, Neil Jerram <neil@ossau.uklinux.net> wrote:

| What are the Octave scoping rules?  For dynamic scoping (a la Elisp),
| Guile has the `@bind' macro for setting and restoring such variables'
| values.  In the Elisp case, this allows Elisp variables to be Guile
| variables directly.  (Except that it doesn't cope with buffer-local,
| etc.)

The scoping rules are fairly simple.  Variables are local to functions
unless declared global.  Global variables all share the same common
global namespace.

The eval() function can introduce new local variables.  How would you
do that with Guile?

Something like this

  (define foo
    (lambda ()
      (let ((x 21))
        (eval-string "(define a (* 2 21))")
        (display a)
        (newline))))

works to define a new variable "a", but once foo has been evaluated,
the variable "a" is visible outside the scope of the function:

  guile> a
  ERROR: In expression a:
  ERROR: Unbound variable: a
  ABORT: (unbound-variable)

  Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
  guile> 
  guile> 
  guile> (define foo
  ...      (lambda ()
  ...        (let ((x 21))
  ...          (eval-string "(define a (* 2 21))")
  ...          (display a)
  ...          (newline))))
  guile> 
  guile> (foo)
  42
  guile> a
  42

How would you use eval to introduce a new local variable?

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> How would you use eval to introduce a new local variable?

You can't.  If Octave needs this feature (but why?), you can not use
Scheme's local variables for Octaves local variables.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[John W. Eaton]

On 28-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > How would you use eval to introduce a new local variable?
| 
| You can't.  If Octave needs this feature (but why?),

Good question.  I can't think of a really legitimate use, but it is
possible to do this in Octave/Matlab, so I was wondering whether it
could be emulated directly in Scheme.

| you can not use
| Scheme's local variables for Octaves local variables.

OK.  I'm not sure whether this feature is really necessary, but it
might also turn out to be a mistake to design the translator in way
that makes it impossible.  Even if I don't want to support this
feature in Octave, someone may want to try to create a completely
bug-for-bug Matlab-compatible translator based on the Octave
translator translator.  We should probably not make that unnecessarily
hard to do.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> [defining new local variables via eval.]
>
> OK.  I'm not sure whether this feature is really necessary, but it
> might also turn out to be a mistake to design the translator in way
> that makes it impossible.

Can you statically determine whether a function uses eval in such a
way?  If so, you can generate efficient code for functions that can
not define new locals, and use some horrible scheme for functions that
can.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[John W. Eaton]

On 28-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:

| "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
| 
| > [defining new local variables via eval.]
| >
| > OK.  I'm not sure whether this feature is really necessary, but it
| > might also turn out to be a mistake to design the translator in way
| > that makes it impossible.
| 
| Can you statically determine whether a function uses eval in such a
| way?  If so, you can generate efficient code for functions that can
| not define new locals, and use some horrible scheme for functions that
| can.

I'm not sure.  It would be easy to determine whether a function uses
eval(), but I think it would be harder to decide whether what funny
stuff might be going on with eval since the string to be evaluated can
come from anywhere, including user input.  If I have something like

  function y = foo (some_string)
    eval (some_string);
    y = sin (x);
  endfunction

and SOME_STRING doesn't define a variable X, it is an error anyway,
and we could probably detect that.  OTOH, there is no way to determine
what might happen for

  function foo (string_one, string_two)
    eval (string_one);
    eval (string_two);
  endfunction

since the code in STRING_TWO might depend on what variables were
defined in STRING_ONE.

Does it matter?  I don't know.  I don't think I would ever write a
program that does these kinds of things, but it is allowed by Matlab,
and Octave users like the fact that Octave has until now tried to be
mostly compatible.  Before I do a lot of coding, I'm trying to explore
what can be done easily if I decide to have Octave emit Scheme code
for Guile to interpret.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Marius Vollmer]

"John W. Eaton" <jwe@bevo.che.wisc.edu> writes:

> | Can you statically determine whether a function uses eval in such a
> | way?  If so, you can generate efficient code for functions that can
> | not define new locals, and use some horrible scheme for functions that
> | can.
> 
> I'm not sure.  It would be easy to determine whether a function uses
> eval(), but I think it would be harder to decide whether what funny
> stuff might be going on with eval since the string to be evaluated can
> come from anywhere, including user input.

Yes, just detecting the use of eval would be good enough, then.  It
might catch cases that don't strictly need it, but that's no problem.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Per Bothner]

John W. Eaton wrote:
> On 28-Apr-2002, Marius Vollmer <mvo@zagadka.ping.de> wrote:
> 
> | "John W. Eaton" <jwe@bevo.che.wisc.edu> writes:
> | 
> | > How would you use eval to introduce a new local variable?
> | 
> | You can't.  If Octave needs this feature (but why?),
> 
> Good question.  I can't think of a really legitimate use, but it is
> possible to do this in Octave/Matlab, so I was wondering whether it
> could be emulated directly in Scheme.

Am I right in guesing that Octave uses dynamic scoping, rather than
lexical scoping?  Certainly any local variable introduced by an eval
cannot be lexically scoped.  However, it can be a dynamic or "fluid"
variable.  So it would be consistent if all local variables were
fluid variables.  (Common Lisp uses the term "special" variables.)

In a single-threaded environment it is easy implement dynamic/fluid
variables:  When the variable is defined, you set the variable in
the global environment, but remember its previous value, if even.
When you exit the variable's scope, you restore the previous value.

It is harder to implement fluid variables in a multi-threaded
environment, but there are various ways you can do it.  (Kawa does
support fluid bindings.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[John W. Eaton]

On 28-Apr-2002, Per Bothner <per@bothner.com> wrote:

| Am I right in guesing that Octave uses dynamic scoping, rather than
| lexical scoping?

Are those the only choices?  :-)

The rules are essentially the same as for Fortran.  Variables are
local to functions (subroutines).  The only "global" variables are
declared global (common).  There is no statement like (let ...).
Functions are all in one global scope.  Functions (but not variables)
can be shadowed.  If a function is shadowed by a variable, "clearing"
the variable restores the function.  For example,

  octave:1> which sin
  sin is a builtin function
  octave:2> sin (pi/2)
  ans = 1
  octave:3> sin = 0
  sin = 0
  octave:4> which sin
  sin is a user-defined variable
  octave:5> clear sin
  octave:6> which sin
  sin is a builtin function
  octave:7> sin (pi/2)
  ans = 1

Well, my excuse is that I didn't make this up, I inherited it from
Matlab.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Per Bothner]

John W. Eaton wrote:
> On 28-Apr-2002, Per Bothner <per@bothner.com> wrote:
> 
> | Am I right in guesing that Octave uses dynamic scoping, rather than
> | lexical scoping?
> 
> Are those the only choices?  :-)
> 
> The rules are essentially the same as for Fortran.  Variables are
> local to functions (subroutines).  The only "global" variables are
> declared global (common).

What I was referring to was whether the following is defined,
assuming f(10) is called with no global definition of x:

function f (x)
   f = g()
endfunction

functioon g()
   g = x
endfunction

If this is allowed then you can't use normal Scheme variable functions
for function parameter, even without using eval.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[John W. Eaton]

On 28-Apr-2002, Per Bothner <per@bothner.com> wrote:

| John W. Eaton wrote:
|
| > The rules are essentially the same as for Fortran.  Variables are
| > local to functions (subroutines).  The only "global" variables are
| > declared global (common).
| 
| What I was referring to was whether the following is defined,
| assuming f(10) is called with no global definition of x:
| 
| function f (x)
|    f = g()
| endfunction
| 
| functioon g()
|    g = x
| endfunction

No, this won't work because X is only defined inside F, not G:

  octave2.1:1> function f (x)
  >   f = g()
  > endfunction
  octave2.1:2> function g()
  >   g = x
  > endfunction
  octave2.1:3> f (1)
  error: `x' undefined near line 2 column 7
  error: evaluating assignment expression near line 2, column 5
  error: called from `g'
  error: called from `f'

Also, variables defined at the top level (command line) are in a
separate namespace that is not the same as the global namespace.
Variables in the top-level namespace are not visible to any function.
So, for example, after the definition of G above,

  octave2.1:3> x = 1
  x = 1
  octave2.1:4> g
  error: `x' undefined near line 2 column 7
  error: evaluating assignment expression near line 2, column 5
  error: called from `g'

The only way for this to work without passing X as an argument to G is
to write

  octave2.1:4> global x
  octave2.1:5> x = 1
  x = 1
  octave2.1:6> function g ()
  >   global x
  >   g = x
  > endfunction
  octave2.1:7> g
  g = 1

So, does it make sense that an Octave translator would be able to
store Octave variables as Guile variables, or would they need to be
stored separately in some tables as Thomas Bushnell said he was doing
for Python?  I see no real problems with that approach, but I was
thinking I might be able to avoid it, and just have Guile manage the
variables.  To avoid conflicts, Octave variables would probably
defined inside a module so that they would be in a separate namespace,
but they would still be Guile variables, not data stored in some
separate tables that my translator would have to manage.

jwe

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: translators and scoping rules (was: Re: language translator help)

[Neil Jerram]

>>>>> "John" == John W Eaton <jwe@bevo.che.wisc.edu> writes:

    John> The eval() function can introduce new local variables.  How would you
    John> do that with Guile? [...]

Currently impossible, I believe.

Parts of the solution are there, namely `local-eval' and
`the-environment', and it's easy to see how we could extend `define'
so that it could add a new binding to a `the-environment'-type
environment.  However, `local-eval' and `the-environment' are already
considered a bit tricksy and perhaps-ought-not-to-be-there by some
people.

Can you explain in more application-specific terms what kind of usage
you are aiming to support by this mechanism?  Then we could perhaps
think of a more natural (in Guile terms) way of achieving it.

        Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

guile 1.4.1.86 (snap) available

[Thien-Thi Nguyen]

testing framework now liberated...  woo hoo!  (you can use "guile-tools
run-all-tests" for your own non-guile projects and get the tally for
PASS, FAIL, UPASS, XFAIL, UNTESTED, UNSUPPORTED, UNRESOLVED or ERROR
results.  SKIP is also available but not tallied -- patches welcome.)
tarball in dir:

  http://www.glug.org/tmp/2002-09/

new NEWS excerpt follows.

thi


__________________________________________________
* New module (ice-9 testing-lib)

This is actually the familiar (test-suite lib) module that has been
distributed for a long time, now repackaged for installation and general use.
Similarly, the driver program formerly known as test-suite/guile-test is now
available as one of the guile-tools.  The guile-specific parts of this are
in test-suite/prologue.scm.  After build, do:

    pre-inst-guile-tools run-all-tests --help

for more info.

* (bit-extract N ...) now signals out-of-range error for N < 0

* bug fix: (expt 0 0) => 1

* New configure option: --enable-site-dir=DIR

Normally, configuration sets scheme_site_dir to be ${datadir}/guile/site,
but you can select another directory to use instead.  The site directory
is available to C code as SCM_SITE_DIR, and to Scheme code as:

  (assq-ref %guile-build-info 'scheme_site_dir)	    ; note underscores

It is available to third party programs via the GUILE_SITE_DIR configure.ac
macro, which sets var GUILE_SITE and does AC_SUBST on it.

[end]


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile 1.4.1.86 (snap) available

[MJ Ray]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> testing framework now liberated...  woo hoo!  (you can use "guile-tools
> run-all-tests" for your own non-guile projects and get the tally for
> PASS, FAIL, UPASS, XFAIL, UNTESTED, UNSUPPORTED, UNRESOLVED or ERROR

How does this relate to greg and/or SchemeUnit?  Not at all?



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: guile 1.4.1.86 (snap) available

[Thien-Thi Nguyen]

   From: MJ Ray <markj@cloaked.freeserve.co.uk>
   Date: Sun, 08 Sep 2002 17:21:04 GMT

   How does this relate to greg and/or SchemeUnit?  Not at all?

see comments in (ice-9 testing-lib).

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user