GNU Extension Language Plans
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.
--
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?"
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.
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)
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
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
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
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.
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
> 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>
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
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.
--
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.
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
> from "define_key_macro".
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
> 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
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.
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.
Robert M. Haas
cross-posting to it? ...Robert
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...
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.
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