On 10/2/06, Kero <kero@chello.single-dot.nl> wrote:
> Well, considering that Paul Graham is a Lispnik, I think we can infer
> what his definitions of "powerful" and "succinct" in a programming
> language are. What would be interesting to me would be where he stands
> on the great "Common Lisp vs. Scheme" divide. Or what he thinks of
> Forth, the "other succinct and powerful language."
>
> Perhaps more to the point would be a comparison of Lisp, Scheme and Ruby
> as hosts for internal domain-specific languages. Didn't somebody do that
> already?
I once had this little conversation with a programmer tha I respect a lot:
He: "Does Ruby have closures?"
Me: "Yes"
He: "Does Ruby have continuations?"
Me: "Yes"
He: "So it's basically just Scheme, but with an uglier syntax."
I once had this little conversation with a programmer tha I respect a lot:
He: "Does Ruby have closures?"
Me: "Yes"
He: "Does Ruby have continuations?"
Me: "Yes"
He: "So it's basically just Scheme, but with an uglier syntax."
I had no reply.
Well ... Ruby has closures and continuations, but does it have the third
hallmark of Scheme -- efficient tail recursion?
Implementation detail. But I really wish it did...
Well, C is not a great language for writing parsers in, and in my
experience neither is Java. The best language I've seen for writing
language parsers is Haskell. Though Racc does a competent job. I
don't think it's antlr, though.
Martin
A nice example of a pure succinct Ruby parser is Dennis Ranke's
recursive descent parser
written for his solution to the Dice Roller Ruby Quiz
In any case, there's a question about about to what extent you *should*
host DSLs internally. It's my feeling that if you want to inline a DSL
in your code, make sure that language is still syntactically
recognizably a Ruby. Ruby on Rails is a classic example.
The problem I have with the two best-known Ruby DSLs, Rails and Rake, is
the somewhat non-intuitive mix of words that don't begin with colons,
and symbols, which do.
True, but at least it's recognizably, syntactically, Ruby. I'm not sure
there's a way round the colon issue, you just have to live with it.
Yeah ... as does the person who's trying to put a timestamp like '10:30'
into a DSL in the "natural way". That "natural way" would work in Forth,
by the way, and is in fact the historical way to do things in Forth. In
Forth
from 10:30 to 11:30
the 'from' word would scan and parse the '10:30' word to its right, etc.
And Rails requires YAML in some places that are
jarring to the reader. Why is the database connection description file
in YAML and not in "a Ruby"?
I guess, because the feeling is that YAML is more recognizable as
user-editable config than a Ruby script, which would tend to frighten
some people off?
I was actually going to post this as a separate question for David
Black, since it arose in my reading of the section in his book
describing how Rails uses the Ruby syntactic freedom to make programming
more like editing a config file. My conjecture was that the database
config file was in YAML rather than Ruby because YAML is a more
user-friendly way to represent a *nested* set of key/value pairs than
the Ruby code.
In fact, maybe YAML is another shortcut in constructing DSLs, since
everything is text in a YAML file without all those nasty single or
double quotes getting in the way.
Well, C is not a great language for writing parsers in,
K & R and the rest of the UNIX founders apparently thought otherwise.
···
On 1 Oct 2006, at 11:40, M. Edward (Ed) Borasky wrote:
Oh great, an ever modifiable ruby DSL that we'll never be able to write a nice configuration tool against. What happened to embrace the constraint?
···
On Mon, 2 Oct 2006 04:32:49 +0900 "Wilson Bilkovich" <wilsonb@gmail.com> wrote:
On 10/1/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> Martin Coxall wrote:
> > In any case, there's a question about about to what extent you *should*
> > host DSLs internally. It's my feeling that if you want to inline a DSL
> > in your code, make sure that language is still syntactically
> > recognizably a Ruby. Ruby on Rails is a classic example.
>
> The problem I have with the two best-known Ruby DSLs, Rails and Rake, is
> the somewhat non-intuitive mix of words that don't begin with colons,
> and symbols, which do. And Rails requires YAML in some places that are
> jarring to the reader. Why is the database connection description file
> in YAML and not in "a Ruby"?
>
DHH mentioned at Canada on Rails (if I recall) that having
database.yml instead of database.rb was basically a beginner's
mistake, and that distant-future plans include turning that into a
Ruby script.
So, at least the rails core team agrees with you. Heh.
I was always wondering what this really means? Is it just the transformation of recursive calls at the end of a method into loops and therefore killing the stack overhead of recursions?
Cheers,
Mariano
···
On Oct 3, 2006, at 10:22 PM, Christian Neukirchen wrote:
Well ... Ruby has closures and continuations, but does it have the third
hallmark of Scheme -- efficient tail recursion?
Implementation detail. But I really wish it did...
Perhaps you could get the best of both worlds by "constraining" the
developers to writing a simple API with every new config file
"format", so that code could read and write it.
Or otherwise you could have:
include database.rb
include custom-that-modifies-some-settings.rb
...which can override whatever database.rb does.
But I agree that YAML is better for this.
Les
···
On 10/2/06, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
On Mon, 2 Oct 2006 04:32:49 +0900 > "Wilson Bilkovich" <wilsonb@gmail.com> wrote:
> On 10/1/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> > Martin Coxall wrote:
> > > In any case, there's a question about about to what extent you *should*
> > > host DSLs internally. It's my feeling that if you want to inline a DSL
> > > in your code, make sure that language is still syntactically
> > > recognizably a Ruby. Ruby on Rails is a classic example.
> >
> > The problem I have with the two best-known Ruby DSLs, Rails and Rake, is
> > the somewhat non-intuitive mix of words that don't begin with colons,
> > and symbols, which do. And Rails requires YAML in some places that are
> > jarring to the reader. Why is the database connection description file
> > in YAML and not in "a Ruby"?
> >
>
> DHH mentioned at Canada on Rails (if I recall) that having
> database.yml instead of database.rb was basically a beginner's
> mistake, and that distant-future plans include turning that into a
> Ruby script.
> So, at least the rails core team agrees with you. Heh.
>
Oh great, an ever modifiable ruby DSL that we'll never be able to write a nice configuration > tool against. What happened to embrace the constraint?
Yes. Scheme doesn't really have any looping constructs. Schemers do it all recursively, which forces you to think in interesting ways about problems. But if you got a stack overflow every time you looped through a large collection, it could rapidly become... annoying.
However, the tail-call optimization is just that- an optimization. An implementation detail. It's not a feature of the language per se, and could be added to Ruby without needing to make a single change to the language spec. In any case, if we really cared about VM efficiency, we wouldn't be Rubyists. ;p
Martin
···
On 3 Oct 2006, at 21:32, Mariano Kamp wrote:
On Oct 3, 2006, at 10:22 PM, Christian Neukirchen wrote:
Well ... Ruby has closures and continuations, but does it have the third
hallmark of Scheme -- efficient tail recursion?
Implementation detail. But I really wish it did...
I was always wondering what this really means? Is it just the transformation of recursive calls at the end of a method into loops and therefore killing the stack overhead of recursions?
> Oh great, an ever modifiable ruby DSL that we'll never be able to
> write a nice configuration tool against. What happened to embrace
> the constraint?
</grin>
Man, fame has made you mean...
Is that better?
···
On Mon, 2 Oct 2006 11:16:04 +0900 Devin Mullins <twifkak@comcast.net> wrote:
In article <29577979-9E2C-4C38-A7D6-14670ADE42D9@gmail.com>,
The K&R C specification is tiny. I wouldn't want to write a parser
for a language spec of the magnitude of C++ or Perl 6 in C.
Others would though, and those people are bonkers.
I've heard rumors of a Fortran compiler written in troff macros. Now
*that* is bonkers...
I hadn't heard that one. However, "f2c" and "p2c" (FORTRAN to C and
Pascal to C translators) were quite popular at one time before the good
GNUs started to spread.
Webserver in sed, my evidence is as solid as yours BTW, *I have heard*
Robert
···
On 10/2/06, Tim Smith <reply_in_group@mouse-potato.com> wrote:
In article <29577979-9E2C-4C38-A7D6-14670ADE42D9@gmail.com>,
Martin Coxall <pseudo.meta@gmail.com> wrote:
> The K&R C specification is tiny. I wouldn't want to write a parser
> for a language spec of the magnitude of C++ or Perl 6 in C.
>
> Others would though, and those people are bonkers.
I've heard rumors of a Fortran compiler written in troff macros. Now
*that* is bonkers...
--
--Tim Smith
--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.
On 10/2/06, Robert Dober <robert.dober@gmail.com> wrote:
On 10/2/06, Tim Smith <reply_in_group@mouse-potato.com> wrote:
>
> In article <29577979-9E2C-4C38-A7D6-14670ADE42D9@gmail.com>,
> Martin Coxall <pseudo.meta@gmail.com> wrote:
> > The K&R C specification is tiny. I wouldn't want to write a parser
> > for a language spec of the magnitude of C++ or Perl 6 in C.
> >
> > Others would though, and those people are bonkers.
>
> I've heard rumors of a Fortran compiler written in troff macros. Now
> *that* is bonkers...
>
> --
> --Tim Smith
Webserver in sed, my evidence is as solid as yours BTW, *I have heard*
