Re: What is Guile?

Re: What is Guile?

[Tom Lord]

    > From: Ricard Mira <ricardmm@tiscali.es>

    > What is Guile?

    > Guile is the GNU *multi-lingual extensibility interpreter*.  The
    > goal of the Guile project is to give users a choice of extension
    > language.


As a point of history, being multi-lingual was _a_ goal, but certainly
not _the_ goal.   RMS still highlights the multi-lingual goal in some
of his talks, but I think he is misplacing emphasis.

Having a standard, powerful, extension language was more of a
priority.  Emacsen (and much else, besides) had proven that lisps are
a good choice of extension languages, and we were interested in
building on that observation.

At the time that the Guile project started (back when it was called
GEL), Sun was pushing Tcl as a proposed "universal scripting language"
and the distinction, if there is one, between extension languages and
scripting languages was not very clear.  This was shortly before Oak
was released as Java.  The social dynamic around this kind of thing
was somewhat different back then -- there was no /., no freshmeat, and
barely a linux, for example.  Sun was not in so much of a slump, at
the time.  When Sun started making press releases about Tcl as the
universal scripting language, it seemed plausible that that would have
a nearly irresistible impact.  Even Usenix got in on the act and
started hosting conferences devoted to Tcl.

In short, Tcl seemed to have a lot of "mindshare", especially with
people who had only a casual interest in extensible applications and
extension languages.  In my own rather unpleasant experience, I had a
project to build an extensible application canceled out from under me
because I had decided to use GEL (Guile) rather than Tcl.

The experience of some of us, which assured us that Tcl was not a good
choice for an extension language, was difficult to argue for.  The Tcl
implementation was unusually clean and simple code.  The language was
easy to learn.  Tk was an nearly unprecendented set of functionality
to offer in a tiny interpreted language for unix-like environments.
To a casual observer, those virtues of Tcl were the most important
thing.

Several of us agreed, though, that Tcl had some serious problems.
While it was a clean language if compared to, say, sh -- it was
nevertheless a string-based language with the weaknesses that that
implied.  It didn't support garbage collected types and, generally,
had limited data structures.  It didn't support closure but did
support some vaguely similar constructs that had their own problems.
And so on....

When we started talking about using Guile instead of Tcl, people often
replied with various things they liked about Tcl.   For many small
programs, a string-based langauge is convenient.   Many people
preferred Tcl's syntax to a lisp syntax.   Back then, people could
still be taken seriously if they said "garbage collection is bad."

So we pointed out that Scheme was more powerful, more flexible.  We
pointed out that Tcl-like languages could be implemented (well) as
libraries for Guile, but that the reverse was not true.  One of the
graduate students who worked on Tcl even supported our arguments by
implementing Rush -- a nearly-Tcl language -- in Guile.  He went on to
suggest a set of changes that should be made to Tcl as a result of
what he had learned (with the aim of making Tcl faster and more
compilable, mostly by making it semantically cleaner).   (His work did
have influence on the language design of Tcl and on implementation
changes that made Tcl faster

For my part, shortly after Java was released, I demonstrated a C-like
syntax for Guile.   I think that, quite bitrotted now, that code is
still floating around.

So in the Propoganda, these ideas got very oversimplified.   I can't
speak for RMS but for my part, I wanted to try to consciousness raise
people to realize that the language wars were pointless.   You want to
use a different syntax?   That's a trivial matter.   You want
string-based data types?   That's just a library.   The important
thing was to make the core of the extension language a powerful and
fully general run-time system and interpreter, ideally based on a
language with good prospects for efficient compilation.

Nowadays, Tcl is mostly quiet (relatively speaking).  Python and Java
have a lot of "mindshare" (as do some other languages).  As with
Common Lisp, a large part of the economic effectiveness of those
languages comes from the wide range of available libraries for them.

The dominant importance of the libraries is, in retrospect, a quite
obvious development.   It also puts a serious crimp in the value of 
an extension language being "multi-lingual".   

Sure, a multi-lingual framework can, in some sense, use the set-union
of all of those libraries.  On the other hand, the "styles" of various
languages are sufficiently different that such library sharing is of
distinctly limited utility.  A good Python library is not necessarily
a good Scheme library or a good Java library or a good Tcl library.
You can glue the libraries together in a pinch -- but to make a
programming environment that is comprehensive yet compact and clean,
you're probably better off sticking to just one programming language.

Nowadays, I don't think people care too much if you happen to be able
to program Guile in Python.  (Evidence for this can be seen in the
Real Soon Now translator for Python->Guile.)  Perhaps if
Python-in-Guile offered significantly better performance or profoundly
new capabilities for Python programmers it would be a bigger deal ---
but merely being able to type in some Python syntax and sorta-kinda
use Python libraries is not a very compelling story.

So, in short, I would not recommend starting off the Guile manual in
the way you have quoted above.    And, if _I_ were maintaining Guile,
looking around at the scene, I think I'd be thinking about how to make
a really great extended Scheme, fast, clean, and small.

Finally, let me say this about Tcl: in some cases, garbage collection
_is_ bad.  In some cases, a language that can be implemented well in
<20K LOC is a serious virtue.  Tcl is not necessarily a great language
design -- but it's implementation continues to have many virtues in
some circumstances.  I now think that rather than just thinking about
a "multi-lingual extensibility interpreter", there would be some value
in thinking about how to design Tcl or Python-like languages that
admit tiny, simple implementation -- but that also "pun" as a subset
of a lisp dialect.  You can use the smaller language when you want --
but then you also have the option of scaling to the larger language,
sharing _some_ libraries between the languages, and exchanging data
between the languages.

-t



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

Re: What is Guile?

[Han-Wen Nienhuys]

lord@emf.net writes:
> [..interesting stuff elided..]

> For my part, shortly after Java was released, I demonstrated a C-like
> syntax for Guile.   I think that, quite bitrotted now, that code is
> still floating around.
> 
> Sure, a multi-lingual framework can, in some sense, use the set-union
> of all of those libraries.  On the other hand, the "styles" of various
> languages are sufficiently different that such library sharing is of
> distinctly limited utility.  A good Python library is not necessarily
> a good Scheme library or a good Java library or a good Tcl library.
> You can glue the libraries together in a pinch -- but to make a
> programming environment that is comprehensive yet compact and clean,
> you're probably better off sticking to just one programming language.
> 
> Nowadays, I don't think people care too much if you happen to be able
> to program Guile in Python.  (Evidence for this can be seen in the
> Real Soon Now translator for Python->Guile.)  Perhaps if
> Python-in-Guile offered significantly better performance or profoundly

It is interesting to note that Java is much more the "multi-lingual
framework", considering Kawa (Scheme in Java), Jython (Python in Java)
and host of other projects. (A colleague of mine had this neat
mini-Haskell-in-Java project.)  Apparently, the way to build such a
framework is by providing portable low-level byte-code operations,
glued to an extensive library.


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.xs4all.nl/~hanwen 


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

Re: What is Guile?

[Tom Lord]

    > From: Han-Wen Nienhuys <hanwen@cs.uu.nl>

    > It is interesting to note that Java is much more the "multi-lingual
    > framework", considering Kawa (Scheme in Java), 

This is still pretty good:

     http://www.cc.gatech.edu/~shivers/javaScheme.html


JVM is a popular target for economic and political reasons, not
technical ones.    In a technical sense, it's a lousy target.

As engineers, working to align the economics and politics with the
technology is our job.

Some (unspecified) thing in the space of lisp dialects is probably a
better UIL than JVM bytecodes.

-t


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

Re: What is Guile?

[Han-Wen Nienhuys]

lord@emf.net writes:
>     > It is interesting to note that Java is much more the "multi-lingual
>     > framework", considering Kawa (Scheme in Java), 
> 
> This is still pretty good:
> 
>      http://www.cc.gatech.edu/~shivers/javaScheme.html
> 
> 
> JVM is a popular target for economic and political reasons, not
> technical ones.    In a technical sense, it's a lousy target.
> 
> As engineers, working to align the economics and politics with the
> technology is our job.

Indeed. The libraries as a motivation for selecting a language is also
an economical thing: it takes less time to develop on a platform with
good libraries.  Worse is better (tm).

-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.xs4all.nl/~hanwen 


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

Re: What is Guile?

[tomas]

On Tue, Sep 02, 2003 at 09:47:53AM -0700, Tom Lord wrote:
> 
> 
> 
>     > From: Ricard Mira <ricardmm@tiscali.es>
> 
>     > What is Guile?
> 
>     > Guile is the GNU *multi-lingual extensibility interpreter*.  The
>     > goal of the Guile project is to give users a choice of extension
>     > language.
> 
> 
> As a point of history, being multi-lingual was _a_ goal, but certainly
> not _the_ goal. [rest deleted]

Very well put. I think parts of this text deserve to be put
on an historical comment to the docs. They express quite well
the difficulties Guile is having now.

Thanks, Tom

-- tomas


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

Re: What is Guile?

[Marius Vollmer]

tomas@fabula.de writes:

> Very well put. I think parts of this text deserve to be put
> on an historical comment to the docs.

I've put this into workbook/translation/history.text.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What is Guile?

[Marius Vollmer]

Ricard Mira <ricardmm@tiscali.es> writes:

> Tom Lord wrote:
> >     > From: Ricard Mira <ricardmm@tiscali.es>
> >     >
> >     > What is Guile?
> >     >
> >     > Guile is the GNU *multi-lingual extensibility interpreter*.  The
> >     > goal of the Guile project is to give users a choice of extension
> >     > language.
> >
> > As a point of history, being multi-lingual was _a_ goal, but certainly
> > not _the_ goal.   RMS still highlights the multi-lingual goal in some
> > of his talks, but I think he is misplacing emphasis.
> 
> It seems that the goal is to make Guile a *potential* multi-lingual
> environment which will allow people to implement languages as
> translators, making Guile an *actual* multi-lingual environment for
> extending programs.  Is it right?

Yes.  As far as I am concerned, I'll promise support for people that
want to write translators (support in the form of low-level stuff that
goes beyond Scheme, say), but I don't think that it is important for
Guile to have offer multiple somehow equivalent syntaxes/semantics.

Indeed, I would even say that putting the muli-lingual stuff at the
top of the feature list of Guile is dangerous.  It is very easy to
fail in direct competition to Python, say.  This woudn't do us any
good when we state Guile's reason for living as being multi-lingual
and I see the risk of failing as very real.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What is Guile?y

[Thamer Al-Harbash]

On Mon, 1 Sep 2003, Ricard Mira wrote:

> But above all, we plan to make Guile a
> *multi-lingual* environment, which will allow users to extend programs
> using their favorite extension languages.

Two quick gripes :)

(1) Use "Above all" instead of "But above all" (better grammar).

(2) Is this still a viable goal for guile? As a software
    developer of a project that is using guile for an extension
    language I'm beginning to think its less work to maintain
    bindings to other languages like Perl and Python than it is to
    write a translator from those languages to Scheme.

    I'm not trying to troll since I do realize this may be a sour
    point, but do the guile maintainers feel the work in writing
    translators is justified when its less of a hassle to simply
    provide bindings to other languages on a per application
    basis?

BTW my thanks go to Kevin Ryde for stepping up and doing all the
doco work.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
                    "HLAGHLHALUAG (KTHANX)"


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

Re: What is Guile?y

[Han-Wen Nienhuys]

tmh@whitefang.com writes:
> On Mon, 1 Sep 2003, Ricard Mira wrote:
> 
> > But above all, we plan to make Guile a
> > *multi-lingual* environment, which will allow users to extend programs
> > using their favorite extension languages.
> 
> Two quick gripes :)
> 
> (1) Use "Above all" instead of "But above all" (better grammar).
> 
> (2) Is this still a viable goal for guile? As a software
>     developer of a project that is using guile for an extension
>     language I'm beginning to think its less work to maintain
>     bindings to other languages like Perl and Python than it is to
>     write a translator from those languages to Scheme.
> 
>     I'm not trying to troll since I do realize this may be a sour
>     point, but do the guile maintainers feel the work in writing
>     translators is justified when its less of a hassle to simply
>     provide bindings to other languages on a per application
>     basis?

Regardless of that goal (which IMNSHO is not viable), I think that
vaporware should not be documented. Since usable translators do not
exist, the multi-lingual aspect should not be in the documentation
(yet)

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.xs4all.nl/~hanwen 


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

Re: What is Guile?

[Jonathan Bartlett]

What languages does Guile currently support?  Last I checked it was pretty
much just scheme.  has anyone added languages?  Is the interface to add
and use other languages documented?

Jon

On Mon, 1 Sep 2003, Ricard Mira wrote:

> Some time ago, I participated in the discussion about the
> reorganization of the Guile documentation.  I have been thinking about
> this and discussing via private email with Max Techter (who had
> proposed to apply domain analysis).  My conclusion is that we must
> understand Guile better before trying to reorganize its documentation.
>
> So my strategy would be to prepare something like a domain dictionary
> (which is a part of domain analysis) but integrated into the
> documentation (to avoid wasted work).  We could achieve that by
> improving the definitions of important things, starting with the
> definition of Guile itself.
>
> The "What is Guile?" node in the Guile Reference Manual contains the
> main definition of Guile.  I would like to make it more structured,
> because I think it is very important for the definition of Guile to
> explain its fundamental features in an easily understandable way.
> Later on, we could improve (or create) definitions for other important
> things, and put them into subnodes.
>
> Here is my proposal:
>
> ---------
>
> What is Guile?
>
> Guile is the GNU *multi-lingual extensibility interpreter*.  The goal
> of the Guile project is to give users a choice of extension language.
>
> Basically, Guile is an *interpreter* that implements the powerful yet
> simple Scheme programming language adding many practical features to
> it.  Further, it is the GNU standard for *extensibility*: we provide
> it as a C library which developers can easily incorporate into C
> programs running on the GNU system, so that users can extend all those
> programs in a similar way.  But above all, we plan to make Guile a
> *multi-lingual* environment, which will allow users to extend programs
> using their favorite extension languages.
>
> * Menu:
>
> * Scheme Interpreter::
> * Extensibility Standard::
> * Multi-lingual Environment::
>
>
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel
>



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

Re: What is Guile?

[Kevin Ryde]

Ricard Mira <ricardmm@tiscali.es> writes:
>
> But above all, we plan to make Guile a
> *multi-lingual* environment, which will allow users to extend programs
> using their favorite extension languages.

I'd be wary of emphasising that, since it's not true now, and seems
unlikely to be so in the near future.

For what it's worth, I quite like the existing text.  It's informal
but seems to have a fairly logical sequence.


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

Re: What is Guile?

[Jeff Read]

On Sun, Sep 07, 2003 at 10:37:33AM +0200, Ricard Mira wrote:
> 
> Maybe I emphasized the multi-lingual aspect too much, but I think we
> should emphasize it a bit, since it seems the fundamental feature in
> the design of Guile.  (But we should do that in a grammatically
> correct way -- thanks for the correction, Thamer!).
> 

It seems as if nowadays when people want multilingual, they go with .NET/Mono and MSIL, or alternatively, JVM, and be done with it. These two environments also have the advantage of being completely integrated with host applications in their native IL -- no bindings or wrappers required. 

I use Guile extensively and never deal with any language except Scheme. Maybe I'm missing something in its engineering, but I think Guile's greatest strength is as an excellent workhorse Scheme, suited to tasks where others might use Perl or Python. Guile and GIMP together are the greatest argument against Scheme's propellerheadedness, the prevailing notion that it is suited only for academic use.

Am I really off the mark here?

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford


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

Re: What is Guile?

[Paul Jarc]

Ricard Mira <ricardmm@tiscali.es> wrote:
> Maybe I emphasized the multi-lingual aspect too much, but I think we
> should emphasize it a bit, since it seems the fundamental feature in
> the design of Guile.

It seems to me that embeddability/extensibility is more fundamental to
Guile.

Also, while implementing new languages as Guile translators might be
ok, I don't think it's a good idea to reimplement existing languages.
There would inevitably be incompatibilities with the original
implementation, which just complicates the problem of writing portable
code in that language.  (See sh.)  Sometimes it's even a challenge
just to make code portable to different versions of the same
implementation.


paul


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

Re: What is Guile?

[Thamer Al-Harbash]

On Mon, 8 Sep 2003, Paul Jarc wrote:

> Also, while implementing new languages as Guile translators might be
> ok, I don't think it's a good idea to reimplement existing languages.

I would agree, unless you can claim that it's easier to write a
Perl to guile translator and embed guile in your application than
to just embed the Perl interpreter into your application.

I haven't seen much documentation suggesting why guile can
support other languages better. Has someone written such a
document? It would go a long way to getting the author of a new
language to implement his language's interpreter or compiler
ontop of guile.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
                    "HLAGHLHALUAG (KTHANX)"


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

Re: What is Guile?

[Jonathan Bartlett]

> I haven't seen much documentation suggesting why guile can
> support other languages better. Has someone written such a
> document? It would go a long way to getting the author of a new
> language to implement his language's interpreter or compiler
> ontop of guile.

The idea comes from Scheme itself - it doesn't really have a syntax.  It's
just a raw parse tree with some primitives.  Using a combination of
function definitions, macro definitions, etc., you can easily modify
scheme to work like any system you want.  Then you just need a parser to
convert the raw code into a parse tree, and have your scheme interpretter
run your parse tree.

Basically, what you would need is the following:

 a) a flag in Guile so that you could specify which parser / language
module to use

 b) the ability to create both macros and definitions within a closed
environment which can be applied to a list (i.e. parse tree - I believe
this is already there)

 c) an interface definition for parsers and language providers.

Basically, the parser would need to be given an environment for a
language, parse the string or input file to a list, and eval that list
within the environment it was passed.

For examples of Scheme used as a syntaxless representation of multiple
languages, see Kamin's "Programming Languages: An INterpretter-Based
Approach" and "Essentials of Programming Languages".  Now, Kamin had to
embed the code for the different languages in the interpretter itself, but
this is doable from scheme itself with macros.

Jon



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

Re: What is Guile?

[Jeff Read]

On Mon, Sep 08, 2003 at 02:39:12PM -0700, Jonathan Bartlett wrote:
> 
> The idea comes from Scheme itself - it doesn't really have a syntax.  It's
> just a raw parse tree with some primitives.  Using a combination of
> function definitions, macro definitions, etc., you can easily modify
> scheme to work like any system you want.  Then you just need a parser to
> convert the raw code into a parse tree, and have your scheme interpretter
> run your parse tree.
> 
> Basically, what you would need is the following:
> 
>  a) a flag in Guile so that you could specify which parser / language
> module to use
> 
>  b) the ability to create both macros and definitions within a closed
> environment which can be applied to a list (i.e. parse tree - I believe
> this is already there)
> 
>  c) an interface definition for parsers and language providers.

Don't forget d) parsers and language modules for various languages. :) They probably have to be written in Scheme, and it seems that there are few people willing to do one, or at least, willing to stick to it long enough so that it's a recognizable form of the target language.

Converting language X to Scheme, and then interpreting the Scheme is an interesting academic idea but if technology doesn't work for people then it doesn't work. Guile isn't the fastest Scheme interpreter in the world, and adding another layer of parsing and conversion will simply make things slower. If given the choice between a slow, subtly incompatible Perl substitute and Perl, most developers will simply embed Perl. Same goes for Python, or whatever other language you can think of. There's also the taste aversion to Scheme to overcome. GIMP appears to be migrating from Scheme to Perl as its embedded language of choice. Alternatively they will target JVM or MSIL bytecode.

Making Guile compile to, say, the Parrot VM before execution and then writing compilers that do X-language->Scheme->Parrot, might be an interesting way to go. Nevertheless, there are numerous marketing hurdles to overcome, the public's taste aversion to Scheme being just one of them. The only way I see Guile becoming everybody's favorite multilingual embedded interpreter is if the FSF really put its weight behind it as The Official GNU Way To Go. That's how free software authors standardized on the creeping horror that is Autoconf (which I'm writing a replacement for (in Guile!)). :)

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford


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

Re: What is Guile?

[Jonathan Bartlett]

> Converting language X to Scheme, and then interpreting the Scheme is an
> interesting academic idea but if technology doesn't work for people then
> it doesn't work. Guile isn't the fastest Scheme interpreter in the
> world, and adding another layer of parsing and conversion will simply
> make things slower. If given the choice between a slow, subtly

It would only possibly make the loading slower.  Execution should be about
the same.  Even parsing should be about the same - you have to parse it no
matter what.  The only difference is the final parse tree.  So, I'm not
really sure that it would add overhead.

However, the real gem of this is the ability to come up with little
languages that exactly match your needs.  Specialized macro sets + helpful
syntax makes this easy and useful.

I got interested in scheme because of the possibility of language
converters.  Not even necessarily to current languages (although that's
certainly possible) but for embedding little languages and being able to
customize sandbox environments for scripts, which I do not believe is as
fully available for any other language as it is for scheme, specifically
GUILE.

Jon



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

Re: What is Guile?

[Lynn Winebarger]

Jeff Read wrote:
> On Mon, Sep 08, 2003 at 02:39:12PM -0700, Jonathan Bartlett wrote:
> 
>>The idea comes from Scheme itself - it doesn't really have a syntax.  It's
>>just a raw parse tree with some primitives.  Using a combination of
>>function definitions, macro definitions, etc., you can easily modify
>>scheme to work like any system you want.  Then you just need a parser to
>>convert the raw code into a parse tree, and have your scheme interpretter
>>run your parse tree.

    Don't forget the run-time typing of values. Or the arbitrary precision
arithmetic, for that matter.

>>Basically, what you would need is the following:
>>
>> a) a flag in Guile so that you could specify which parser / language
>>module to use
>>
>> b) the ability to create both macros and definitions within a closed
>>environment which can be applied to a list (i.e. parse tree - I believe
>>this is already there)
>>
>> c) an interface definition for parsers and language providers.
> 
> 
> Don't forget d) parsers and language modules for various languages. :) 
 > They probably have to be written in Scheme, and it seems that there are few
 > people willing to do one, or at least, willing to stick to it long enough
 > so that it's a recognizable form of the target language.

     I'm working on a parser generator to go with the regexp compiler I
put up on guile-sources last week*.  Once guile comes with such tools (not
necessarily mine),  perhaps there will be a greater inclination to work on
translators.  I think that's always been the theory.

> Making Guile compile to, say, the Parrot VM before execution and then writing 
 > compilers that do X-language->Scheme->Parrot, might be an interesting way to go.
 > Nevertheless, there are numerous marketing hurdles to overcome, the public's taste
 > aversion to Scheme being just one of them.

    What public is that?  As far as I know, most of the public has an aversion to programming,
period.  I don't think the target is to translate Perl, so much as the kinds of programming
languages (limited in power) that are embedded for use by this hulking majority of users.
    There are also FFI applications.

Lynn

* I can now build predictive, SLR(1), and LR(1) parse tables.  I still have to do LALR(1) and
provide operator precedence relations to support Yacc style grammars.
    I am, of course, completely ignoring errors in grammars, so there's plenty of work left to
be done for an end-user type of product.



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

Re: What is Guile?

[Dale P. Smith]

Jeff Read wrote:

> Converting language X to Scheme, and then interpreting the Scheme is 
> an interesting academic idea but if technology doesn't work for 
> people then it doesn't work. Guile isn't the fastest Scheme 
> interpreter in the world, and adding another layer of parsing and 
> conversion will simply make things slower. If given the choice 
> between a slow, subtly incompatible Perl substitute and Perl, most 
> developers will simply embed Perl. Same goes for Python, or whatever 
> other language you can think of. There's also the taste aversion to 
> Scheme to overcome. GIMP appears to be migrating from Scheme to Perl 
> as its embedded language of choice. Alternatively they will target 
> JVM or MSIL bytecode.

Yes indeed.  I think that's why most of the ficus so far has been on
improving the Guile interpreter and moving to a compiler or other
speedups, like Gnu Lightning.


> That's how free software authors standardized on the creeping horror
> that is Autoconf (which I'm writing a replacement for (in Guile!)).
> :)

Hooray!

-Dale


-- 
Dale P. Smith
dsmith at actron dot com



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

Re: What is Guile?

[Andreas Rottmann]

Jeff Read <bitwize@snet.net> writes:

> The only way I see Guile becoming everybody's
> favorite multilingual embedded interpreter is if the FSF really put
> its weight behind it as The Official GNU Way To Go. That's how free
> software authors standardized on the creeping horror that is
> Autoconf (which I'm writing a replacement for (in Guile!)). :)
>
*G* Is there any status info available for your autoconf replacement?

Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.


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

Re: What is Guile?

[Thamer Al-Harbash]

On Tue, 9 Sep 2003, Andreas Rottmann wrote:

> Jeff Read <bitwize@snet.net> writes:
>
> > The only way I see Guile becoming everybody's
> > favorite multilingual embedded interpreter is if the FSF really put
> > its weight behind it as The Official GNU Way To Go. That's how free
> > software authors standardized on the creeping horror that is
> > Autoconf (which I'm writing a replacement for (in Guile!)). :)
> >
> *G* Is there any status info available for your autoconf replacement?

Just to spite us Jeff should implement it as an m4 to scheme
translator.

-- 
Thamer Al-Harbash
GPG Key fingerprint: D7F3 1E3B F329 8DD5 FAE3  03B1 A663 E359 D686 AA1F
                    "HLAGHLHALUAG (KTHANX)"


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

Re: What is Guile?

[Marius Vollmer]

Ricard Mira <ricardmm@tiscali.es> writes:

> So my strategy would be to prepare something like a domain
> dictionary (which is a part of domain analysis) but integrated into
> the documentation (to avoid wasted work).  We could achieve that by
> improving the definitions of important things, starting with the
> definition of Guile itself.

I have the feeling that this strategy will not work out very well for
a volunteer project.  I think it is too easy to get stuck half way
thru and end up with a 'head without body'.

Of course, I don't want to discourage you or others from improving the
documentation, far from it.  But I'm wary of undertakings that take a
large amount of dedicated work until they turn up profits.

So, what I'm saying is that we should only really discuss complete
changes to the documentation, where we can decide whether they are an
immediate improvement or not.  Changes that only promise improvements
later on but are (arguably) a step back in their current form (since
they leave holes that weren't there previously) should not be made.

The current "What is Guile" node is OK in this light, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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