GNU Extension Language Plans
Peter da Silva
(I can safely say that the FSF have proven themselves credible in the field
of language implementation) was going to do something to resolve the mish-
mash of lisp and scheme and lispoid language implementations out there. But
this announcement doesn't exactly fill my heart with warm fuzzies.
First of all, it starts off with more of the FSF's recent attacks on Tcl, a
fairly innocuous little language that is really quite good at what it does
even if it doesn't do everything Stallman wants. This tends to make me think
that the real reason isn't to fix a problem, but to promote some subtle
political agenda.
This is reinforced when he starts attacking Sun. Attacking Sun is a great
way to get the iconoclasts on your side, but occasionally Sun does come up
with some good things (NeWS, for example, which people stayed away from in
droves, largely due to FUD) and the folks bashing Sun miss the boat (DEC
has done some good things with OSF/1, but nobody else has managed to pull
a rabbit out of that hat).
So, is the Gnu Extension Language going to be another Motif, another RFS,
another OSF/1? Some great smelly monster that even if it succeeds makes nobody
happy?
That brings me to my second problem... the list of extensions. It seems like
about half the announcement is extensions to scheme. Come on, the big advantage
to lisp-like languages is the way their simple semantics and syntax can be
used to bootstrap very powerful concepts.
What's wrong with taking some existing implementation, like STk's interpreter,
and adding a modicum of string and O/S functions? If Tcl is an unholy cross
of Lisp and Awk, this is sounding like some similarly sanctified marriage of
Lisp and Perl.
Oh well, at least it looks like he's got a clue about licensing...
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
Wayne A. Christopher
1. It appears that there are to be two modules -- a compiler for a given
extension language, and a Scheme-based runtime interpreter. It sounds
like the compiler will be GPL'ed and the runtime won't be. But what if
I want to call "eval some-extension-language-command" from a running program?
Will it get compiled into Scheme on the fly (and then into C and dynamically
loaded, even)? I think this will be a big performance hit, and furthermore
it will require every application to include the GPL'ed compiler, which
defeats the purpose of unencumbering the runtime.
2. Will the Scheme runtime need something like Boehm's garbage collector?
I'm sure there are applications that can't use this sort of system -- for
example, ones that maintain pointers to objects in core in external
storage but not internally (for whatever reason).
3. Tcl is very popular in embedded applications where code size is critical.
It seems that the Scheme interpreter plus the garbage collector plus the
compiler would be a lot larger.
It's definitely a cute idea, but I'm not sure it's very practical...
Wayne
Bryan O'Sullivan
>2. Will the Scheme runtime need something like Boehm's garbage collector?
I can't imagine why it would. It's fairly straightforward to have your
Scheme (or whatever) system maintain pointers into C land and vice
versa, with rather less magical support from the RTS than the Parc GC
gives (the system I've seen uses structures called "malloc" and
"stable" pointers, respectively, to point in each direction).
What GNUscript's RTS does absolutely need is a decent generational
garbage collector, so that it will provide reasonably sane interactive
performance. One of the things that regularly makes me want to kick my
workstation through a window is the GC and buffer relocation burps in
Emacs.
<b
--
Bryan O'Sullivan email: b...@cyclic.com, bosu...@maths.tcd.ie
Department of Poverty wuh wuh wuh: http://www.scrg.cs.tcd.ie/~bos
Trinity College, Dublin nous n'avons qu'un peu de mouton aujourd'hui.
Warren Harris
> Until today, users have not been able to choose which extension
> language to use. They have always been compelled to use whichever
> language is supposed by the tool they wish to extend. And that has
> meant many different languages for different tools.
Richard,
I just wanted to draw your attention to the Open Scripting
Architecture (OSA) that my colleagues and I developed at Apple. OSA
allows users to choose the language they prefer to customize their
applications with.
OSA works by defining an API that application programs use to invoke
scripts, and a standardized way of tagging compiled scripts with the
language to which they belong. It also provides a dispatching
mechanism that is used at runtime to associate a given script with its
evaluator. The API also defines standardized calls for printing
values, transforming C data to and from values the language can
manipulate, triggering scripts in response to event input, compiling
scripts (for some languages, this may be as little as tagging the text
of the script with the language it belongs to). Essentially, OSA
defines the read-eval-print calls for applications.
To date there are several languages that are OSA-compliant, including
AppleScript, UserLand Frontier, a version of SmallTalk (ParcPlace?) as
well as the QuicKeys macro language. There are also many applications
that use OSA, thereby allowing any of these languages to serve as
their customization language.
I realize that GNU will probably never adopt OSA, but it might want to
take a look at how it works as an alternative to giving the user a
choice of customization languages by embedding those languages in
Scheme. I think the OSA approach gives the language implementor much
more flexibility in how to implement their language than Scheme ever
could. An OSA-like approach would allow Scheme as well as the real Tcl
to be used as a customization language rather than the Tcl-like Rush
(of course you could have both).
Warren Harris
General Magic
Peter da Silva
Tom Christiansen <tch...@mox.perl.com> wrote:
> Thanks, Peter. See Larry's release notice posted elsewhere in these
> language areas for details, and/or glance at my implementation of a
> Patricia trie in perl, recently posted elsewhere in this thread.
Yes, I had a look at it. You didn't use postix if at all, that I could see.
> Do you want big languages and little programs or vice versa?
I want little languages and little programs. I don't believe you can't
get there (watch out, he's got something under his coat! Oh no! He's got
a Forth interpreter! Run!) from here...
> I guess all we need is a elisp-to-perl (or is that scheme-to-perl)
> translator now and even rms will be happy. :-) (Someone else reports
> working on a tcl-to-perl translator already, but progress is slow.)
I don't think that you're going to get a good translator from any of these
data-driven languages to a procedural language any time soon. Run-time
manipulation of code is too much a part of what makes them interesting.
And it's also too much a part of what makes them useful extension
languages.
Peter da Silva
> Anyway, none of these seems "big" in terms of code size and/or
> runtime space requirements. As for "flexible string manipulation
> functions" and "access to all or most of the Unix system calls", these
> will add to the "footprint" of the language.
You're right, they will. But for the application domain I'm interested in
(extension languages for programs running on UNIX) it's more important.
I mean in this domain I find Tcl more than adequate, and nobody is going
to tell me it has anywhere near the functionality of scheme even without
any of these extensions.
> I don't, OTOH, see why not we couldn't just have a simple
> #ifdef compilation option to exclude various features from the
> language,
That turns out not to work very well. You end up with everything compiled
in anyway. We've already been down that road in the Tcl world. The real
solution to application size is dynamically loadable extensions. Things like
the UNIX I/O package and the strings package would be well suited to that.
Extensions to the language syntax are less so.
And the real "size" metric I'm using is more like the one Tom was using
to measure the size of Perl 5 versus Perl 4: complexity. Adding new primitives
doesn't add much to the complexity (the mental size, if you like) of the
language. Adding new control structures, or changing the basic syntax
(making it more lispy) does.
> For real tightness and power in a scripting language, I (and many others)
> would recommend using "Forth" where these things matter
OK, OK, how about Postscript? In a lot of ways it's got most of the tightness
of Forth with a lot cleaner syntax. And people are used to dealing with it.
Yes, traditional PS implementations are pretty big but that's mostly the
rendering engine...
> Anyway, when can we get it ;-) Also, I'll repeat my oft'
> expressed desire to see DOS/Windoze/Win32 versions.
You already got that with Tcl.
Raul Deluth Miller
: Ousterhout is more right about the Law than most in their Ivory
: Towers here seem to care to admit: the people will use gleefully
: only that which comes easy to them, and these languages will drive
: out the others.
Which reminds me of this little gem:
#!/usr/local/bin/wish -f
label .lab -bd 2 -relief raised -text "So, What is wrong with using a utility"
label .lab2 -bd 2 -relief raised -text "that kills babies...I happen to like"
label .lab3 -bd 2 -relief raised -text "tcl."
pack append . .lab {top fill} .lab2 {top fill} .lab3 {top fill}
button .b1 -text "End this madness" -command exit
pack append . .b1 {top}
--
Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q
<rock...@nova.umd.edu> y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e<n
NB. public e, n, y
x -: n&|&(*&y)^:d 1 NB. 1=(d*e)+.p*&<:q
Peter da Silva
Tom Christiansen <tch...@mox.perl.com> wrote:
> Peter, be aware that the common man has neither the time for nor any
> appreciation of your spartan minimalism.
Spartan minimalism? Tcl is hardly spartan... it's just designed for a
specific job and does it very well. Perl is designed for a different
job and does THAT very well. I don't think it could do Tcl's even as
well as Tcl does Perl's.
[preaching to the choir omitted]
Hey, I'm responsible for some of the features in Tcl that *are* there, like
the way strings work. Karl and I worked out the semantics of Tcl arrays on
his whiteboard when he worked here. We did Tcl Extended, because the original
language was too minimal, and a lot of that has been picked up. For that
matter we picked some ideas up from Perl... some of them didn't make the
cut and still aren't in the core language (like the filescan stuff).
But there's always been this basic assumption: that you don't add a feature
just because it sounds good. You add it because you need it. If there's two
ways of doing something you use the one that avoids complicating the language.
The classic example in Perl is the postfix if statement. It doesn't add
any capability to the language, and it confuses new users. In an extension
language that's a bad thing... because most of the time most users are
new users, because they're not using the language to do a job, they're
using it to configure the tool that does the job.
> The problem is, you see, is that quite simply, you're designing the wrong
> languages for the wrong crowd.
Who, me? I'm not designing a language at all. Or redesigning one. I'm trying
to keep a bunch of people from inventing yet another camel when the specs
don't even call for a horse.
[a bunch of stuff that doesn't seem to have anything to do with me at all,
skipped]
> When it comes to lisp or tcl, while the extensive run-time nature of
> those languages make machine language generation (at least of certain
> constructs) difficult, compiling them into native perl (probably
> with a run-time emulator library) should in theory present no insurmountable
> hurdles.
Certainly with a runtime emulator library... especially when you're running
around loading stuff on an ongoing basis at runtime and using code fragments
as your communication channel between components. And since you have to keep
doing that, what's the point to putting Perl in the loop at all? It's not
technically infeasible, it's just not very useful. And that's why I think
it's unlikely.
Tom Christiansen
:But there's always been this basic assumption: that you don't add a feature
:just because it sounds good. You add it because you need it. If there's two
:ways of doing something you use the one that avoids complicating the language.
:The classic example in Perl is the postfix if statement. It doesn't add
:any capability to the language, and it confuses new users.
Don't make the user through more work than necessary. If it bothers you
that that we in English sometimes naturally express outself with the
conditional afterwards, use somthing else. It's more restrictive and
stilted and unnatural to enforce a particular style on the user. Ask your
mother if you don't believe me.
if (annoy $peter reversed("conditional")) {
use Something_Else;
}
value("flexibility") > value("restriction");
ask $mom if disbelieve $tom;
Remember, in C, you can say for(;c;) wherever you can say while(c), and
no one seems to mind that. It's the same issue. One is more readable.
You're asking for decreased legility for no good reason. Likewise,
do {
foo();
} until $a || $b;
is some better than either of these:
do {
foo();
} while !$a && !$b;
do {
foo();
} while !($a || $b);
because they make you go through more work than needed. Likewise
foreach $a (@list) {
foo($a);
}
is superior to the far busier:
for ($i = 0; $i <= $#list; $i++) {
foo( $list[$i] );
}
But so what? It's not like we should can one or the other and
force you to choose between C and shell.
[yes, much of the previous was more addressed to the thread then
to just Peter]
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
Malt does more than Milton can
To justify God's ways to Man.
lvi...@cas.org
:
:> I still think that all other things being equal a tighter, smaller language
:> is better than a larger and more complicated one, and all the enhancements
:> to Scheme suggested by RMS in <941019042...@mole.gnu.ai.mit.edu> are
:> a bit worrisome. If this comes down to a fight between Sun and the FSF my
:
: I don't, OTOH, see why not we couldn't just have a simple
:#ifdef compilation option to exclude various features from the
Having to compile up multiple copies of interpreters has been tried in the
perl and tcl communities - to the frustrations of many. What I and many
others have called for are ways to dynamically load independantly developed
sets of enriched command sets into a very small base interpreter. This
would allow me to tailor an application to a required set of objects
and appropriate operations/methods, while passing on pieces for which I have
no need. Why should my applications be saddled with hundreds of k of X
overhead if the app I want to develop just wants to send messages to an
existing X app - but needs to do no window instantiation at all? Equally,
if all I need to do is small integer manipulation, I would just as soon
not be saddled with bignum floats. On the other hand, if a user wishes
to write their own extended commands for my app, and in doing so determines
that _they_ need bignum floats, X, or whatever, I would like for the language
to be able to support _them_ requesting said objects be loaded, along with
appropriate operation/method library code, etc.
:language, e.g. #undef GXL_UNIXCALLS or whatever. Same for "expect"
:interface (what is expect anyway?).
Expect is a nifty concept (available at least in a Tcl and Perl form -
perhaps in other languages now as well) where one defines a set of
interactions that need to take place one or more processes. Think of
telecomm software in the micro world which allow you to capture login
scripts and then replay them to log into services, etc. Expect is
a language where one can write 'scripts' to invoke ftp, telnet, etc.
and then generate requests, watch for respones, etc. The latest Expect,
with an extended environment known as Expectk, allows one to wrap aaGUI
around a traditional text based interaction such as ftp, password changes,
whatever, in a rather nifty way. There is also a neat paper done able
a feature of Expect called Kibitz - where one links two separate programs
together with expect/kibitz glue between - so that one program feeds input
to another and then recieves the second's output as it's input (think
of playing two chess programs against one another - not that this is
the only use, but a simple to grasp one).
: I would guess in the general case, the lion's share of apps
:using the language will have oodles of giant GUI extensions, user
:i/o validation, etc. and one average size 8bit+ color image will have
:a footprint bigger than the whole language implementation anyway! For
:real tightness and power in a scripting language, I (and many others)
:would recommend using "Forth" where these things matter - but I
It is true that many apps will be extended using many pieces of
extensions. If they are all loaded only when needed, and able to be
unloaded when not needed, this would allow an app to consume only the
resources needed at any one time. And if folk take into consideration
the 'hypertool' or applet approach, where entire mini-applications grow
up and communicate between one another, then one will find that more
use of distributed compute resouces, threading, etc. will be utilized.
--
:s Great net resources sought...
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
The task of an educator should be to irrigate the desert not clear the forest.
Tom Christiansen
:Having to compile up multiple copies of interpreters has been tried in the
:perl and tcl communities - to the frustrations of many. What I and many
:others have called for are ways to dynamically load independantly developed
:sets of enriched command sets into a very small base interpreter.
Dynamic loading of extensions works just fine in Perl. Why do you think
the /usr/bin/perl binary can be just 50k? There's no longer any need for
fooperl, barperl, and flotzperl. Tcl users can use this feature if they
start their tcl programs with
#!/usr/bin/repl
use Tcl;
and go from there. No, I'm not entirely kidding.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
Documentation is the castor oil of programming. Managers know it must
be good because the programmers hate it so much.
Peter da Silva
Tom Christiansen <tch...@mox.perl.com> wrote:
> Don't make the user through more work than necessary. If it bothers you
> that that we in English sometimes naturally express outself with the
> conditional afterwards, use somthing else. It's more restrictive and
> stilted and unnatural to enforce a particular style on the user. Ask your
> mother if you don't believe me.
[snippet]
I'm sorry, but putting a feature in because it's english like is just
plain silly. Programming languages are not human languages. If you don't
think so, there's always COBOL.
The syntactic distance between
> if (disbelieve $tom) {
ask $mom;
}
and:
> ask $mom if disbelieve $tom;
is pretty high. The former is clearly a control structure. The latter is
hard to pick out of code.
As for C, I don't recall arguing that C is either easy to learn or that it
would make a good extension language.
On the gripping hand:
for(;read_news;)
flame();
and:
while(read_news)
flame();
retain the same basic form. They don't add to the conceptual cost of learning
and using the language.
Some extensions are useful. Foreach is like C's "+=", it takes a common
idiom and removes a lot of duplication from it. Postfix if doesn't reduce
the complexity of the statement any (there's still as many elements to
evaluate) but does add to the complexity of the language.
This is where I'm coming from: adding a feature to a language because it's
neat (and postfix if is certainly neat... it's downright cute) is a bad idea.
That way lies COBOL.
(no, I don't think Perl's COBOL. I will note that a lot of the improvements
to Perl have involved removing complexity, which defends it from that
charge quite well *and* supports my argument against un-necessary frills)
Mikael Djurfeldt
>>>>> "ozan" == ozan s yigit <o...@nexus.yorku.ca> writes:
In article <OZ.94Oct...@nexus.yorku.ca> o...@nexus.yorku.ca (ozan s. yigit) writes:
ozan> Mikael Djurfeldt is concerned about the suggested
ozan> modifications to the Scheme language in order to fullfill
ozan> GNU extension language goals. I do not think there is any
ozan> cause for concern. It is clear that the changes are not to
ozan> The Scheme language, which is well defined in an IEEE
ozan> standard and Revised^4 Report [...]
It was my intention only to talk about the GNU extension language.
I would like it to be a good language/implementation.
/mdj
Tim Smith
>You're suffering from delusions of clinically committable magnitude if you
>begin to think for one moment that anything as counterintuitive to the kid
>off the street as Forth -- or Lisp for that matter -- has a chance of
>actually gaining sufficient acceptance and widespread use to become a the
>cyber lingua franca you're looking for. Even RMS in his guise as the
Everyone seems to be assuming that the extension language built into the
program must be the same as the extension language that the user sees.
Yet this is not so. What would be wrong with building in something that
is small, simple, and fast (e.g., Forth), and then providing tools to
compile something else to that (e.g., a gcc backend that generates Forth
instead of assembly)?
--Tim Smith
Simon Leinen
Mikael> only one binding.
This is always taken for granted by you proponents of single-namespace
Lisps. I argue that most people "intuitively" have no problems at all
distinguishing the several meanings of a symbol. I have never seen
anybody who was confused about the predefined meanings of the word
CONS as a type specifier and an operator (function) in Common Lisp,
for example. Personally I would rather expect people to be surprised
when they use a variable with a generic name like LIST, and find that
they have redefined a system function in the scope.
I admit that from a formalism-aesthetic point of view, multiple
namespaces are not as nice ("violating the 0-1-infinity principle"),
but this does not mean that a LISP-1 is more "intuitive" than a LISP-2.
Mikael> Because of this most lisp code doesn't use both value and
Mikael> function bindings simultaneously.
It is true that most symbols in a given program don't have a variable
and a function binding at the same time. But the reason might also be
that "intuitive" names for functions and variables are often (but not
always!) different.
--
Simon.
lvi...@cas.org
It is great that Perl 5 now has this feature - I am still expecting to see
such a feature in Tcl 4 or 5 as well. My point was that folks planning
a new GNU Scheme should plan on also providing such a feature as well.
With the ability to auto load both object libraries AND externally written
{plug in your favorite language interpreter here} files, one gets quite
a productivity boost.
Of course, the real problem is how to do this across all platforms - how
does Perl handle all the different Unix, MS-DOS, etc. limitations on
dynamically loaded objects? (I have the Perl5 tech doc printed - it's
just that my speed reading skills keep getting cancelled out by kids
wanting my attention...)
Raul Deluth Miller
scheme: for example, give all variables a v prefix, and all functions
an f prefix, and run a syntax analyzer over the code to insert v or f
in the front of each symbol.
Similarly, it's "trivial" to add (e.g.) property lists to scheme --
just introduce a global variable that's a hash table indexed by
symbols.
These are just examples -- their point is to point out that adding
features to scheme needn't destroy the underlying language.
Marco Antoniotti
argument that actually would clarify the wide acceptance that Tcl/Tk
has gained.
The main reason for the acceptance of Tcl is the '/Tk' suffix.
I cannot see anybody who would like to learn a language like Tcl if it
where not for all the "Value Added" by Tk.
I am usually amazed by the ease with wich you can build interfaces
with Tk. I also think that that is what makes the whole thing so
appetible.
Which brings up the following point. Any language which wants to be a
replacement for Tcl/Tk (and I believe that any Scheme or CL serious
attempt would just breeze through) should provide an equivalent of Tk.
Thanks for the attention.
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: mar...@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
Peter da Silva
Tim Smith <t...@u.washington.edu> wrote:
> Everyone seems to be assuming that the extension language built into the
> program must be the same as the extension language that the user sees.
> Yet this is not so. What would be wrong with building in something that
> is small, simple, and fast (e.g., Forth), and then providing tools to
> compile something else to that (e.g., a gcc backend that generates Forth
> instead of assembly)?
Using an arbitrary syntax to avoid favoritism:
display "Enter keystroke: "
read keystroke
display "Enter macro: "
read macro
define_key_macro %keystroke %macro
Now, if you're using an external compiler you need to run that compiler
from "define_key_macro".
Now suppose you're reading these from an X resource at startup. You're going
to have to call the compiler for *each* resource in turn.
Sorry, it just don't work. The underlying language *is* going to be exposed
to the user.
That doesn't mean that Scheme isn't a fine language for this, just that it's
nonsense to pretend the underlying language doesn't matter.
Mike McDonald
|>
|> Everyone seems to be assuming that the extension language built into the
|> program must be the same as the extension language that the user sees.
|> Yet this is not so. What would be wrong with building in something that
|> is small, simple, and fast (e.g., Forth), and then providing tools to
|> compile something else to that (e.g., a gcc backend that generates Forth
|> instead of assembly)?
|>
|> --Tim Smith
Because you can't maintain the system then. If your users get to go off and
pick any tranlator they want, you'll have to learn every available language
inorder to debug your user's scripts. I don't believe that it is practical for
you to expect to be able to debug a script written is some unknown language that
was machine translated into scheme, or forth, or whatever. (I've argued this same
point with the Dylan people to no good.)
If you're not going to let them pick, then you just as well force them to use
the same language as you picked.
Mike McDonald m...@trantor.ess.harris.com
Christopher M. Hanson
Language .. by Wayne A. Christopher@rem
> > program must be the same as the extension language that the user sees.
> > Yet this is not so. What would be wrong with building in something that
> > is small, simple, and fast (e.g., Forth), and then providing tools to
> > compile something else to that (e.g., a gcc backend that generates Forth
> > instead of assembly)?
>
> 1. A decent extension language will probably need "eval".
> 2. Eval must take statements in the language the user writes.
> 3. The extension language runtime must understand (either to interpret
> or to compile) this language.
> 4. Therefore it is impossible to completely separate the user-visible
extension
> language from the internal extension language.
>
> Of course, one could provide the user-visible language as a dynamically-
> loadable interpreter or compiler, but this would preclude anything as
> heavy-weight as running gcc for every eval statement.
No! No! No! Study AppleScript... Applications have resources that the
scripting system uses to determine what EVENTS an application can
receive; then, anything (another app or a "Scripting component") can
send it those events to tell it to do things. Eval is not a command in
any AppleScript dialect; you can send applications a "DoScript" event
with a script string as an argument (if they support that event), or you
can have AppleScript execute a script object. Execution of a script
object is actually left up to the scripting component; AppleScript just
manages the dialects and everything. Thus, you could have an
AppleScript-English script that executes another script written using
the TCL or GNU component, etc. BTW, scripts can also export events so
you could do "on open ... end open" "on quit ... end quit" etc. in one
script and have those events exported.
It's worth checking out -- not everything Apple does is evil just
because Apple does it (no flames on this please).
TTFN,
Chris
---
Chris Hanson, KSC, KTD-2 <ch...@andrew.cmu.edu> <cha...@mcs.com>
VP in charge of Pittsburgh Flock of the Puck Foundation.
Foundation motto #1: "Puck lives * Puck saves * Puck loves"
Foundation motto #2: "Puck loves everyone, even you!"
Yeah, Puck's a plastic lawn duck. What're you gonna do about it?
ozan s. yigit
Scheme language in order to fullfill GNU extension language goals. I do
not think there is any cause for concern. It is clear that the changes are
not to The Scheme language, which is well defined in an IEEE standard and
Revised^4 Report, The language described in the RMS note may at best be
characterized as a derivative of Scheme, and i doubt it would be called
Scheme, any more than Dylan is called Scheme.
oz
---
a technology is indistinguishable from | electric: o...@nexus.yorku.ca
its implementation. -- Marshall Rose | or o...@sni.ca [416 449 9449]
Mikael Djurfeldt
Scheme seems to be the right thing to choose. Also, the idea of
translating other languages into scheme, thereby allowing the user to
use his/her favourite extension language, is a very nice one.
But, I feel concerned about three of the suggested modifications to
the language. According to RMS "[it] is desirable to support Scheme,
because it is simple and clean." This is indeed one of the great
strengths of Scheme, and it's extremely important not to compromise
it.
In "The GNU extension language plan" we find:
** Extra slots in a symbol, to better support
translating other Lisp dialects into Scheme.
I suspect that you intend to add function and property-list bindings
to symbols. Having symbols associated with multiple slots makes the
language complicated, regardless of their use or implementation.
But, let's take a closer look:
I take it for granted that you're going to use the value-binding for
symbols occuring in the first position of a form. To have another
scheme of evaluation for operators would simply make it a different
language. It would make "Modified Scheme" incompatible with Scheme
and would make the code clumsier.
Apart from the conceptual burden, extra symbol bindings would
complicate the implementation and make symbols "heavier", thus slowing
down code which creates new symbols.
The property list could easily be implemented in scheme as a separate
table.
Assuming that symbols have a function binding, how would you translate
elisp into "Modified Scheme"?
One way to do it is to use a selector `function-binding' to access the
function binding and a mutator `set-function!' for modification.
(Both are special forms which don't evaluate their first argument.)
Then some translations could be:
(* 2 3) --> (* 2 3)
(g 3) --> ((function-binding g) 3)
(Of course one could have the same value in both value and function
bindings of primitive operators, which would make the translation
simpler.)
(defun g (x) (* 5 x)) --> (if (not (defined? x))
(define x #f))
(set-function! x (lambda (x) (* 5 x)))
(funcall 'g 3) --> ((function-binding g) 3)
(funcall func 3) --> ((eval (list 'function-binding func)
(interaction-environment))
3)
(1. I don't know how you are going to implement dynamic variables,
therefore I ignore the dynamic - lexical binding issues in my
examples.
2. I used the eval from the proposal in Jonathan Rees "The Scheme
of Things: The June 1992 Meeting" which can be found in the
Scheme Repository
3. As far as I understand, implementing `function-binding' as a
procedure would put the same kind of restrictions on the
implementation as first class environments do.)
I can't think of any better way to use the extra binding. How are you
going to use it?
In fact, most people intuitively think about symbols as having only
one binding. Because of this most lisp code doesn't use both value
and function bindings simultaneously.
Wouldn't it be a much simpler solution then just to drop the
distinction and manually correct code which use both bindings?
(* 2 3) --> (* 2 3)
(g 3) --> (g 3)
(defun g (x) (* 5 x)) --> (define x (lambda (x) (* 5 x)))
(funcall 'g 3) --> (g 3)
(funcall func 3) --> ((eval func (interaction-environment)) 3)
This obviates the need of the extra function binding.
From the "multiple extension languages" perspective this would of
course lead to an odd dialect of lisp. If this is a big issue there
are still other solutions. E.g., having multiple obarrays opens the
possibility of using a different name space for functions in
translated code...
** A place in a function to record an interactive argument reading
spec.
Such interactive argument specs are particular to certain
applications, like emacs. Why make a change in the Scheme language
when it could be implemented as a separate table? The elisp ->
M. Scheme translator could generate code for maintenance of this
table. Or, `defun' could be implemented as a macro which augments the
table.
** An optional reader feature to convert nil to #f and t to #t,
for the sake of supporting Lisp as well as Scheme.
Alternatively one could define the symbol nil as #f and t as #t,
thereby not changing characteristics of the language.
Mikael Djurfeldt
ozan s. yigit
Syntaxes other than Scheme are just ordinary extensions.
but so is scheme syntax itself. adam shah's architecture does not mention
the fact that most of the scheme syntax is an "extension" on top of a simpler
core language containing not much more than symbols, constants, quote,
define, lambda, begin, if, set!, prim, proc etc.
oz
Assar Westerlund
Scheme language in order to fullfill GNU extension language goals. I do
not think there is any cause for concern. It is clear that the changes are
not to The Scheme language, which is well defined in an IEEE standard and
Revised^4 Report, The language described in the RMS note may at best be
characterized as a derivative of Scheme, and i doubt it would be called
Scheme, any more than Dylan is called Scheme.
It's not Scheme, but wouldn't it be nice if it could be as close to
Scheme as possible?
lvi...@cas.org
There are over 320 programs which currently use Tcl and/or Tk as
their extension language. This includes DejaGNU , a GNU program.
lvi...@cas.org
I do think however that it need not, and perhaps should not, try to
take tk as it is and reproduce it. Instead of trying to shoehorn a
language designed around the Tcl programming philosophy, I would rather
see folk design a similar concept extension designed with the
appropriate language in mind. For instance, I would rather see Dylan's
X not be an Xt or Tk knock off, but something that fits into Dylan's
gestalt. The same for GNUel - make it something designed intentionally
for the language, taking advantages of the strengths and limiting the
weaknesses of the language.
Jeffrey Friedl
|> plain silly. Programming languages are not human languages. If you don't
|> think so, there's always COBOL.
|>
|> The syntactic distance between
|>
|> > if (disbelieve $tom) {
|> ask $mom;
|> }
|> and:
|> > ask $mom if disbelieve $tom;
|>
|> is pretty high. The former is clearly a control structure. The latter is
|> hard to pick out of code.
Again, sorry to jump into what's obviously an ongoing and heated
discussion, but, although I completely agree with most of what Peter says
(particularly the first paragraph above), the ending "the latter is hard to
pick out of code" is a rather silly thing to assert. If you don't know the
language, of course it's hard. If you don't know the language (and it
doesn't resemble something you *do* know, such as COBOL vs. English :-),
anything is hard.
If you _Know_ the language, it's as natural as can be. At least that's my
opinion. That it's not natural for you is yours.
The problem with perl is that it resembles C in many ways. This is a
double-edged sword. It's good in that what is similar is, uh, similar.
It's bad in that what's not, isn't, and it's not always apparent what is
and isn't similar (that make any sense?). Anyone familiar with Japanese
will see the same double-edged sword in romaji, the expression of Japanese
using "English" letters.
The biggest trap of perl resembling C/sed/awk/COBOL/English/whatever is
that it can seduce a beginner. If you program in perl while Thinking in C,
your perl will suck bigtime.
Let me say that again: If you program in perl while Thinking in C, your
perl will suck.
Over the years I've done real, large, non-academic projects in some wild
languages (including FORTH, a nastalgic favorite), so had a pretty wide
range of experience when I first encountered perl in the late 2.x stage.
It took me a *long* time to get to really _Know_ perl (i.e. in the biblical
sense :-). But once I was able to Think in perl, it was magical, just as
when I was finally able to think in Japanese.
*jeffrey*
-------------------------------------------------------------------------
Jeffrey E.F. Friedl <jfr...@omron.co.jp> Omron Corporation, Kyoto Japan
See my Jap/Eng dictionary at http://www.omron.co.jp/cgi-bin/j-e
or http://www.cs.cmu.edu:8001/cgi-bin/j-e
Tom Lord
Peter da Silva writes:
I'm sorry, you've lost me. Either the extension language the user's
interested in is built into the executable, in which case they all
have to be, or it's got to be execed to convert the user's key macro
string into the implementation language, which gives you too much
of a performance hit, or you expose the underlying mechanics of the
implementation language to the user, which is what I thought you were
trying to avoid. What's the fourth alternative?
The ``fourth alternative'' is this: the parser and translator for a
user's favorite syntax is loaded into the running program on demand.
Thus, it is as easy to use as if built-in, but without the associated
costs of building in all languages.
Syntaxes other than Scheme are just ordinary extensions.
-t
--
----
If you would like to volunteer to help with the GNU extension language
project, please write to lo...@gnu.ai.mit.edu.
David J. MacKenzie
> Nonetheless, it turns out that perl is growing *SMALLER*, which is a truly
> remarkable thing for a programming language, if you think about it. The
> v5 release has a grammar that's 50% smaller than v4.0, and v5 are only 33%
> the reserve words that v4 had.
Depends on how you define smaller -- the language might be shrinking,
but the interpreter is getting bigger, at least on BSD/386:
text data bss dec hex
405504 45056 28960 479520 75120 /usr/obj/export/src/usr.local/bin/perl5.000/miniperl
335872 49152 40876 425900 67fac /usr/contrib/bin/perl
Kevin K. Lewis
>>> "Paul" == egg...@twinsun.com (Paul Eggert) wrote:
Paul> Isn't the choice of name obvious?
Paul> ``GNU Extension Scheme''.
Paul> We can call it ``escheme'' for short.
No no no ... it should called `gel', particularly if it's going to be
used to "glue" all the diverse GNU applications together. :-)
- Mike W.
Hey, I like that! gel == GNU Extension Language? (or Glue Extension
Languge? Or perhaps GlNUe Extension Language?) Pronounced `jel'? I
like that a lot!
--
Kevin K. Lewis | My opinions may be unreasonable
lew...@aud.alcatel.com | but such is the voice of inspiration
Peter da Silva
> We can call it ``escheme'' for short.
gescheme
Has a sort of middle-european feel to it. A nice cuddly sort of name.
Lee Iverson
In article <MIKEW.94O...@gopher.dosli.govt.nz> mi...@gopher.dosli.govt.nz (Mike Williams) writes:
>>> "Paul" == egg...@twinsun.com (Paul Eggert) wrote:
Paul> Isn't the choice of name obvious?
Paul> ``GNU Extension Scheme''.
Paul> We can call it ``escheme'' for short.
No no no ... it should called `gel', particularly if it's going to be
used to "glue" all the diverse GNU applications together. :-)
- Mike W.
Hey, I like that! gel == GNU Extension Language? (or Glue Extension
Languge? Or perhaps GlNUe Extension Language?) Pronounced `jel'? I
like that a lot!
How about GLU, the ``GNU Language Utility'' (given that it is really
intended to be a sort assembly language underneath a possible variety
of faces) or the ``GNU Lisp Utility''.
We must appreciate the importance (perhaps) of retaining a hard G ;-)
--
-------------------------------------------------------------------------------
Lee Iverson SRI International
le...@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
(415) 859-3307
Thomas M. Breuel
|Paul> Isn't the choice of name obvious?
|Paul> ``GNU Extension Scheme''.
|Paul> We can call it ``escheme'' for short.
|
| No no no ... it should called `gel', particularly if it's going to be
| used to "glue" all the diverse GNU applications together. :-)
The GNU extension language should, of course be called "TINT":
TINT Is Not TCL
Thomas.
Jurgen Botz
>> Since these violations of the standard are minor, if the string
>> "Scheme" shows up in the name, I think that will not be too great an
>> abuse of terminology.
>
>Isn't the choice of name obvious?
I don't think it should have "Scheme" in the name unless it can run
R4RS programs, which it can't if (for example) (eqv? '() #f). I'm not
opposed to a language with the proposed 'extensions' to Scheme, but
that language is not Scheme.
Some people have been writing 'GNUel' to refer to the proposed
language in this thread... I propose 'gnudel'---short 'e', rhymes with
"noodle"---the 'd' is for 'dynamic' which is nice because this is a
salient feature of all the extension languages discussed and makes the
acronym pronounceable.
Peter da Silva
Raul Deluth Miller <rock...@nova.umd.edu> wrote:
> Peter da Silva:
> . What's the fourth alternative?
> Dynamically loaded libraries. Possibly configured on a per-user
> basis.
That'd work. Would be a bummer if you saved your configuration when you had
your environment in "scheme mode" and then tried to reload your config file
in "Rush mode" though. Make sure your API supports having multiple DLLs
loaded at once.
(Hrm. GCC is a bit big for a DLL)
Darin Johnson
> used to "glue" all the diverse GNU applications together. :-)
No no. GSP. GNU Spackling Putty.
(although I think the "GNU Extension Scheme" has a nice subtlety to it)
--
Darin Johnson
djoh...@ucsd.edu
Ensign, activate the Wesley Crusher!
Darin Johnson
> English language speaker "do this if that" is very natural.
Odd, I'm a native English speaker, and I think "if this, do that"
is very natural as well.
Of course, in other languages, "this if, that do" is natural,
should we also support that sort of thing?
--
Darin Johnson
djoh...@ucsd.edu
Where am I? In the village... What do you want? Information...
Juergen Wagner
[deleted]
>I'm sorry, but putting a feature in because it's english like is just
>plain silly. Programming languages are not human languages. If you don't
>think so, there's always COBOL.
>
>The syntactic distance between
>
>> if (disbelieve $tom) {
> ask $mom;
> }
>
>and:
>
>> ask $mom if disbelieve $tom;
>
>is pretty high. The former is clearly a control structure. The latter is
>hard to pick out of code.
I agree in that the syntactic differences are pretty clear.
However, you're mixing syntax and semantics. Depending on the semantics
attached to the two statements, you can have *both*, *one*, or *none*
representing a control structure. In a rule-based system, the first
form is quite common and only declaratively formulates a rule. The
control structure comes in through the rule interpreter/inference
mechanism. Therefore, this is just a bad example.
All languages (including COBOL :-) just happen to be similar to a
context-free language which might be mistaken as a subset of English
with some mathematical notation (except for LISP which is natural
language with parentheses :-)). It is the nature of programming
languages that they cannot be and "are not human languages". In fact,
they don't have to.
--Juergen Wagner
Juergen...@iao.fhg.de
gan...@csli.stanford.edu
Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
<a href = http://www.iao.fhg.de/Public/leute/jrw-en.html>J. Wagner</a>
Paul Eggert
> Since these violations of the standard are minor, if the string
> "Scheme" shows up in the name, I think that will not be too great an
> abuse of terminology.
Isn't the choice of name obvious?
``GNU Extension Scheme''.
Darin Johnson
> replacement for Tcl/Tk (and I believe that any Scheme or CL serious
> attempt would just breeze through) should provide an equivalent of Tk.
This has already been done - Scheme/TK exists. I think there was a
Perl and Python port as well.
--
Darin Johnson
djoh...@ucsd.edu
"I wonder what's keeping Guybrush?"
Matthias Blume
No. This only leads to confusion and subtle bugs. If it isn't
Scheme, then it should be different enough for every real Scheme to
cough up and complain about a program in that new language on first
sight. Otherwise we just add one more to the list of slightly
incompatible Scheme implementations...
--- Scheme talk --- only for the comp.lang.scheme audience ----
Many of RMS' suggestions of what needs to be changed actually
constitute inverse progress. It took a lot of time and arguing to
finally get over the non-distinction of #f and (). Now RMS walks in
and tries to tell us: ``Well folks, nice work -- but let's go back to
square one.'' I don't think so!
What are ``multiple slots'' in a symbol? I'm not even aware of one
single slot in a symbol! Multiple obarrays? Oh -- I see -- he wants
a module system. Good point!
Fluid-let? What for? (I'm aware of the fact that there are many
people who seem to think that fluid-let is indispensable. I disagree
with this point of view. Establishing error-handlers,
interrupt-handlers and so on can be done with procedures similar to
WITH-INPUT-FROM-FILE. I don't think we should sacrifice strict lexical
scoping for a few special cases.)
Distinguishing between upper-case and lower-case in symbols. Yes,
please! But we have been through that argument, haven't we?
Powerful catch and throw? It's there, and it's called
CALL-WITH-CURRENT-CONTINUATION. If you don't want to confuse your
``average programmer'' with the word ``continuation'' then just wrap
call/cc into some macros:
(define-syntax catch
(syntax-rules ()
((_ c exp ...)
(call-with-current-continuation (lambda (c) exp ...)))))
(define-syntax throw
(syntax-rules ()
((_ c val) (c val))))
Ok, let me step down from this soapbox...
--
-Matthias
Logan Ratner
>But there's always been this basic assumption: that you don't add a feature
>just because it sounds good. You add it because you need it. If there's two
>ways of doing something you use the one that avoids complicating the language.
>The classic example in Perl is the postfix if statement. It doesn't add
>any capability to the language, and it confuses new users. In an extension
>language that's a bad thing... because most of the time most users are
>new users, because they're not using the language to do a job, they're
>using it to configure the tool that does the job.
Well, when I was a very new user to perl (I still consider myself a 'new' user
a year later) one of the most attractive, clear, and anti-confusing features
was the ability to write conditionals the way I would speak them. For an
English language speaker "do this if that" is very natural.
Now, I have an E.E background. I can do conditionals on a gate-logic level,
and I've programmed C and C++ for years, so I knew prefix syntax, and I still
wasn't confused. In fact I'd argue that perl is less confusing because you
can write "a unless b" and C more confusing because you can't, and the
condition always gets emphasized over the action.
--
Logan Ratner | rat...@rice.edu | It is not funny that a man should die, but
CRPC/CITI | tinker | it is funny that he should be killed for so
Rice Univ. | tailor | little, and the coin of his death should be
Houston TX | cybernaut | what we call civilization - R. Chandler
Mark Hamburg
schw...@roke.cse.psu.edu (Scott Schwartz) wrote:
> sm...@sytex.com (Scott McLoughlin) writes:
> For real tightness and power in a scripting language, I (and many
> others) would recommend using "Forth" where these things matter -
>
> Engineering is everything. Nothing is lean and mean unless its
> implementors are powerfully motivated to make it so. Anyone remember
> Turbo Pascal version 2.0? It was a good quality implementation of
> pascal in something like 24K, and it compiled to native code at
> hundreds of lines per second on very slow hardware.
Or look at ETH Zurich's work on Oberon.
Mark
Peter da Silva
Raul Deluth Miller <rock...@nova.umd.edu> wrote:
> Peter da Silva:
> . from "define_key_macro".
> Depending on the definition of define_key_macro. [Some definitions
> of define_key_macro wouldn't expose any of the details of the
> extension language.]
I'm sorry, you've lost me. Either the extension language the user's
interested in is built into the executable, in which case they all
have to be, or it's got to be execed to convert the user's key macro
string into the implementation language, which gives you too much
of a performance hit, or you expose the underlying mechanics of the
implementation language to the user, which is what I thought you were
trying to avoid. What's the fourth alternative?
Raul Deluth Miller
. What's the fourth alternative?
Dynamically loaded libraries. Possibly configured on a per-user
basis.
--
Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q
<rock...@nova.umd.edu> y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e<n
NB. public e, n, y
x -: n&|&(*&y)^:d 1 NB. 1=(d*e)+.p*&<:q
Raul Deluth Miller
<BLUME.94O...@aleph.cs.princeton.edu>: many of the "gnu
extension language enhancements" would be best treated as some other
language implemented in scheme.
Which leads me to wonder about how to contribute to the current
effort. What is considered to be a contribution? Are these sorts of
implementation design issues still being considered?
I'm interested in the effort, but not sure how I would fit in with the
existing effort. I'm not even sure how to ask about the existing
effort.
Where do things stand?
matthew green
> For an
> English language speaker "do this if that" is very natural.
Odd, I'm a native English speaker, and I think "if this, do that"
is very natural as well.
what is so odd about it? i'm a native `english' speaker, and *both*
are natural to me.
Of course, in other languages, "this if, that do" is natural,
should we also support that sort of thing?
depends if larry speaks those languages or not.. ;-)
.mrg.
Paul Wilson
Tom Lord <lo...@x1.cygnus.com> wrote:
>
> ozan s. yigit writes:
>
> The language described in the RMS note may at best be characterized as
> a derivative of Scheme, and i doubt it would be called Scheme, any
> more than Dylan is called Scheme.
I have to sort-of-agree with Oz here. I think rms has accidentally
broken the GNU language w.r.t. Scheme compatibility. (But presumably
it's not too late to avoid that mistake.)
>The GNU language (whatever it is called) will be very nearly a
>superset of standard Scheme. Only two kinds of standard Scheme
>program won't work with the GNU language without modification:
>
> 1. Those that depend on the distinction between '() and #f.
> 2. Those that depend on the case insensativity of Scheme identifiers.
>
>It would not be hard to provide a reader option to control case
>sensativity. In that case, standard programs from class 2 would work
>perfectly well with the GNU language although they might have trouble
>communicating with other packages that take advantage of case
>sensativity.
I don't yet know if this is right, but I'm willing to entertain the idea.
However...
>R4RS itself gives warning that some implementations conflate '() and
>#f. So, there is precendent for discouraging people from writing
>programs that depend on the distinction.
I think you've misread the R4RS. The passage in question should say
that there are obsolete, broken old implementations that do not conform
to the R4RS in this regard. Please have a look at section 6.1 (Booleans).
It says (all-caps added for emphasis).
Of all the standard Scheme values, only #f counts as false in conditional
expressions. Except for #f, all standard Scheme values, including #t,
pairs, THE EMPTY LIST, symbols, numbers, strings, vectors, and procedures,
count as true.
It goes on to give examples of things that evaluate to #t and #f:
(not #t) ==> #f
(not 3) ==> #f
(not (list 3)) ==> #f
(not #f) ==> #t
(not '()) ==> #f
(not (list)) ==> #f
(not 'nil) ==> #f
I think this is important enough to reconsider the decision to be incompatible.
My impression is that the R4RS authors intentionally made #f and '() REQUIRED
to be distinct objects in part to support a programming style where an
empty list means a list of zero objects, but #f means the absence of any list
(or whatever) at all. E.g., you can compute a set of zero things, or you
can fail to compute a usable answer. I used this idiom regularly in
Scheme programs, and suspect other people do too. An implementation that
reverts to pre-R4RS days may break a significant fraction of conforming
R4RS or IEEE Scheme programs.
Another significant consideration is that the separation of boolean types
from list types is important if you want to be upward-compatible with
extended Schemes that support type declarations, e.g., for interoperability
with Dylan.
Language ideology-wise, I think the conflation of false and nil is
generally viewed as a category mistake, even if it's one that's useful
sometimes.
Practically speaking, it has important implications for compatibility
with existing standards and code, and with future extended languages.
Personally, I'm very interested because we're buiding a highly
portable extended Scheme that might end up being the big brother of
a GNU extension language, for larger and more performance-critical
applications. (It's got objects, threads, sockets, and a real-time
garbage collector, and compiles to C without losing proper tail
recursion or the ability to have full continuations. We're also working
on a portable GUI which is based on the VIBRANT package, so it should
work under UNIX, Windows and the Mac OS.) It may eventually end up being
a full Dylan implementation as well, supporing interoperability between
Dylan and Scheme code. This is possible because Dylan is semantically
almost a superset of Scheme, despite major syntactic differences.
I think a GNU extension language based on Scheme could be just the
boost that Scheme needs right now, and a nice encouragement to Dylan
implementors to support Scheme.
As for the other changes, please let us know the reasoning behind them.
I agree with an earlier posting that you don't need a property list
slot to efficiently support property lists. (A separate table can be
plenty efficient for an interpreted system, or even a high-performance
system. Our symbols have a field that holds the hash value of the
name string, so you don't have to compute that value each time you
hash into a table.
I assume that you're not going to implement a separate function
namespace for Scheme code. (Scheme programs freely use first-class
procedures, and that is much more awkward with separate namespaces;
it would probably break the large majority of nontrivial Scheme programs,
and half the trival ones too.) What is your plan for using the extra
binding slots?
--
| Paul R. Wilson, Computer Sciences Dept., University of Texas at Austin |
| Taylor Hall 2.124, Austin, TX 78712-1188 wil...@cs.utexas.edu |
| (Recent papers on garbage collection, memory hierarchies, and persistence |
| are available via ftp from cs.utexas.edu (128.83.139.9), in pub/garbage.) |
Mike Williams
Paul> Isn't the choice of name obvious?
Paul> ``GNU Extension Scheme''.
Paul> We can call it ``escheme'' for short.
No no no ... it should called `gel', particularly if it's going to be
used to "glue" all the diverse GNU applications together. :-)
- Mike W.
Aubrey Jaffer
In article <LORD.94Oc...@x1.cygnus.com>,
Tom Lord <lo...@x1.cygnus.com> wrote:
>R4RS itself gives warning that some implementations conflate '() and
>#f. So, there is precendent for discouraging people from writing
>programs that depend on the distinction.
I think you've misread the R4RS. The passage in question should say
that there are obsolete, broken old implementations that do not conform
to the R4RS in this regard. Please have a look at section 6.1 (Booleans).
It says (all-caps added for emphasis).
Of all the standard Scheme values, only #f counts as false in conditional
expressions. Except for #f, all standard Scheme values, including #t,
pairs, THE EMPTY LIST, symbols, numbers, strings, vectors, and procedures,
count as true.
I think this is important enough to reconsider the decision to be incompatible.
My impression is that the R4RS authors intentionally made #f and '() REQUIRED
to be distinct objects in part to support a programming style where an
empty list means a list of zero objects, but #f means the absence of any list
(or whatever) at all. E.g., you can compute a set of zero things, or you
can fail to compute a usable answer. I used this idiom regularly in
Scheme programs, and suspect other people do too. An implementation that
reverts to pre-R4RS days may break a significant fraction of conforming
R4RS or IEEE Scheme programs.
It really is no big deal to write Scheme code which works either way.
By the way, here is a little example from the mother of all Schemes,
MIT Scheme - the implemenation which Profs. Sussman and Abelson use:
================================================================
Scheme Microcode Version 11.148
MIT Scheme running under HP-UX
Type `^C' (control-C) followed by `H' to obtain information about interrupts.
^L
Scheme saved on Monday October 24, 1994 at 9:47:41 PM
Release 7.4.0 (alpha)
Microcode 11.148
Runtime 14.166
;Loading "/zu/jaffer/.scheme.init"
;Loading "/zu/jaffer/slib/require.scm" -- done -- done
1 ]=> (eq? '() '#f)
;Value: #t
================================================================
So is it an "obsolete, broken old implementation"?
Dave Gymer
djoh...@elvis.ucsd.edu writes:
>> For an
>> English language speaker "do this if that" is very natural.
>Odd, I'm a native English speaker, and I think "if this, do that"
>is very natural as well.
Whilst I agree with that, I do like Perl's "do that unless this"; I
think it's nice to use that form for exceptional circumstances so that
the condition doesn't hide the normal flow of things.
-- Dave
Tom Lord
Raul D. Miller asks:
Which leads me to wonder about how to contribute to the current
effort. What is considered to be a contribution? Are these sorts of
implementation design issues still being considered?
I'm interested in the effort, but not sure how I would fit in with the
existing effort. I'm not even sure how to ask about the existing
effort.
Where do things stand?
Here are some answers:
* How can I contribute to the project?
To volunteer your time either for hacking or writing, you can write
to lo...@gnu.ai.mit.edu. A very promising list of volunteers is
already forming. I think there is a chance the project can go quite
quickly if this keeps up.
* Where do things stand now?
I am currently putting together a task list. During the week of
31-Oct-94 I'll be sending the task list to all the volunteers and
organizing the initial division of labor.
The first hacking step of the project, which must precede all
others, will be to rename some of the identifiers in the SCM source,
to combine the SCM and SCM autoconf distributions, and to make some
slight amendments to the Makefile.
The most immediate goal of this is to make a standard GNU
distribution of SCM that compiles to a namespace-friendly library.
Included with this distribution will be a header file of CPP defines
for the old identifier names; its purpose will be to enable existing
SCM extensions to continue to work.
* Can we convince you to change the design?
Compelling, pragmaticly oriented arguments may be convincing. They
should probably be made to lo...@gnu.ai.mit.edu rather than carried
on endlessly in netnews.
For practical reasons, we won't be engaging in prolonged debate on
any point. Informed critiques are very welcome, but please don't
count on an engaging reply; there isn't enough time to reply to
every critique that comes in.
Perhaps the best way to influence the design is with code. If you
don't like the way we plan to implement some feature, and you can
provide that feature in a better way, you'll find that we have
trouble arguing against code that works. If your way really is
better, we'll gratefully accept the code, and voila -- the design is
changed. (But before going off the deep end, it is probably a good
idea to understand all the reasons the design is as it is; if you
accidently ignore some of our requirements, your code may not be
useful to the project.)
* Where can I ask about the project?
You can send inquiries to lo...@gnu.ai.mit.edu, but please understand
that not all inquiries receive immediate or even eventual replies.
There is simply not enough time.
As new versions of the language are released, announcements will be
posted to at least the newsgroups comp.lang.scheme and
gnu.misc.discuss, and to the mailing list info...@prep.ai.mit.edu.
Eventually, I hope a volunteer can start a FAQ for the project.
Bryan Oakley
For information on a good implementation of tk with perl4 see
<A HREF="http://www.ira.uka.de/IRA/SMILE/tkperl/">
http://www.ira.uka.de/IRA/SMILE/tkperl/</A>
Note: this is not the same tkperl that gets the lions share of
attention in this group. I sure wish one of those two camps would
change the name of their product... though come to think of it, one
is tkperl and the other is tkperl5...
Ken Mayer
Darin Johnson <djoh...@elvis.ucsd.edu> wrote:
>> For an
>> English language speaker "do this if that" is very natural.
>
>Odd, I'm a native English speaker, and I think "if this, do that"
>is very natural as well.
>
>Of course, in other languages, "this if, that do" is natural,
>should we also support that sort of thing?
It depends upon what's important.
next if (/pat/);
(/pat/) && next;
if (/pat/) {
next;
}
All do pretty much the same thing, but when reading it, the emphasis is
on different parts of the expression. It makes it more "logical" for the
author and more readable for a reader. Perl doesn't care one way or the
other. Perl is flexible that way.
--
Ken Mayer kma...@mrj.com Words ought to be a
MRJ, Inc. (703) 277-1722 little wild for they
10560 Arrowhead Drive (703) 385-4637 fax are the assault of
Fairfax, Virginia 22030-7305 thoughts on the
USA unthinking.
*** NOTE ADDRESS & PHONE CHANGE EFFECTIVE 11/18/94 *** -- John Maynard Keynes
Tom Christiansen
:It's been pointed out to me that Perl 5 has apparently considerably tighter
:syntax and semantics than the rather ad-hoc Perls of yesteryear,
Thanks, Peter. See Larry's release notice posted elsewhere in these
language areas for details, and/or glance at my implementation of a
Patricia trie in perl, recently posted elsewhere in this thread.
:I still think that all other things being equal a tighter, smaller language
:is better than a larger and more complicated one,
[]
:...I'd rather the winner be something more minimalist...
I'd rather it were more usable. :-)
Do you want big languages and little programs or vice versa?
Nonetheless, it turns out that perl is growing *SMALLER*, which is a truly
remarkable thing for a programming language, if you think about it. The
v5 release has a grammar that's 50% smaller than v4.0, and v5 are only 33%
the reserve words that v4 had. Functions are migrating out of the core
language into libraries, particularly now that this can be done cleanly,
portably, and transparently. At the same time, it has gained a great deal
to provide for safe, flexible, portable, and extensible programming of
more serious programs than were hitherto reasonably attempted.
I guess all we need is a elisp-to-perl (or is that scheme-to-perl)
translator now and even rms will be happy. :-) (Someone else reports
working on a tcl-to-perl translator already, but progress is slow.)
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
As Zeus said to Narcissus, "Watch yourself."
Scott McLoughlin
> I still think that all other things being equal a tighter, smaller language
> is better than a larger and more complicated one, and all the enhancements
> to Scheme suggested by RMS in <941019042...@mole.gnu.ai.mit.edu> are
> a bit worrisome. If this comes down to a fight between Sun and the FSF my
Howdy,
Ummm, RMS's proposed extensions don't seem to "bloat" Scheme
too much IMHO. Scheme itself is a very small language. Adding fluid
variables was done in Oaklisp, so there's precedent. Exception
handling and catch/throw are simply first class exits with dynamic
extent, which has also been researched, implemented, etc. Multiple
obarrays are simply "packages" - not rocket science.
Anyway, none of these seems "big" in terms of code size and/or
runtime space requirements. As for "flexible string manipulation
functions" and "access to all or most of the Unix system calls", these
will add to the "footprint" of the language. I guess it's a tradeoff -
multiple incompatible "user level" extensions vs. built in convenience
(and perhaps some economy achievable only by "built-ins"). It's a
"judgement call".
I don't, OTOH, see why not we couldn't just have a simple
#ifdef compilation option to exclude various features from the
language, e.g. #undef GXL_UNIXCALLS or whatever. Same for "expect"
interface (what is expect anyway?).
I would guess in the general case, the lion's share of apps
using the language will have oodles of giant GUI extensions, user
i/o validation, etc. and one average size 8bit+ color image will have
a footprint bigger than the whole language implementation anyway! For
real tightness and power in a scripting language, I (and many others)
would recommend using "Forth" where these things matter - but I
wouldn't sick Forth on users of a "general purpose" scripting language
(I'm not religious).
Anyway, when can we get it ;-) Also, I'll repeat my oft'
expressed desire to see DOS/Windoze/Win32 versions.
=============================================
Scott McLoughlin
Conscious Computing
=============================================
Peter da Silva
> What's wrong with taking some existing implementation, like STk's interpreter,
> and adding a modicum of string and O/S functions? If Tcl is an unholy cross
> of Lisp and Awk, this is sounding like some similarly sanctified marriage of
> Lisp and Perl.
It's been pointed out to me that Perl 5 has apparently considerably tighter
syntax and semantics than the rather ad-hoc Perls of yesteryear, so I'll see
if I can come up with a better analogy. It's a sad day when ones favorite
bad examples pass by the wayside. (HHOS)
I still think that all other things being equal a tighter, smaller language
is better than a larger and more complicated one, and all the enhancements
to Scheme suggested by RMS in <941019042...@mole.gnu.ai.mit.edu> are
a bit worrisome. If this comes down to a fight between Sun and the FSF my
money wouldn't be on Sun (not after they dropped NeWS and OpenLook), and
I'd rather the winner be something more minimalist...
Ken Mayer
>>> rms wrote:
Sometimes developers choose a language because they like it. But not
always. Sun recently announced a campaign to "make Tcl the universal
scripting language." This is a campaign to convince all the
developers who *don't* prefer Tcl that they really have no choice.
The idea is that each one of us will believe that Sun will inevitably
convince everyone else to use Tcl, and each of us will feel compelled
to follow where we believe the rest are going.
<<<
The threat that TCL will take over the world is improbable. Sun has not
been completely successful in imposing standards. (I certainly don't feel
compelled. Just look at all the sites that haven't adopted NIS+ for
example.) Why should anyone think that this attempt will be any better?
Sun certainly can not prohibit other scripting languages from running on
their systems. In addition, they are not the only game in town. Far from
it; DEC, HP, IBM are also in the OS and workstation business. If they
don't choose TCL as the "universal scripting language" then Sun's
"universe" will be very small indeed.
I think healthy competition is good, so I welcome GNUel (rhymes with
"jewel" -- gosh it even looks like *.el !) into this arena. The best thing
that could happen is that the wizards build a better mouse trap.
--
Ken Mayer
MRJ, Inc. (703) 385-0722
10455 White Granite Drive (703) 385-4637 fax
Oakton, Virginia 22124 kma...@mrj.com
USA "Not now, I'm spanking my inner child."
Kevin K. Lewis
Some people have been writing 'GNUel' to refer to the proposed
language in this thread... I propose 'gnudel'---short 'e', rhymes with
"noodle"---the 'd' is for 'dynamic' which is nice because this is a
salient feature of all the extension languages discussed and makes the
acronym pronounceable.
Do you suppose that it might become en vogue to write spaghetti code
in gnudel?
Sorry.
--
Kevin K. Lewis | My opinions may be unreasonable
lew...@aud.alcatel.com | but such is the voice of inspiration
Marcus Daniels
>Scheme Microcode Version 11.148
>MIT Scheme running under HP-UX
>Type `^C' (control-C) followed by `H' to obtain information about interrupts.
>^L
>Scheme saved on Monday October 24, 1994 at 9:47:41 PM
> Release 7.4.0 (alpha)
> Microcode 11.148
> Runtime 14.166
>;Loading "/zu/jaffer/.scheme.init"
>;Loading "/zu/jaffer/slib/require.scm" -- done -- done
>1 ]=> (eq? '() '#f)
>;Value: #t
>================================================================
>So is it an "obsolete, broken old implementation"?
Ha ha! Read on!
Received: from yale by MC.LCS.MIT.EDU 28 Jan 86 13:47:21 EST
Received: by Yale-Bulldog.YALE.ARPA; 28 Jan 86 06:22:59 EST (Tue)
Date: 28 Jan 86 06:22:59 EST (Tue)
From: <ram%YALE...@YALE.ARPA>
Message-Id: <860128112...@Yale-Bulldog.YALE.ARPA>
Subject: Of growing code and diminishing hacks...
To: t-disc...@YALE.ARPA, sch...@mit-mc.arpa
A SHORT BALLAD DEDICATED TO THE GROWTH OF PROGRAMS
==================================================
by
Ashwin Ram
This is a tale of a sorry quest
To master pure code at the T guru's behest
I enrolled in a class that appealing did seem
For it promised to teach fine things like T3 and Scheme
The first day went fine; we learned of cells
And symbols and lists and functions as well
Lisp I had mastered and excited was I
For to master T3 my hackstincts did cry
I sailed through the first week with no problems at all
And I even said "closure" instead of "function call"
Then said the master that ready were we
To start real hacking instead of simple theory
Will you, said he, write me a function please
That in lists would associate values with keys
I went home and turned on my trusty Apollo
And wrote a function whose definition follows:
(cdr (assq key a-list))
A one-liner I thought, fool that I was
Just two simple calls without a COND clause
But when I tried this function to run
CDR didn't think that NIL was much fun
So I tried again like the good King of yore
And of code I easily generated some more:
(cond ((assq key a-list) => cdr))
It got longer but purer, and it wasn't too bad
But then COND ran out and that was quite sad
Well, that isn't hard to fix, I was told
Just write some more code, my son, be bold
Being young, not even a moment did I pause
I stifled my instincts and added a clause
(cond ((assq key a-list) => cdr)
(else nil))
Sometimes this worked and sometimes it broke
I debugged and prayed and even had a stroke
Many a guru tried valiantly to help
But undefined datums their efforts did squelch.
I returneth once more to the great sage of T
For no way out of the dilemma I could see
He said it was easy -- more lines must I fill
with code, for FALSE was no longer NIL.
(let ((val (assq key a-list)))
(cond (val (cdr val))
(else nil)))
You'd think by now I might be nearing the end
Of my ballad which seems bad things to portend
You'd think that we could all go home scot-free
But COND eschewed VAL; it wanted #T
So I went back to the master and appealed once again
I said, pardon me, but now I'm really insane
He said, no you're not really going out of your head
Instead of just VAL, you must use NOT NULL instead
(let ((val (assq key a-list)))
(cond ((not (null? val)) (cdr val))
(else nil)))
My song is over and I'm going home to bed
With this ineffable feeling that I've been misled
And just in case my point you have missed
Somehow I preferred (CDR (ASSQ KEY A-LIST))
:-)
==================================================
Stefan Monnier
Wayne A. Christopher <fau...@remarque.berkeley.edu> wrote:
> It's very simple:
> 1. A decent extension language will probably need "eval".
Yes. Even though scheme didn't have it for a long time.
It's useful sometimes, but not too often.
> 2. Eval must take statements in the language the user writes.
Wrong assumption !
Eval is pretty rare. And building source code on the fly is a pain.
A library to build compiled ocde will anyway be written for the
compilers, so why not make it pretty and user useable to build up code
on the fly and call eval on it afterwards ?
the following points are of course not valid any more :-)
> 3. The extension language runtime must understand (either to interpret
> or to compile) this language.
> 4. Therefore it is impossible to completely separate the user-visible extension
> language from the internal extension language.
Stefan
Stefan Monnier
> Using an arbitrary syntax to avoid favoritism:
>
> display "Enter keystroke: "
> read keystroke
> display "Enter macro: "
> read macro
> define_key_macro %keystroke %macro
>
> Now, if you're using an external compiler you need to run that compiler
Why ?
Is elisp visible from its keyboard macro facility ?
> Now suppose you're reading these from an X resource at startup. You're going
> to have to call the compiler for *each* resource in turn.
First, I don't see why use X resources for that purpose (but then, why
not). Second, these resources might be generated by a compiler !
Stefan
Stefan Monnier
Mike McDonald <m...@Titan.ESS.Harris.com> wrote:
> Because you can't maintain the system then. If your users get to go off and
> pick any tranlator they want, you'll have to learn every available language
> inorder to debug your user's scripts. I don't believe that it is practical for
> you to expect to be able to debug a script written is some unknown language that
> was machine translated into scheme, or forth, or whatever. (I've argued this same
> point with the Dylan people to no good.)
>
> If you're not going to let them pick, then you just as well force them to use
> the same language as you picked.
No ! you can just announce them that if they don't use language X, then
you don't provide any support: no problem for you and more flexibility
for the experienced user !
Your reaction is bit the same as our syadmin's: he put the whole init
files in /etc/csh.{login,cshrc}. Claiming that he doesn't support
users who change their init files. But then, in order not to use his
files I had to recompile my own tcsh version which doesn't source
/etc/csh.*.
Stefan
Wayne A. Christopher
Tim Smith <t...@u.washington.edu> wrote:
> Everyone seems to be assuming that the extension language built into the
> program must be the same as the extension language that the user sees.
> Yet this is not so. What would be wrong with building in something that
> is small, simple, and fast (e.g., Forth), and then providing tools to
> compile something else to that (e.g., a gcc backend that generates Forth
> instead of assembly)?
It's very simple:
1. A decent extension language will probably need "eval".
2. Eval must take statements in the language the user writes.
3. The extension language runtime must understand (either to interpret
or to compile) this language.
4. Therefore it is impossible to completely separate the user-visible extension
language from the internal extension language.
Of course, one could provide the user-visible language as a dynamically-
loadable interpreter or compiler, but this would preclude anything as
heavy-weight as running gcc for every eval statement.
Wayne
br...@liverpool.ac.uk
> I assume that you're not going to implement a separate function
> namespace for Scheme code. (Scheme programs freely use first-class
> procedures, and that is much more awkward with separate namespaces;
> it would probably break the large majority of nontrivial Scheme
> programs, and half the trival ones too.) What is your plan for
> using the extra binding slots?
I think the reasoning behind several of the changes is to make this
new language pretty much a superset of emacs-lisp, so that emacs can
use the same extension language.
Emacs lisp programs really do use the same symbol for values and
functions, and certainly use nil to represent false.
From the comments of several people, it looks as though some of these
decisions are mistakes: the emacs lisp code should be changed.
In particular, it looks as though the conflation of #f and '(), and
keeping the multiple slots in symbols (especially the function slot)
are bad ideas for compatibility with scheme. I can't see any problem
with dynamic variables and case sensitivity: presumably the first has
been done before, and the second is surely not going to cause
problems?
--
Bruce Institute of Advanced Scientific Computation
br...@liverpool.ac.uk University of Liverpool
Barry A. Warsaw
>>>>> "bruce" == bruce <br...@liverpool.ac.uk> writes:
bruce> Emacs lisp programs really do use the same symbol for
bruce> values and functions, and certainly use nil to represent
bruce> false.
bruce> From the comments of several people, it looks as though
bruce> some of these decisions are mistakes: the emacs lisp code
bruce> should be changed.
Ha! Do you know how much elisp that will break? I can't imagine this
ever happening.
-Barry
Peter da Silva
Marco Antoniotti <mar...@mosaic.nyu.edu> wrote:
> In all the discussion I have seen about Tcl, I still have to see the
> argument that actually would clarify the wide acceptance that Tcl/Tk
> has gained.
Well, I started using Tcl before Tk even existed outside sprite. Why?
Because at 40k Tcl was the only extension language out there that was
practical to use on Xenix-286, and because it's still the easiest language
to suck existing programs in as extensions (because they're already
written to parse argv). It also let me write significant scripts on a
machine for which Perl was too large to compile, and the shell was too
slow. It turned a tortoise of a development environment into something
useful.
Tcl is still about the smallest useful extension language. I know it's
politically incorrect to worry about code size these days, but I come from
simpler times when megs were megs and ... oh, never mind ...
Scott Draves
In article <BLUME.94O...@aleph.cs.princeton.edu> bl...@aleph.cs.princeton.edu (Matthias Blume) writes:
Matthias> It took a lot of time and arguing to finally get over the
Matthias> non-distinction of #f and (). Now RMS walks in and tries to
Matthias> tell us: ``Well folks, nice work -- but let's go back to
Matthias> square one.'' I don't think so!
the purported reason is to support elisp. but since elisp makes
extensive use of dynamic scope, it'll have to run through a
compiler/translater anyway. such a compiler can insert the null?
calls in the right places, thus leaving the scheme free of the pun.
can someone who knows explain why they should be the same?
Matthias> What are ``multiple slots'' in a symbol? I'm not even aware
Matthias> of one single slot in a symbol! Multiple obarrays? Oh -- I
Matthias> see -- he wants a module system. Good point!
yea, i would hate to see a symbol-based module system. scheme48's
module system looks good, why not adopt it?
Matthias> Fluid-let? What for? (I'm aware of the fact that there are
Matthias> many people who seem to think that fluid-let is
Matthias> indispensable. I disagree with this point of view.
i want fluid-let. it is the basis (with call/cc) of exceptions, plus
other things like *print-level*, *stdout*, etc. it comes in handy at
the user level as well, for the same reasons.
Matthias> Establishing error-handlers, interrupt-handlers and so on
Matthias> can be done with procedures similar to WITH-INPUT-FROM-FILE.
if it comes in useful for the implementation, it's useful for the user
as well.
Matthias> I don't think we should sacrifice strict lexical scoping for
Matthias> a few special cases.)
i very strongly disagree. this looks like the "protect the programmer
from herself" attitude. no no no no no.
Matthias> Distinguishing between upper-case and lower-case in symbols.
Matthias> Yes, please! But we have been through that argument,
Matthias> haven't we?
i'm all for this one as well.
--
mosquito
tick
leech
Michael R. Blair
Jaffer> Newsgroups: comp.lang.scheme,comp.lang.misc,gnu.misc.discuss
Jaffer> Date: 26 Oct 1994 03:50:25 GMT
Jaffer> Organization: MIT Artificial Intelligence Lab
Jaffer> Lines: 52
Jaffer> References: <941019042...@mole.gnu.ai.mit.edu>
Jaffer> <MDJ.94Oc...@sanscalc.nada.kth.se>
Jaffer> <OZ.94Oct...@nexus.yorku.ca> <LORD.94Oc...@x1.cygnus.com>
Jaffer> <38htg8$b...@boogie.cs.utexas.edu>
Jaffer> NNTP-Posting-Host: camelot.ai.mit.edu
Jaffer>
Jaffer> By the way, here is a little example from the mother of all Schemes,
Jaffer> MIT Scheme - the implemenation which Profs. Sussman and Abelson use:
Jaffer>
Jaffer> ================================================================
Jaffer> Scheme Microcode Version 11.148
Jaffer> MIT Scheme running under HP-UX
Jaffer> Type `^C' (control-C) followed by `H' to obtain information about interrupts.
Jaffer> ^L
Jaffer> Scheme saved on Monday October 24, 1994 at 9:47:41 PM
Jaffer> Release 7.4.0 (alpha)
Jaffer> Microcode 11.148
Jaffer> Runtime 14.166
Jaffer> ;Loading "/zu/jaffer/.scheme.init"
Jaffer> ;Loading "/zu/jaffer/slib/require.scm" -- done -- done
Jaffer>
Jaffer> 1 ]=> (eq? '() '#f)
Jaffer>
Jaffer> ;Value: #t
Jaffer> ================================================================
Jaffer>
Jaffer> So is it an "obsolete, broken old implementation"?
Scheme Microcode Version 12.0
MIT Scheme running under HP-UX
Type `^C' (control-C) followed by `H' to obtain information about interrupts.
Scheme saved on Monday October 24, 1994 at 10:39:13 PM
Release 7.4.0 (internal)
Microcode 12.0
Runtime 14.167
;Loading ".scheme.init"
1 ]=> (eq? '() '#f)
;Value: #f
---------------------------------
Aubrey,
Quoting #f is redundant since it is self-evaluating (BTW).
You are using the old microcode. Just because you do not know how to
use your tools properly does not imply that the tools are broken.
Please stop taking every opportunity to engage in MIT Scheme bashing.
We all know you are jealous of MIT Scheme. You do not have to keep
reminding us.
Also, please find a way of posting to netnews so that your
Organization field does not falsely claim you are a member of the MIT
Artificial Intelligence Lab. You are not. Nor have you ever been. You
are a guest. And not a very well behaved one at that.
--
------------------------------------------------------------------------------
zi...@ai.mit.edu Michael R. Blair MIT Artificial Intelligence Laboratory
(617) 253-0765 [O] -. 545 Technology Square --- Room 439
(617) 661-3394 [H] /\. Cambridge, MA 02139-3539
Craig Burley
In article <38jie8$4...@mudraker.mtholyoke.edu> jb...@mtholyoke.edu (Jurgen Botz) writes:
Some people have been writing 'GNUel' to refer to the proposed
language in this thread... I propose 'gnudel'---short 'e', rhymes with
"noodle"---the 'd' is for 'dynamic' which is nice because this is a
salient feature of all the extension languages discussed and makes the
acronym pronounceable.
Do you suppose that it might become en vogue to write spaghetti code
in gnudel?
That's using your gnudel!
To meet some typist's expectations, there'd have to be an alternate
version of gnudel named gnubs.
And gnudel programmers would undoubtedly have lunch at their local
gnudeli.
Presumably the food there would be gnudelicious.
And it'd be flown in on gnudelta airlines.
:-)
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Michael R. Blair
> Only two kinds of standard Scheme
> program won't work with the GNU language without modification:
>
> 1. Those that depend on the distinction between '() and #f.
> 2. Those that depend on the case insensativity of Scheme identifiers
Make that three:
3. Those that depend on the existence of multiple obarrays
If not done in a careful manner, there will be no easy mapping back into Scheme
code without multiple obarrays.
I think this deserves some careful thought just how this extension is to be
provided and exploited.
I, for one, would like to hear from Tom Lord just how you plan to achieve this
objective. I am afraid that, in this case, the syntax actually matters.
matthew green
pe...@nmti.com (Peter da Silva) writes:
>(no, I don't think Perl's COBOL.
Perl _is_ COBOL, not because of its verbosity, but because of the
large number of builtin commands *each with its own peculiar syntax*.
if you look at perl 5, you'll see the number of reserved words
dropped by 2/3rds, and the "rules" for pretty much all of them
have been standardised.
perl 5 can *look* like cobol when you do
use English;
and use the *long* names (like $INPUT_FIELD_SEPARATOR)
(Saying "Perl is COBOL" is a bit too strong, but you know what I mean.)
bit? perl is the combination of a myriad of languages. it
is just wrong to say "perl is blah" in any sense.
.mrg.
Technically Sweet
a lot less space? Since you're talking about compiling to the
extension language any, it makes sense to compile to something
small and fast, thus keeping the compiled extentions small.
--
Lance Norskog
thi...@netcom.com
Artisputtingtogether. Art s th ow n aw y.
Aubrey Jaffer
Jaffer> From: jaf...@zurich.ai.mit.edu (Aubrey Jaffer)
;Value: #f
---------------------------------
Aubrey,
You are using the old microcode. Just because you do not know how to
use your tools properly does not imply that the tools are broken.
I typed `scheme' on one of the switzerland machines. This is the how
the info manual for MIT Scheme says to invoke it. If this is improper
use, it is a strange world. Notice the quotation marks in:
Jaffer> So is it an "obsolete, broken old implementation"?
*I* don't think it is broken even with (EQ? '() '#F). I was trying to
discredit that assertion by the previous poster.
Please stop taking every opportunity to engage in MIT Scheme bashing.
It amazes me that you consider my comment to be negative toward MIT
Scheme, when it was exactly the opposite. I consider MIT Scheme to be
*the* standard implemenation, and the fact that it has for so long had
(EQ? '() '#F) and that the authors of *the* standard text have used it
like that for years, I think points out the minimal importance of that
issue. That is the point I was trying to make.
We all know you are jealous of MIT Scheme. You do not have to keep
reminding us.
Jealous is not the term I would use. There are many aspects and
features of MIT Scheme that are worthy of inclusion in other
implementations. I often look to MIT scheme for the model for calling
conventions and procedure names for SLIB. Is that jealousy? If I use
code or specifications that you write and complement your work, does
that mean I am jealous of you?
In 1989, I tried hard to get MIT Scheme to compile on my 3Megabyte
68000 unix machine. I was unsuccessful and searched for other
solutions. Had I been successful, I wouldn't have written SCM. But I
harbor no grudge toward MIT Scheme.
But It *REALLY*, *REALLY* disturbs me that "We all" think I am biased
against certain implementations. I would not be effective in
administering SLIB if I harbored such bias. I have tried in every
communication to encourage ports and support for all implementations.
In fact, I do most of the work of maintaining SLIB's MITScheme port.
I can't beleive that you accuse me of all this on the basis of
misreading one post. I had thought our private email discussions on
Scheme technical issues had been cordial. But words can deceive. The
only guess I have for the source of your indignation is that you think
none of the work I do on SLIB, Jacal, r4rs.texi, SCM and other scheme
packages is of any worth and hence I am just an irritating freeloader.
If Prof. Sussman, and C. Hanson (my sponsors) agree, then I will
certainly stop. I do not want be a burden on your organization or
reputations.
Also, please find a way of posting to netnews so that your
Organization field does not falsely claim you are a member of the MIT
Artificial Intelligence Lab.
I have looked through my configuration files and I can not find that
string in there. I think it is added on when the posting goes through
camelot.ai.mit.edu. But I will try to suppress "Organization:". I
use emacs-GNUS through a term connection from Linux, if anyone can
help me with this (email please). I will also try to add a signature
to disclaim any association.
You are not. Nor have you ever been.
I did work for LCS (a related organization) when I was a student at
MIT.
You are a guest. And not a very well behaved one at that.
Please (in email) tell me what I have done that makes you say that. I
apologize if I have abused this priviledge. Such was certainly not my
intent.
I am a guest and *not* a member of the MIT Artificial Intelligence Lab.
My actions and comments do not reflect in any way on MIT.
--
I am a guest and *not* a member of the MIT Artificial Intelligence Lab.
My actions and comments do not reflect in any way on MIT.
ozan s. yigit
[MIT Scheme example as authority elided]
So is it an "obsolete, broken old implementation"?
probably not. on the other hand, none of its authors [so far as i know]
claim that MIT Scheme is designed to be compliant with any past or present
Scheme standard or compatible with any other implementation. [Bill J. Rozas
put this more forcefully once, but i cannot locate his note.]
oz
---
a technology is indistinguishable from | electric: o...@nexus.yorku.ca
its implementation. -- Marshall Rose | or o...@sni.ca [416 449 9449]
Erik Naggum
| Scheme saved on Monday October 24, 1994 at 10:39:13 PM
| Release 7.4.0 (internal)
| Microcode 12.0
| Runtime 14.167
| ;Loading ".scheme.init"
|
| 1 ]=> (eq? '() '#f)
|
| ;Value: #f
|
| ---------------------------------
:
| You are using the old microcode.
so where do I find release 7.4.0 and microcode version 12.0?
this is the latest public release I have found.
Scheme saved on Sunday November 21, 1993 at 9:15:23 PM
Release 7.3.0 (beta)
Microcode 11.146
Runtime 14.166
hold your fire, please, just answer my question.
#<Erik>
--
Microsoft is not the answer. Microsoft is the question. NO is the answer.
Markus Freericks
> May I respectfully suggest that a Forth interpreter would take up
> a lot less space? Since you're talking about compiling to the
> extension language any, it makes sense to compile to something
> small and fast, thus keeping the compiled extentions small.
Extend the Forth interpreter with a garbage-collected heap and closures,
and voila! you have a scheme runtime engine.
Markus
Scott McLoughlin
>
>
> I am a guest and *not* a member of the MIT Artificial Intelligence Lab.
> My actions and comments do not reflect in any way on MIT.
> --
> I am a guest and *not* a member of the MIT Artificial Intelligence Lab.
> My actions and comments do not reflect in any way on MIT.
Howdy,
This is _truly_ pathetic that it has come to this. If
anyone is "jealous" it is the recent attackers of Aubrey Jaffer
and SCM. Look guys and gals, SCM _won_ and Aubrey Jaffer is
to be complemented for writing/maintaining/organising the
SCM/SLIB effort to date.
Critics might ask themselves _why_ SCM was
selected and not their own favorite implementation. I have
a few guesses (longevity, portable, comprehensible source,
user base, small size, portable (including DOS, Atari ST and
Amiga), fast enough, etc.) but no one's asking.
Anyway, congrat's to SCM and its author. Live long
and prosper.
p.s. If other Scheme authors out there are desperate for a
large user base port the damn thing to Windows, include
a FFI and GUI binding and send it off to cica.cica.indiana.edu.
Write a Dr. Dobb's Journal article and wait for the gadzillion
"what's Scheme?" emails to come your way. Popularity has its
costs.
Neil Jerram
Since functions and variables occur in syntactically distinct contexts
in Emacs Lisp, couldn't the elisp->scheme translator handle this
problem by uniquifying variable names as it went along?
Neil.
lvi...@cas.org
In article <38lsar$5...@info.epfl.ch>,
Stefan Monnier <mon...@di.epfl.ch> wrote:
:In article <Cy6p...@jabba.ess.harris.com>,
:Mike McDonald <m...@Titan.ESS.Harris.com> wrote:
:> Because you can't maintain the system then. If your users get to go off and
:> pick any tranlator they want, you'll have to learn every available language
:> inorder to debug your user's scripts. I don't believe that it is practical for
:> you to expect to be able to debug a script written is some unknown language that
:> was machine translated into scheme, or forth, or whatever. (I've argued this same
:> point with the Dylan people to no good.)
What is the point of all the discussions? Is the goal to give 'users' (who
ever that might be) the ability to add new commands to a program? If so,
then we need to figure out which of the users we are trying to
cater to. The users most used to Windows are not going to want a selection
of dozens of langauges - they are going to want Visual Basic - or something
so close that the differences are non-important . This means not Tcl,
not Perl, not Scheme, or anything else.
Or are the users the system administrators of large Unix installations?
Then in all likelihood the language should look like either ksh (or one
of the derivitive/supersets) or perl.
Or are the users college students? By capturing the attention of folk
before they move out to industry, one has a better chance of moving one's
product on out to the marketplace - that's the approach Unix took as you
all know. Then Modula-3, Scheme, Dylan or whatever is the language
du jour is preferred as a base.
:>
:> If you're not going to let them pick, then you just as well force them to use
:> the same language as you picked.
:
:No ! you can just announce them that if they don't use language X, then
:you don't provide any support: no problem for you and more flexibility
:for the experienced user !
There are two results to this approach. One is that indeed you limit the
problems of dealing with all those languages out there. That is because
you limit to a very small subset the number of customers. If however
you are depending on said customers for income - you have just lost bucks.
--
:s Great net resources sought...
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
The task of an educator should be to irrigate the desert not clear the forest.
Peter da Silva
Stefan Monnier <mon...@di.epfl.ch> wrote:
> In article <id.Y44...@nmti.com>, Peter da Silva <pe...@nmti.com> wrote:
> > Using an arbitrary syntax to avoid favoritism:
> > display "Enter keystroke: "
> > read keystroke
> > display "Enter macro: "
> > read macro
> > define_key_macro %keystroke %macro
> > Now, if you're using an external compiler you need to run that compiler
> > from "define_key_macro".
> Why ?
Because the macro is in the extension language.
> Is elisp visible from its keyboard macro facility ?
I don't much care what elisp does. I'm talking about what I do.
> > Now suppose you're reading these from an X resource at startup. You're going
> > to have to call the compiler for *each* resource in turn.
> First, I don't see why use X resources for that purpose (but then, why
> not).
Because if you use X resources then it'll work the way you want on your
display, even if you're running a program from someone else's account.
> Second, these resources might be generated by a compiler !
I prefer to have my .Xdefaults file at least marginally readable.
Peter da Silva
Stefan Monnier <mon...@di.epfl.ch> wrote:
> > 2. Eval must take statements in the language the user writes.
> Wrong assumption !
Huh?
> Eval is pretty rare.
Eval is pretty common.
> And building source code on the fly is a pain.
That depends on the language.
Stefan Monnier
Michael R. Blair <zi...@biere.ai.mit.edu> wrote:
> Please stop taking every opportunity to engage in MIT Scheme bashing.
>We all know you are jealous of MIT Scheme. You do not have to keep
>reminding us.
>
> Also, please find a way of posting to netnews so that your
>Organization field does not falsely claim you are a member of the MIT
>Artificial Intelligence Lab. You are not. Nor have you ever been. You
>are a guest. And not a very well behaved one at that.
Thank you so much, you made my day !
Sometimes I feel like a moron, but...
there's obviously worse than me !
Stefan
Robert M. Haas
cross-posting to it? ...Robert
Roger Hayes
In article <38m4r3$9...@news.CNRI.Reston.Va.US> bwa...@cnri.reston.va.us (Barry A. Warsaw) writes:
>>>>> "bruce" == bruce <br...@liverpool.ac.uk> writes:
bruce> ...the emacs lisp code should be changed.
Barry> Ha! Do you know how much elisp that will break? I can't
Barry> imagine this ever happening.
Barry> -Barry
But it's not necessary to change any elisp. It's easy to implement
elisp in scheme.
For example, here's how to merge #f and '():
(define (elisp-bool x)
(if (null? x) #f
x))
(define-macro (elisp-and/2 x y)
(and (elisp-bool x) (elisp-bool y)))
You can get good performance by doing this elisp implementation as
a compiler, or as macros.
And it's much easier to merge '() and #f than to tease them apart once
merged.
Roger Hayes
Michael R. Blair
Jaffer> I typed `scheme' on one of the switzerland machines. This is the how
Jaffer> the info manual for MIT Scheme says to invoke it. If this is improper
Jaffer> use, it is a strange world.
The current on-line documentation on the switzerland machines does not
reflect the most recent alpha version of the microcode. This is not a
strange world. It is typical of systems under development. The current
way to use the experimental microcode is to type:
with-new-version scheme
to invoke Scheme. MY point was only to correct your presumed
implication that MIT Scheme does not comply with the IEEE '()/#f
distinction. The most recent experimental microcode does. I felt it
relevant, if not important, to point that out.
Jaffer> Notice the quotation marks in:
Jaffer>
Jaffer> So is it an "obsolete, broken old implementation"?
Jaffer>
Jaffer> *I* don't think it is broken even with (EQ? '() '#F). I was trying to
Jaffer> discredit that assertion by the previous poster.
I apologize. I misread you to be engaging in a more inflamatory
rhetoric. Like when Kennedy says to Romney: ``Well _I_ am interested
in helping children, any sane man would be.'' Maybe I have been
listening to too much of the local political debates while
hacking. Again, I apologize.
Please stop taking every opportunity to engage in MIT Scheme bashing.
Jaffer> It amazes me that you consider my comment to be negative toward MIT
Jaffer> Scheme, when it was exactly the opposite. I consider MIT Scheme to be
Jaffer> *the* standard implemenation, and the fact that it has for so long had
Jaffer> (EQ? '() '#F) and that the authors of *the* standard text have used it
Jaffer> like that for years, I think points out the minimal importance of that
Jaffer> issue. That is the point I was trying to make.
I believe, more accurately, that it reflects the recency of that
language modification in the Revised^N Report as well as the
relatively painful changes braved by Stephen Adams and Jim Miller to
bring it into MIT Scheme _versus_ the relative importance the issue
warrants given the coding style of most MIT Scheme users here at MIT.
We all know you are jealous of MIT Scheme. You do not have to keep
reminding us.
Jaffer> Jealous is not the term I would use. There are many aspects and
Jaffer> features of MIT Scheme that are worthy of inclusion in other
Jaffer> implementations. I often look to MIT scheme for the model for calling
Jaffer> conventions and procedure names for SLIB. Is that jealousy? If I use
Jaffer> code or specifications that you write and complement your work, does
Jaffer> that mean I am jealous of you?
I did not mean ``jealous'' in an accusative way. I meant it in a
factual way. You moved me to consult my desk dictionary to make sure I
had not erred. I do not mean to get needlessly pedantic on this point,
but I feel honor bound to at least explain myself:
1. watchful or solicitous in guarding or keeping: as, a man is
jealous of his rights.
Nope. Not what I had in mind. Probably more applicable to my comments
than yours.
2. resentfully suspicious of a rival or a rival's influence: as, her
husband was jealous of the other man.
Yup. That is what I had in mind. You seem relentless here and on the
Revised authors list to debate implementation and design issues
regarding MIT Scheme versus your SCM to the point of appearing, to me
at least, to be resentfully suspicious of anything you see in MIT
Scheme which you do not fully understand. I have heard this opinion
voiced by others on that list so I do not believe myself to be
mistaken, at least not mistaken in having formed that opinion.
[other irrelevant definitions omitted]
5. resentfully envious
This is _not_ what I intended to be taken to mean but I get the
distinct impression than you, and a couple others who responded in
private, interpreted my comment this way. Again, I apologize. This was
not my intent. I try to be very precise in my word choice but am often
stymied by the ambiguities in modern American usage.
By the way, these definitions I found in my Webster's New World
Dictionary of the American Language -- College Edition -- (c) 1960.
This printing, for those unfamiliar w/ American dictionary trivia, was
one of the last ones before the great revision undertaken throughout
the 60's to reflect American English as a more pedestrian dialect. For
instance, it does not support the modern confusion over ``anxious''
and ``impatient'' common today (one of my pet peeves).
Jaffer> In 1989, I tried hard to get MIT Scheme to compile on my 3Megabyte
Jaffer> 68000 unix machine. I was unsuccessful and searched for other
Jaffer> solutions. Had I been successful, I wouldn't have written SCM. But I
Jaffer> harbor no grudge toward MIT Scheme.
Jaffer>
Jaffer> But It *REALLY*, *REALLY* disturbs me that "We all" think I am biased
Jaffer> against certain implementations. I would not be effective in
Jaffer> administering SLIB if I harbored such bias. I have tried in every
Jaffer> communication to encourage ports and support for all implementations.
Jaffer> In fact, I do most of the work of maintaining SLIB's MITScheme port.
Yes. Your actions are commendable. Yet, at the same time, your
participation on this list and on the Revised authors list has often
been devisive when you saw things differently from the MIT Scheme
designers (and others). Your frequent unconstructive arguments served
to drive others away from active work on Scheme and has driven a wedge
of non-consensus within the revised authors list that has stalled
progress and burned out many formerly enthusiastic developers. Much of
the delay in the Revised 5 report I would attribute to the apathy that
has resulted in the other authors from feeling exhausted fighting with
you on relatively non-critical points on which you were not willing to
compromise or even entertain the possibility of a reasonable
dissenting opinion.
Jaffer> I can't beleive that you accuse me of all this on the basis of
Jaffer> misreading one post.
You cannot believe it because it is not true. I accused you of MIT
Scheme bashing on the basis of reading your posts to this list and,
more to the point, on the authors list for some 3 to 5 years now. Your
confusion at why I might have construed your quoted query as yet
another dig at MIT Scheme I consider to be disingenuous. I know when I
am issuing flame bait. Every good flamer does. You must have realized
your comment was inflamatory given your habit of bashing MIT Scheme.
Jaffer> I had thought our private email discussions on
Jaffer> Scheme technical issues had been cordial. But words can deceive.
Yes. I tried to be cordial with you before when you were campaigning
against MIT Scheme's exploration of first class environments. As I
recall, your complaints, we both ultimately surmised, were
ungrounded. As you ultimately admitted, there were design alternatives
you had not considered in your criticism of the language feature we
were discussing. You, however, had confused arguing against MIT
Scheme's implementation of the idea with arguing against the idea
itself. I thought we had come to closure on that topic.
When I proposed an addition to the Revised 5 report to provide a new
predicate for determining the mutubility/immutabilty of constant
aggregate date, you objected there based on your implementation's
inability to support such a feature in other than a trivial
conservative manner. When I pointed out to you that MIT Scheme and
Scheme 48 had such a feature already and that it was a natural
consequence of the Revised 4 report (although the MIT implementation
was trivial), you again took to bashing MIT Scheme and again confused
this with the idea being proposed. As I recall, you accused MIT Scheme
of supporting a memory model which you considered inferior to your
own. You would not accept that both MIT Scheme's design chose and your
SCM design choice were equally valid but that MIT Scheme's choice was
trivial in one direction (liberal) whereas yours was trvial in another
(conservative). You were characteristically intransigent on that point
so I gave up arguing for the proposal for the time being.
This is what I had in mind. You often confuse an idea with a specific
implementation of an idea and decide that your SCM implementation
would suffer difficulty in supporting the new idea so you take to
criticising MIT Scheme's particular implementation of it in order to
stifle cloud debate and divide the authors. In your comment on the
status of '()/#f in MIT Scheme, I took you to be engaging in the same
activity again since this is a long standing pattern of rhetoric for
you in this forum. Since the factual basis of your complaint was in
error, I chose to correct you as well as to express my dissatisfaction
with your behavior.
Jaffer> The
Jaffer> only guess I have for the source of your indignation is that you think
Jaffer> none of the work I do on SLIB, Jacal, r4rs.texi, SCM and other scheme
Jaffer> packages is of any worth and hence I am just an irritating freeloader.
Calm down. That is not a rational conclusion based on my comments. You
sound like Stallman. In an earlier message [apropos GNU Extension
Language sent to the authors list] I applauded your SCM efforts as
having a "deserved place within the spectrum of Scheme
implementations", or words to that effect. I have never commented on
SLIB, Jacal, or your other efforts as I do not have need of
them. Admittedly, I neglected to personally thank you for your
r4rs.texi efforts but that does not imply that I do not appreciate
it. As you may recall, I was the one who initiaited the request for
such an effort and even so much as volunteered to try to attend to it
but I unfortunately had insuffient time/experience to pull it off
myself so, in the meantime, you beat me to it. Again, thank you.
Jaffer> If Prof. Sussman, and C. Hanson (my sponsors) agree, then I will
Jaffer> certainly stop. I do not want be a burden on your organization or
Jaffer> reputations.
Relax. Your certainly no more a burden or embarassment than I am. Your
sponsors probably value your contributions more than my own, to be
honest. There, is that the complement you were fishing for? I'm not
beyond obliging you, even when you have annoyed me.
Also, please find a way of posting to netnews so that your
Organization field does not falsely claim you are a member of the MIT
Artificial Intelligence Lab.
Jaffer> I have looked through my configuration files and I cannot find that
Jaffer> string in there. I think it is added on when the posting goes through
Jaffer> camelot.ai.mit.edu. But I will try to suppress "Organization:". I
Jaffer> use emacs-GNUS through a term connection from Linux, if anyone can
Jaffer> help me with this (email please). I will also try to add a signature
Jaffer> to disclaim any association.
In your home directory, you can create a .organization file like your
.signature file. In your shell environment from which you invoke
emacs, you can also set an environment variable called
ORGANIZATION. From within emacs, there is a gnus-local-organization
(?) variable which you can also set. I do not recall what precedence
is. You can ask rol...@gnu.ai.mit.edu for more details. I believe he
knows that appropriate magic.
By the way, my displeasure with this "Organization" situation I have
also raised with respect to other guests on our system long ago. For
most of them, I have tried to find a solution but in your case that
seemed ineffective. Specifically, the login initialization scripts on
our machines detect if the person logging in is a guest and attempts
to setup the appropriate shell variable and .organization file. This
works for several of my guests but seems to fail for your account. I
do not understand why.
This "Organization" complaint does not reflect a personal attack on
you. It reflects pressure I have received from others to make the
policy consistent for all guests. Your post merely reminded me of the
unresolved problem.
You are not. Nor have you ever been.
Jaffer> I did work for LCS (a related organization) when I was a student at
Jaffer> MIT.
I did not want folks to get the impression that you were an authority
on MIT Scheme. Your post, in isolation, might naturally have lead
people to that conclusion. I did not want to read, some number of
weekes from now, that some MIT Scheme guy showed that the '()/#f
distinction could not be done in MIT Scheme, blah blah blah. This sort
of disinformation peppers Usenet and I just sought to salk this one's
tail before it took flight (mixed metaphor not withstanding).
You are a guest. And not a very well behaved one at that.
Jaffer> Please (in email) tell me what I have done that makes you say that. I
Jaffer> apologize if I have abused this priviledge. Such was certainly not my
Jaffer> intent.
I have explained above. Since you accused me of basing my reaction on a single
post, I felt compelled to explain myself in detail above.
Again, as in our last exchange, we appear to have been talking at
cross purposes. I took you to have been issuing an insult, which you
have refuted. My mistake. Upon re-reading, perhaps a better wording
than "well behaved" would have been "gratious", but I didn't want to
be misread as asking for some sort of penance. I'm not _that_ trite.
I just don't think you conduct your postings with much grace
sometimes. Neither do I, for that matter. I guess my own posts just
don't annoy me as much as some of yours, for some odd reason. This
particular round, however, has caused me to embarass myself. For what
it's worth, again I apologize. I will make every effort to cool my
jets and be more civil to your future posts. You tend to rub me the
wrong way with your MIT Scheme needling but I will try to resist and
afford you the benefit of the doubt and take you at your word and
simply offer dispassionate factual refutations of any false claims you
may offer in the future. I think it is more important that the truth
be made apparent than that either of us appear to be in the right.
And I apologize to the rest of the list for my bad temper on this
subject. I am a habitual flamer but I am trying to grow out of
it. This was a particularly bad relapse this time on my part.
I'm trying to avoid just this sort of flare up. Thank you for bearing
with me.
Michael R. Blair
[Michael R. Blair]
| Scheme saved on Monday October 24, 1994 at 10:39:13 PM
| Release 7.4.0 (internal)
| Microcode 12.0
| Runtime 14.167
| ;Loading ".scheme.init"
|
| 1 ]=> (eq? '() '#f)
|
| ;Value: #f
|
| ---------------------------------
:
| You are using the old microcode.
so where do I find release 7.4.0 and microcode version 12.0?
this is the latest public release I have found.
Scheme saved on Sunday November 21, 1993 at 9:15:23 PM
Release 7.3.0 (beta)
Microcode 11.146
Runtime 14.166
This ``release'' is internal, meaning pre-release (alpha). So too is the
microcode (I think). It is, however, the Scheme running on our machines where
it is being developed. That was my only point. Aubrey's post could have been
misinterpreted as implying otherwise.
I do not know when the new release is scheduled for completion (i.e., beta).
If you find this new feature to be critical to your work, send me email and I
will try to see if we can accomodate you somehow. My email address and phone
numbers are below.
hold your fire, please, just answer my question.
Yes. I deserved that. Thank you.
br...@liverpool.ac.uk
>>>>> "bruce" == bruce <br...@liverpool.ac.uk> writes:
bruce> Emacs lisp programs really do use the same symbol for values
bruce> and functions, and certainly use nil to represent false.
bruce> From the comments of several people, it looks as though some of
bruce> these decisions are mistakes: the emacs lisp code should be
bruce> changed.
> Ha! Do you know how much elisp that will break? I can't imagine
> this ever happening.
Not much, I hope. I was thinking of the rather minimal symbols being
used as both functions and variables thing---now that *is* used in
elisp, but I'd guess it's not used all that much. Perhaps it can even
be done automatically.
I can't even imagine how to catch '() being used instead of #f. That
seems quite tricky.
lvi...@cas.org
Let's not lock ourselves into saving extensions languages into X resource
files - some folk do write programs that don't need or want to link in
Xlib just to read in default values...
Martin Meier
Why don't you just simplify this down a bit more:
The user perfered extention language is translated into C.
The GCC front and back end create an object module
(The tricky part)
The object module is automagicly converted into a bit of run time code, loaded
on the fly by the app, and simply run as native processor code.
This may be as fast as you can likely get with an extention language and may only
be slightly more cumbersome the present plan(lang -> scheme).
Hmmm....
Now that I think of it, this maybe something I could 'patent'.
:)
Peter da Silva
>
> Let's not lock ourselves into saving extensions languages into X resource
> files
Who's doing that?
I'm saying "don't lock out cases where you need cheap eval". The X resource
file was just one example.
Jurgen Botz
Kevin K. Lewis <lew...@grasshopper.aud.alcatel.com> wrote:
>In article <38jie8$4...@mudraker.mtholyoke.edu> jb...@mtholyoke.edu (Jurgen Botz) writes:
> Some people have been writing 'GNUel' to refer to the proposed
> language in this thread... I propose 'gnudel'---short 'e', rhymes with
> "noodle"---the 'd' is for 'dynamic' which is nice because this is a
> salient feature of all the extension languages discussed and makes the
> acronym pronounceable.
>
>Do you suppose that it might become en vogue to write spaghetti code
>in gnudel?
That's up to each programmer, I'll be writing rontini code, thank
you.
Btw., for those who haven't heard the term, some people have been
referring to some of the new VHLL's (esp. Dylan) as "OODLs",
pronounced "oodles" and standing for "Object Oriented Dynamic
Languages". So with the right extensions Gnudel would be a an OODL.
And since the GNU dynamic extension language will be designed as a
base on top of which variant/other languages can be implemented, there
might end up being oodels of Gnudels.
Raul Deluth Miller
. It is also less suited for large projects than TCL, and for all of
. the same reasons. (Forth enthusiasts: please flame by email.)
Not the same reasons -- for example, TCL is typically about 100-200
times slower than Forth. TCL spends a lot of the time doing symbol
table lookups.
. - It has a much smaller user base. The language is less publicised
. and is quite a bit harder to justify. Forth also has a fairly
. steep initial learning curve, which makes getting new users harder.
Smaller than what? How measured?
. I'd be happy to be wrong... it has been a few years since I followed
. forth closely. Have you seen a good, fast, free, portable and
. C-based forth? (Tile forth wouldn't qualify without extensive
. work.) Are there any compilers out there now? Are there any GUI
. interfaces?
Try Will Baden's "ThisForth" (available from
http://taygeta.oc.nps.navy.mil/skips%5Fhome.html) -- no GUI yet on
this forth, but it wouldn't be hard to add TK. [And there are plenty
of forths with GUIs -- I won't bore you with the list.]
None of which is an endorsement for Forth as an extension language --
I merely wish to point out that some of these criticisms are unjust,
and, to put it bluntly, flame bait.
--
Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q
<rock...@nova.umd.edu> y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e<n
NB. public e, n, y
x -: n&|&(*&y)^:d 1 NB. 1=(d*e)+.p*&<:q
John Lundin
Technically Sweet <thi...@netcom.com> wrote:
>May I respectfully suggest that a Forth interpreter would take up a lot
Forth makes a great embedded language, especially where space is
tight. Unfortunately, it isn't likely to make a good portable glue.
- Forth is weakest in areas we have to use heavily in an extension
language. The "standard" language lacks all but trivial string
and file system handling, and interfacing with external non-forth
modules is both nonstandard and nontrivial. It's easy to build
tools to do these things... but everyone builds their own. :-(
Even local variables require nonstandard extensions.
Forth also (historically) lacks security and checking. It is
unusually easy to crash. This is partly due to a decision by
developers to keep the interpreter fast and leave protection to the
program developer. This isn't desirable where you have novices
adding to the dictionary. It can be fixed, but at a cost.
It is also less suited for large projects than TCL, and for all of
the same reasons. (Forth enthusiasts: please flame by email.)
- There are many fewer tools to work with Forth. And to use with it.
We're talking about a project that has to "compete" with TCL and
other candidate languages. Forth has far fewer packages, and much
less agreement between packages, than the others being discussed.
In particular, GUI capabilities in packages that I've seen have been
rudimentary and wholly nonstandard.
- It has a much smaller user base. The language is less publicised
and is quite a bit harder to justify. Forth also has a fairly
steep initial learning curve, which makes getting new users harder.
- The virtual architecture that forth imposes is a straightjacket on
many modern machines. Not only does it make interfacing to other
languages painful, but techniques required for optimization beyond
the usual threaded interpreter are not (IMHO) well developed. It
also makes it darned difficult to "prove" proper program operation.
I'd be happy to be wrong... it has been a few years since I followed
forth closely. Have you seen a good, fast, free, portable and C-based
forth? (Tile forth wouldn't qualify without extensive work.) Are
there any compilers out there now? Are there any GUI interfaces?
Unless the situation has changed radically, forth isn't at all suited
to be our general purpose extension language.
(Please remove comp.lang.scheme from followups if not scheme-related.)
We now return to our regularly scheduled scheming. -john
ps: if you really want to use forth, maybe I can locate a toy forth I
wrote in lisp in the '80s. :-) MISFIT* was mostly a joke on the '83
standard, but it might be made to work if you want to put some time in.
*Maximally Incompatible Standard Forth Interpreter/Translator.
John Lundin, lun...@urvax.urich.edu, lun...@boojum.urich.edu
"Immature programmers imitate, mature programmers steal"
Barry A. Warsaw
>>>>> "JB" == Jurgen Botz <jb...@mtholyoke.edu> writes:
JB> Btw., for those who haven't heard the term, some people have
JB> been referring to some of the new VHLL's (esp. Dylan) as
JB> "OODLs", pronounced "oodles" and standing for "Object Oriented
JB> Dynamic Languages". So with the right extensions Gnudel would
JB> be a an OODL. And since the GNU dynamic extension language
JB> will be designed as a base on top of which variant/other
JB> languages can be implemented, there might end up being oodels
JB> of Gnudels.
POODLE (Perl or Python OODL)
TOODLE (Tcl OODL)
STROODLE (Scheme TailoRed OODL)
DOODLE (Dylan OODL)
-Barry
John Lundin
Raul Deluth Miller <rock...@nova.umd.edu> wrote:
>I merely wish to point out that some of these criticisms are unjust,
>and, to put it bluntly, flame bait.
Hm. That went well. 8-( Lets see if I can do better this time.
Raul has a point... my commentary came out much harsher than intended.
Lance, I hope you weren't offended. It was not intended as flame or bait.
These are my opinions, not absolute facts, and do not reflect, etc, etc.
For context, I began using forth in the late 70s. It and its variants (such
as stoic) do indeed make useful glue languages... but for internal projects.
Forth is a very good tool-building language. Too good. I would be reluctant
to give access to the core forth language to an end-user. It's too easy to
crash existing implementations, and too hard to figure out why. Writing a
more rugged extension language in it would make more sense, but the end-user
wouldn't "see" the forth core and the safer extensions would be slower.
The languages that I had most fun using have been forth, icon, and lisp...
>John Lundin:
>. It is also less suited for large projects than TCL, and for all of
>. the same reasons. (Forth enthusiasts: please flame by email.)
>Not the same reasons -- for example, TCL is typically about 100-200
>times slower than Forth. TCL spends a lot of the time doing symbol...
We can argue the speed business offline if you like. It's true enough.
Large projects being slow is a familiar complaint about forth interpreters.
The same was true of lisp, maybe more so. I would expect to hear it of tcl.
Remedies can be implemented. My feeling is that lisp has more remedies now.
I'm curious about your 100-200 times figure. What were your benchmarks? My
experience has been that once you start doing similar glue-type things, the
string handling and calls mask out a lot of language speed differences.
Tell you what. Most dictionaries are linked lists of pointers to words. Why
not go one step further and use "link threading" so that each word pointer is
followed by a link to the next word pointer in order? This at most doubles
your dictionary size, but you can reclaim some if you use a secondary space
for your string area and keep separate headers, as some other forths do. The
linking adds some inner interpreter overhead, say, about as much as token
threading, and gives you even more flexibility in rearranging the dictionary.
What you wind up with looks a lot like a primitive lisp interpreter. (grin)
The design goal, as stated, calls for something that you can implement lisp
and tcl in efficiently. Thanks to language similarity and rush, this is true
of scheme. I have seen (and written) lisp interpreters in forth, but they
were slow and I have not seen any equivalent compiler projects. Yet.
>. - It has a much smaller user base. The language is less publicised
>Smaller than what? How measured?
(blink) I assumed this was obvious. Smaller than lisp's. Emacs alone should
take care of that. Most CS departments teach some lisp, but forth? Compare
sales of books, amount of code, available software using the language, etc.
>>...Have you seen a good, fast, free, portable and C-based forth? ...
>Try Will Baden's "ThisForth" ... no GUI yet... it wouldn't be hard to add
>TK. [And there are plenty of forths with GUIs -- I won't bore you...]
I will. And please bore me with that list. Email preferred.
>None of which is an endorsement for Forth as an extension language --
Really? I'd endorse it as "an" extension language. -john
John Lundin Jr lun...@urvax.urich.edu "A pentagram approaches a circle for
U of Richmond lun...@boojum.urich.edu sufficiently large values of five."
Stephen J Bevan
followups to the latter - bevan ]
In article <38p80s$m...@nomad.urich.edu> lun...@boojum.urich.edu (John Lundin) writes:
Forth makes a great embedded language, especially where space is
tight. Unfortunately, it isn't likely to make a good portable glue.
- Forth is weakest in areas we have to use heavily in an extension
language. The "standard" language lacks all but trivial string
and file system handling,
The "standard" has comparable (but less) string and file system
handling than C. The former can usually be written in portable Forth
and the latter is often system dependent and so is outside the scope
of the standard. Neither are difficult to write once you decide on
what you want.
and interfacing with external non-forth modules is both
nonstandard and nontrivial.
Very few languages have standard methods of interfacing with other
languages, so Forth isn't an exception here.
... Even local variables require nonstandard extensions.
The necessary features to implement local variables are in the standard.
Forth also (historically) lacks security and checking. It is
unusually easy to crash. This is partly due to a decision by
developers to keep the interpreter fast and leave protection to the
program developer. This isn't desirable where you have novices
adding to the dictionary. It can be fixed, but at a cost.
Some systems come with optional checking, this lets the user decide
whether to pay the performance penalty or not.
It is also less suited for large projects than TCL, and for all of
the same reasons. (Forth enthusiasts: please flame by email.)
For all the same reasons as what?
- The virtual architecture that forth imposes is a straightjacket on
many modern machines.
The standard does not require a virtual machine; there is at least one
pre-standard Forth (currently being updated) which compiles to native
machine code.
... It also makes it darned difficult to "prove" proper program operation.
Unless people are proving that their TCL/Perl/... etc. programs are
operating correctly I don't see that this is relevant.
I'd be happy to be wrong... it has been a few years since I followed
forth closely. Have you seen a good, fast, free, portable and C-based
forth?
See the FAQ in comp.lang.forth.
(Tile forth wouldn't qualify without extensive work.)
Perhaps you could explain why since it appears to satisfy all the
above requirements?
Are there any compilers out there now?
See the comp.lang.forth FAQ.
Are there any GUI interfaces?
For which GUI? Again, see the FAQ for more details.
Unless the situation has changed radically, forth isn't at all suited
to be our general purpose extension language.
Perhaps not, but then I doubt you can get everyone to agree that any
particular language is suited to be "our general purpose extension
language". For example, try convincing a Perl user that TCL is the
way to go, or vice versa.
Fergus Henderson
>(no, I don't think Perl's COBOL.
Perl _is_ COBOL, not because of its verbosity, but because of the
large number of builtin commands *each with its own peculiar syntax*.
(Saying "Perl is COBOL" is a bit too strong, but you know what I mean.)
--
Fergus Henderson - f...@munta.cs.mu.oz.au
Harald Hanche-Olsen
Scott> Look guys and gals, SCM _won_ and Aubrey Jaffer is
Scott> to be complemented for writing/maintaining/organising the
Scott> SCM/SLIB effort to date.
Yes, by all means, go ahead and complement Aubrey. Personally, I
think he might deserve a compliment as well. :-)
- Harald