|
|
|
|
|
|
| Author |
Message |
Poul-Henning Kamp *nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
Posted: Tue Jul 16, 2002 4:23 pm Post subject:
Re: An odd scripting language
|
|
|
In message <3D346322.1060902@ntlworld.com>, Antony T Curtis writes:
| Quote: | Mark Murray wrote:
However, I am intruiged by your assertion here. It implies that perhaps
a good direction to try would be to build a scripting language that is
tied to FreeBSD, but contains elements that makes it easy to pick up
by people who are already comfortable with the popular scripting languages.
A solution here may be to pick up an earlier scripting language
that has been abandoned, but is nevertheless useful. I'm specifically
thinking of Perl4, but I imagine that TCL, the lisps, the BASICs
and other older "Toy" languages may yield up a useful base for an
OS-specific scripting language.
I would suggest REXX... It's a mature scripting language which is
drifting off into the sunset. It is easy to pick up - being a bit like
BASIC... The only thing is - How would IBM react to it?
Actually, I think IBM's Mike Colinshaw would love his language being used...
|
I'd love to see John Hartman's TSO-PIPES under UNIX :-)
Get them to release it under BSDL and we'll rock :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Jordan K Hubbard *nix forums beginner
Joined: 07 Jul 2002
Posts: 17
|
Posted: Tue Jul 16, 2002 4:42 pm Post subject:
Re: Package system flaws?
|
|
|
I think we're waiting for it to get to the stage where it does enough
that it's not shot down for lack of functionality. It actually seems
to be making very good progress as a side-project, so I haven't been
tempted to rock the boat by encouraging its merger with the main CVS
repo until its own developers feel it's ready for that. For one thing,
it would make adding new developers to the libh project that much
harder since they'd have to go through the more formal committer
process.
- Jordan
On Tuesday, July 16, 2002, at 02:24 AM, Dag-Erling Smorgrav wrote:
| Quote: | Jordan K Hubbard <jkh@queasyweasel.com> writes:
If libh ever makes it off the ground, you can bet that Tcl will enter
the base system fairly rapidly since it will be required for
everything from bootstrapping packages onto the system to actually
installing the system itself.
I'm not a big fan of having Tcl in the base system, but - what are we
waiting for? libh should have entered the tree a long time ago,
there's absolutely nothing to be gained from leaving it out in the
cold.
DES
--
Dag-Erling Smorgrav - des@ofug.org
-- |
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
M. L. Dodson *nix forums beginner
Joined: 16 Jul 2002
Posts: 1
|
Posted: Tue Jul 16, 2002 7:15 pm Post subject:
Re: An odd scripting language
|
|
|
On 16 Jul, Mark Murray wrote:
| Quote: | However, I am intruiged by your assertion here. It implies that perhaps
a good direction to try would be to build a scripting language that is
tied to FreeBSD, but contains elements that makes it easy to pick up
by people who are already comfortable with the popular scripting languages.
A solution here may be to pick up an earlier scripting language
that has been abandoned, but is nevertheless useful. I'm specifically
thinking of Perl4, but I imagine that TCL, the lisps, the BASICs
and other older "Toy" languages may yield up a useful base for an
OS-specific scripting language.
This is an interesting concept. Fraught with problems, but nonetheless
interesting.
Yes. _Very_ interesting :-)
M
|
Icon, Icon, Icon! http://www.cs.arizona.edu/icon/
Professionally designed (by the inventor of snobol), right kind of
license, ability to do X graphics, if need be, but not required, even
better than perl in string processing (IMO).
--
M. L. Dodson bdodson@scms.utmb.edu
409-772-2178 FAX: 409-772-1790
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Cyrille Lefevre *nix forums beginner
Joined: 12 Jun 2002
Posts: 48
|
Posted: Tue Jul 16, 2002 8:55 pm Post subject:
Re: An odd scripting language
|
|
|
here is a non-exhaustive list of computer languages, so please, don't
list them all :)
http://dmoz.org/Computers/Programming/Languages/
Cyrille.
--
Cyrille Lefevre mailto:cyrille.lefevre@laposte.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Andrew Reilly *nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
Posted: Mon Jul 22, 2002 9:16 pm Post subject:
Re: Package system flaws?
|
|
|
On Tue, 2002-07-16 at 03:18, Mark Valentine wrote:
| Quote: | Beyond that there's a perfectly good C compiler.
|
Here's another way to think about this problem, that just occurred to me
(and with it, another theory for a solution):
* Any new scripting language always runs into the problem of support for
the entirety of the libraries of the base system (and whatever add-ons a
site might have) until it becomes popular enough that wrappers will have
been written for all of them, or auto-generated in some way.
* The big things that make C more difficult than scripting languages are
(IMO of course):
+ No high-level containers as basic types (dictionaries,
multi-dimensional auto-sizing arrays, "stringy" strings.
+ No container-oriented flow control (foreach, etc).
+ No garbage collection.
+ Manual type definition.
* It does, however automatically have access to facility of the system,
because that's how the APIs are expressed (.h files).
* There isn't (that I can see) a strong need for the dynamic features of
scripting languages (the exec function, essentially) in "programs" like
portupgrade and the build-assist things that used to be done in perl.
So: what about a ratfor-style pre-processor for C, rather than a whole
extra language? The C source could be shipped with the system to be
compiled, so that the translator/pre-processor would not be a dependency
in the build process. (SmallEiffel bootstraps this way.)
I don't know of a language that does what I'm thinking, so perhaps
there's something fundamentally difficult with it. SmallEiffel probably
comes pretty close, but it doesn't do the type inference that you need
to avoid manual definitions. It's also a bit painful to wrap external C
functions. Showing it's age a bit there.
Certainly there are string manipulation libraries that are much easier
to use than stdlib, generic garbage collectors.
Sure, it would make the programmer's job a smidgen harder, because
they'd have to run the pre-processor and then compile the result, but
that's not much of a chore. The system Makefiles could even be taught
to do it automatically.
On the same topic, (but perhaps in counterpoint) there was a post to
comp.arch recently that said (in effect) that every programming project
of sufficient scale grows a bad implementation of Common Lisp.
Just how important _is_ the exec function to a scripting language?
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Jordan K. Hubbard *nix forums beginner
Joined: 18 Jun 2002
Posts: 4
|
Posted: Mon Jul 22, 2002 9:28 pm Post subject:
Re: Package system flaws?
|
|
|
On Monday, Jul 22, 2002, at 16:16 US/Pacific, Andrew Reilly wrote:
| Quote: | Just how important _is_ the exec function to a scripting language?
|
Not nearly as important as the eval function. :)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Andrew Reilly *nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
Posted: Mon Jul 22, 2002 9:41 pm Post subject:
Re: Package system flaws?
|
|
|
On Tue, 2002-07-23 at 09:28, Jordan K. Hubbard wrote:
| Quote: |
On Monday, Jul 22, 2002, at 16:16 US/Pacific, Andrew Reilly wrote:
Just how important _is_ the exec function to a scripting language?
Not nearly as important as the eval function.
|
Doh! That's what I meant, of course. Insufficient caffiene intake so
far this morning.
So: do, for example, portupgrade or libh make significant use of an eval
function?
I know (well, believe: it's been a while since I looked) that tcl is all
read-eval loop, just like lisp. But how much is that functionality
actually used in real programs/scripts? Config file parsing is about
all that I can think of, and that's likely to be subsumed by an XML
parser or LDAP server hook due to popular demand any day now... :-)
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Jordan K. Hubbard *nix forums beginner
Joined: 18 Jun 2002
Posts: 4
|
Posted: Mon Jul 22, 2002 10:30 pm Post subject:
Re: Package system flaws?
|
|
|
I think the most important use of eval is probably the one the user is
least explicitly aware of: The outermost one which is called on the
contents of a script.
To put it another way, it's not so much about parsing config scripts
(though that comes along for free with any reasonably simplistic
scripting language), it's about extensibility.
If sysinstall had been written as a small, tight generic core of
functionality with all the actual "personality" in external scripts,
for example, people would have long-since come up with lots of good
innovations to the "standard" script which made it even easier for
novice users to navigate, they would have changed the "expert" script
to be even more succinct, and they probably would have come up with a
host of other scripts which were uniquely well-suited to installing
FreeBSD in academic environments and so on.
In the world of packaging, all of the post-configuration and custom
installation stuff is essentially controlled by scripts already,
they're just shell scripts and sh(1) is already notorious for its weak
variable handling (no associative arrays), cumbersome conditional
statements, rudimentary string handling primitives, and so on.
Adopting a more robust scripting language, especially one where various
interfaces to the system or to database libraries can be plugged in
from other languages like C, simply makes the package writer's job that
much easier. Maybe I'm seeing this from the wrong perspective, but it
seems to me that this is all people are essentially arguing about.
- Jordan
On Monday, Jul 22, 2002, at 16:41 US/Pacific, Andrew Reilly wrote:
| Quote: | On Tue, 2002-07-23 at 09:28, Jordan K. Hubbard wrote:
On Monday, Jul 22, 2002, at 16:16 US/Pacific, Andrew Reilly wrote:
Just how important _is_ the exec function to a scripting language?
Not nearly as important as the eval function. :)
Doh! That's what I meant, of course. Insufficient caffiene intake so
far this morning.
So: do, for example, portupgrade or libh make significant use of an
eval
function?
I know (well, believe: it's been a while since I looked) that tcl is
all
read-eval loop, just like lisp. But how much is that functionality
actually used in real programs/scripts? Config file parsing is about
all that I can think of, and that's likely to be subsumed by an XML
parser or LDAP server hook due to popular demand any day now... :-)
--
Andrew
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Mark Valentine *nix forums addict
Joined: 13 Jun 2002
Posts: 62
|
Posted: Tue Jul 23, 2002 1:40 am Post subject:
Re: Package system flaws?
|
|
|
| Quote: | From: "Jordan K. Hubbard" <jkh@queasyweasel.com
Date: Mon 22 Jul, 2002
Subject: Re: Package system flaws?
sh(1) is already notorious for its weak
variable handling (no associative arrays),
|
But hey, it has "eval"... ;-)
main()
{
array_init colour
array_set colour apple red
array_set colour pear green
for_each colour c 'echo "The $c is `array_get colour $c`."'
}
array_init()
{
array=$1
eval _keys_$array=
}
array_set()
{
array=$1
key=$2
value=$3
eval _elements_${array}_${key}="$value"
eval _keys_${array}=\"\$_keys_${array} $key\"
}
array_get()
{
array=$1
key=$2
eval value=\$_elements_${array}_${key}
echo "$value"
}
for_each()
{
array=$1
variable=$2
procedure=$3
eval for key in \$_keys_${array}\; do \{ $variable=\$key\; $procedure\; \}\; done
}
main
Almost as readable as Tcl, I'd say. And as for Perl...
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com> <http://www.freebsd.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Dag-Erling Smorgrav *nix forums Guru Wannabe
Joined: 23 Mar 2002
Posts: 110
|
Posted: Tue Jul 23, 2002 5:30 am Post subject:
Re: Package system flaws?
|
|
|
"Jordan K. Hubbard" <jkh@queasyweasel.com> writes:
| Quote: | In the world of packaging, all of the post-configuration and custom
installation stuff is essentially controlled by scripts already,
they're just shell scripts and sh(1) is already notorious for its weak
variable handling (no associative arrays), cumbersome conditional
statements, rudimentary string handling primitives, and so on.
|
So let's import a ksh.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Anthony Dean *nix forums beginner
Joined: 23 Jul 2002
Posts: 3
|
Posted: Tue Jul 23, 2002 11:31 am Post subject:
Re: Package system flaws?
|
|
|
| Quote: | In the world of packaging, all of the post-configuration and custom
installation stuff is essentially controlled by scripts already,
they're just shell scripts and sh(1) is already notorious for its weak
variable handling (no associative arrays), cumbersome conditional
statements, rudimentary string handling primitives, and so on.
So let's import a ksh.
ksh93 even has dynamically loadable builtins, which allows the extensibility
to arbitrary APIs that phk pointed out was the most important feature of the
"real" scripting languages.
$ grep "^ksh93" /usr/ports/LEGAL
ksh93 ports/shells/ksh93 User must agree to "regularly monitor the Website".
How about a cron job to fetch the web page and mail it to root, oh say about
twice a year? ;-)
ksh93 would also help the standards effort.
Cheers,
Mark.
|
I've been meaning to suggest the same thing. I can't think of anything that
Perl does better than ksh93, but ksh93 is actually readable (and makes a damn
good interactive shell :)
In fact ksh93 is the first port I install on Free/OpenBSD.
Anthony
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Mark Valentine *nix forums addict
Joined: 13 Jun 2002
Posts: 62
|
Posted: Tue Jul 23, 2002 1:15 pm Post subject:
Re: Package system flaws?
|
|
|
| Quote: | From: Dag-Erling Smorgrav <des@ofug.org
Date: Tue 23 Jul, 2002
Subject: Re: Package system flaws?
"Jordan K. Hubbard" <jkh@queasyweasel.com> writes:
In the world of packaging, all of the post-configuration and custom
installation stuff is essentially controlled by scripts already,
they're just shell scripts and sh(1) is already notorious for its weak
variable handling (no associative arrays), cumbersome conditional
statements, rudimentary string handling primitives, and so on.
So let's import a ksh.
|
ksh93 even has dynamically loadable builtins, which allows the extensibility
to arbitrary APIs that phk pointed out was the most important feature of the
"real" scripting languages.
$ grep "^ksh93" /usr/ports/LEGAL
ksh93 ports/shells/ksh93 User must agree to "regularly monitor the Website".
How about a cron job to fetch the web page and mail it to root, oh say about
twice a year? ;-)
ksh93 would also help the standards effort.
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com> <http://www.freebsd.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Christian Weisgerber *nix forums beginner
Joined: 29 May 2002
Posts: 18
|
Posted: Tue Jul 23, 2002 3:33 pm Post subject:
Scripting languages (was: Re: Package system flaws?)
|
|
|
Mark Valentine <mark@thuvia.demon.co.uk> wrote:
| Quote: | ksh93 would also help the standards effort.
|
ksh93 has an unacceptable license. The legalese is impenetrable,
but it appears you can't redistribute the source without the receiver
explicitly acknowledging the license; AT&T can revoke the license;
etc. This was clearly written by corporate lawyers in a mindset
entirely different from that of the Open Source community.
(ksh93 also ships with an idiosyncratic build system from hell.
They try to be ultra-portable, but the result is extremely fickle
and the port keeps breaking. We can't run the regression tests
against the compiled excutable unless somebody dives even further
into the mess of AT&T's parallel code universe, but I suspect if
we could the results would be discouraging. Speaking as the
maintainer of the port, I certainly advise against people using
ksh93 for anything serious.)
--
Christian "naddy" Weisgerber naddy@mips.inka.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Fri Jan 09, 2009 1:36 am | All times are GMT
|
|
Final Fantasy Wallpapers | Wide Shoes for Women & Men | Loan | Credit Cards | Internet Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|