Forum: Ruby Nexus Programming Language

A new object-oriented programming language has been unofficially
released. There are some interesting details already published at the
in-progress website (www.nexuslang.org). The language is a marriage
between concepts introduced by Lua and Ruby. Strong influences from
both languages with an eye towards simplification. The language itself
introduces rarely seen strict left-to-right expression evaluation.
There is no implicit operator precedence, the programmer is forced to
be explicit with parenthetical expression, which has the added benefit
of readability. Another form of this strict left-to-right evaluation
is the assignment operator (^), rather then using the traditional
<variable> = <value> syntax, a value is put on the stack and then
assigned to one or more named memory location on the right (i.e.
1+2^a^b, a*b^c). Another interesting feature is the inclusion method
overloading.

On Sat, 21 Feb 2009 15:37:34 -0800, Avatar wrote:

> <value> syntax, a value is put on the stack and then assigned to one or
> more named memory location on the right (i.e. 1+2^a^b, a*b^c). Another
> interesting feature is the inclusion method overloading.

"There are no precedence rules applied to operators, they are simply
evaluated from left to right. Operator precedence is explicity applied
with the use of parenthetical expressions. The following example
demonstrates explicit operator precedence."

Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0,
that's not a good thing, and will confuse most mathemeticians to no end.
And the use of ^ for assignment will also be very unintuitive.

At the same time, I don't see *any* conceptual advantages over Ruby. 
Just
different, unintutitive, syntax.

--Ken

Ken Bloom <kbloom@gmail.com> writes:

>> readability. Another form of this strict left-to-right evaluation is the
> Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0, 
> that's not a good thing, and will confuse most mathemeticians to no end. 
> And the use of ^ for assignment will also be very unintuitive.
>
> At the same time, I don't see *any* conceptual advantages over Ruby. Just 
> different, unintutitive, syntax.

Well if you need to talk about no conceptual advantage and just
different unintuitive syntax, you can say the same of Ruby vs. Lisp.

Once you start creating gratuituous languages such as Ruby, why not go
on and change everything every years with a new gratuituously
different language. This year, let's all switch all to Nexus.  Next
year, I've got already another variant in preparation...


Just stop the sillyness, let's all use Common Lisp, the ultimate
programming language!

On Sun, Feb 22, 2009 at 5:29 PM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:

> Just stop the sillyness, let's all use Common Lisp, the ultimate
> programming language!
What does Common Lisp have that the Turing Machine does not have? As
you said yourself, let us stop being silly, Lisp is just a hype
because McCarthy could not stand Turing having invented a programming
language first.

Hopefully this helps a lot!!!!!!

BTW
I rather share Ken's point of view.

R.

> "There are no precedence rules applied to operators
>
> Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0,
> that's not a good thing, and will confuse most mathemeticians to no end.

My first association would have been Smalltalk. Anyway, I personally
do not think the world needs yet another esoteric programming language
unless that language introduces novel concepts unseen before.

t4l

t4l wrote:
>> "There are no precedence rules applied to operators
>>
>> Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0,
>> that's not a good thing, and will confuse most mathemeticians to no end.
> 
> My first association would have been Smalltalk. Anyway, I personally
> do not think the world needs yet another esoteric programming language
> unless that language introduces novel concepts unseen before.

Like cucumber?

Seriously - the best way to introduce novel concepts is add them to an 
existing
(and >cough< popular) language. Then you don't need to burn up time 
re-inventing
all the non-novel concepts.

Examples: Qt adding signals and slots to C++, or Groovy adding templates 
(IIRC)
to Java, or PHP adding a secure sandbox to Perl, or me adding 
RubyReflector to Ruby.

Brand new languages succeed primarily when they arrive at the same time 
as the
industry needs them. The industry _thought_ it needed Java for dynamic 
web
pages. It needed Ruby when Perl projects went mega-line. But 
(unfortunately for
some languages, and some novel concepts) the industry has to perceive 
the need, too!

On 22 Feb 2009, at 17:29, t4l wrote:
>> "There are no precedence rules applied to operators
>>
>> Looks like a cross between Ruby and INTERCAL. When  
>> 1.0+2.0/3.0+4.0=5.0,
>> that's not a good thing, and will confuse most mathemeticians to no  
>> end.
>
> My first association would have been Smalltalk. Anyway, I personally
> do not think the world needs yet another esoteric programming language
> unless that language introduces novel concepts unseen before.

You might as well say the world doesn't need another painting or
concept album unless it passes the same criterion. Personally I love
to see new languages even when I've no intention of using them and I
wish the Nexus team all the best with their baby: who knows where it
will lead?


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On 22.02.2009 17:26, Pascal J. Bourguignon wrote:

> Just stop the sillyness, let's all use Common Lisp, the ultimate
> programming language! 

Frankly, Pascal you're doing a bit too much Lisp advocacy recently.  Not
that I have anything against Lisp or you advocating it.  But I find it
impolite to do that in forum dedicated to a different programming 
language.

Cheers

  robert


PS: Yes, I know you probably did not mean it that serious but you're
bringing up that topic a bit too often for my taste.

Robert Klemme <shortcutter@googlemail.com> writes:

> Cheers
>
>   robert
>
>
> PS: Yes, I know you probably did not mean it that serious but you're
> bringing up that topic a bit too often for my taste.

I understand.  But in a thread in clr consacred to another programming
language, I though it was worthwhile to mention it.  I see all these
younglings searching and searching, trying to invent yet another
language, and not seeing that what they're tending to is just Lisp.

If you specify a language with silly precedence rules, it just gives
the definitive incentive to put PARENTHESES around each subexpression.

From the Documentation:

------------------

3.3 - Arrays

{}         // an empty array (with no elements)
{1,2,3}    // an array of three elements
{1,{2,3}}  // a nested array

3.4 - Tables

_{}                     // an empty table (with no entries)
_{"a";1, "b";2, "c";3}  // a table of three entries

3.5 - Maps

#{}                     // an empty map (with no entries)
#{"a";1, "b";2, "c";3}  // a map with three entries

4 - Variables

name   // local variable
$name  // global variable
@name  // object field
Name   // class field

----------------

*COUGH* People HATE Perl's crazy confusing symbol variable designation
rules. What's the difference between a Table and a Map? Why does it
use the semi-colon as a map operator?

And as what other people said previously: ^ for assignment operator?
wow, that's insanely difficult to read.

I'd rather go learn OCaml than this, sorry. There's a reason languages
use a lot of the same syntax, ideas, and operators: people are used to
them. [] is an array / list, {} is a hash / map / table, = is
assignment (can be := if you want = to be comparison). I see nothing
here but backwards steps.

And no operator precedence? The reason this is rarely seen is because
it's *wrong*. 1 + 2 / 4 is ALWAYS 3. That's math. Building a language
that calculates this expression to 3/4 is a bug and will cause nothing
but rampant confusion and frustration.

Jason

Jason Roelofs wrote:
> And no operator precedence? The reason this is rarely seen is because
> it's *wrong*. 1 + 2 / 4 is ALWAYS 3. That's math. Building a language
> that calculates this expression to 3/4 is a bug and will cause nothing
> but rampant confusion and frustration.

APL\360 was amazingly popular and it had no operator precedence either.
However, the default was right-to-left, not left-to-right as Nexus has
chosen.

But yeah, who the heck needs another language that's poorly thought out,
when Factor, Joy, Eiffel, Dylan, and dozens of other well-thought-out
languages burst on the scene and drifted into oblivion? And why not
Fortress?

--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Mon, Feb 23, 2009 at 8:42 AM, M. Edward (Ed) Borasky
<zznmeb@gmail.com> wrote:
>
> But yeah, who the heck needs another language that's poorly thought out,
> when Factor, Joy, Eiffel, Dylan, and dozens of other well-thought-out
> languages burst on the scene and drifted into oblivion? And why not
> Fortress?

I think Joy, at least, is *influential* - language designers seem to
pay attention to it, even if users don't.

martin

On Mon, Feb 23, 2009 at 10:06 AM, Jason Roelofs 
<jameskilton@gmail.com>wrote:

>
>
> And no operator precedence? The reason this is rarely seen is because
> it's *wrong*. 1 + 2 / 4 is ALWAYS 3. That's math. Building a language
> that calculates this expression to 3/4 is a bug and will cause nothing
> but rampant confusion and frustration.
>

There certainly seems to be a bug here somewhere ;-)

Pascal J. Bourguignon wrote:

> > programming language.
> language, I though it was worthwhile to mention it.  I see all these
> younglings searching and searching, trying to invent yet another
> language, and not seeing that what they're tending to is just Lisp.

Post some Commune Lisp solutions to some programming problems.
I think it will be fun to compare them to Ruby solutions.

Commune Lisp code is incredibly bloated, inelegant, and ugly.
Those who use it seem to delight in writing 10 lines of code
when 1 line should do.

Those who use it have no taste.



Bernard Lang:

Common Lisp did kill Lisp. Period.

  (just languages take a long time dying ...)

It is to Lisp what C++ is to C.  A monstrosity that totally ignores
the basics of language design, simplicity and orthogonality to begin
with.



Gilles Kahn:

To this day I have not forgotten that Common Lisp killed Lisp, and
forced us to abandon a perfectly good system, LeLisp.



Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.



Jeffrey M. Jacobs:

Common LISP is the PL/I of Lisps.  Too big and
too incomprehensible, with no examiniation of the real world of
software engineering.

...  The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and then we'll all
go down the tubes".  Everybody had vested interests, both financial
and emotional.

CL is a nightmare; it has effectively killed LISP development in this
country.  It is not commercially viable and has virtually no future
outside of the traditional academic/defense/research arena.




Dick Gabriel:

Common Lisp is a significantly ugly language.  If Guy and I had been
locked in a room, you can bet it wouldn't have turned out like that.



Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct.  We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general.  ---  Daniel Weinreb, 24 Feb 2003




I have found that the disciples of Commune Lisp (CL) are literally
that---disciples.   They are completely irrational in their
religious devotion to the language.  I suspect that to them,
CL stands for the name of their god: Commode Lord.


If you want to use a Lisp, I suggest Clojure.

> Common Lisp

Even though PJB seems to be an cl advocate, the question isn't so much
cl vs other lisp dialects (this is a discussion that should be
restrained to comp.lang.lisp) but rather lisp vs non-lisp (when such a
discussion is held on ruby-talk).

The proposition in question is that any (dynamically typed) language
eventually ends up being as complex as a full-fledged lisp. PJB's
suggestion seems to be: Then why not use a standardized lisp like cl
right away?

Anyway, I think there is a reason why lisps haven't gained world
domination yet. They would have been around long enough for that. I
think the suggestion can be rejected on empirical grounds.

Clojure on the other hand ... BTW does somebody know jruby vs clojure
benchmarks? Actual clojure benchmarks seem to be rare.

Tom Link wrote:

> Anyway, I think there is a reason why lisps haven't gained world
> domination yet. They would have been around long enough for that. I
> think the suggestion can be rejected on empirical grounds.

I would like to invent the kind of language that causes its advocates 
such
Stockholm Syndrome devotion that they all make pests of themselves on 
each and
every other languages' forum in the world...

On Mon, Feb 23, 2009 at 01:09:34AM +0900, Ken Bloom wrote:
> 
> "There are no precedence rules applied to operators, they are simply 
> evaluated from left to right. Operator precedence is explicity applied 
> with the use of parenthetical expressions. The following example 
> demonstrates explicit operator precedence."
> 
> Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0, 
> that's not a good thing, and will confuse most mathemeticians to no end. 
> And the use of ^ for assignment will also be very unintuitive.

This is why I tend to think that positional precedence should always use
named functions (or methods or whatever) instead of traditional
mathematical sigils, and use either prefix or postfix notation.  For
instance:

    sum( quotient( sum( 1.0, 2.0 ), 3.0 ), 4.0 )

. . . or as UCBLogo would put it:

    sum quotient sum 1.0 2.0 3.0 4.0

. . . or:

    sum (quotient (sum 1.0 2.0) 3.0) 4.0

. . . if you really want parentheses or need different numbers of
operands for each operator/function than the default two arguments.  In
the same language, you can still do:

    (1.0 + 2.0) / 3.0 + 4.0

. . . to get 5.0, if you really want to do it the traditional precedence
way.  I wish more languages offered named prefix operators like that.
Ruby's .method syntax is pretty nice, too, though:

    1.0.+(2.0)./(3.0).+4.0

. . . as long as you aren't working with floating point numbers, since
all those extra dots/decimals look *awful* strung together like that.

Pascal J. Bourguignon wrote:
> If you specify a language with silly precedence rules, it just gives
> the definitive incentive to put PARENTHESES around each subexpression.

Sure. But why would anyone want to write something like

    a = b + c

when they could just as easily have written

    (set!
       (quote a)
       (+ b c))

instead?

(Note: untested and probably wrong. I have a sneaking suspicion that 
set! may be a special-form and so doesn't require its first argument to 
be quoted. Of course, there is no clue to this in the syntax, or lack of 
it. That's also ignoring any differences between Scheme and LISP)

On 23 Feb 2009, at 12:38, Chad Perrin wrote:
>> that's not a good thing, and will confuse most mathemeticians to no  
>
> . . . or as UCBLogo would put it:
>
>    sum quotient sum 1.0 2.0 3.0 4.0


how about:

1 2 + 3 / 4 +

I always liked Forth's RPN simplicity :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On Mon, Feb 23, 2009 at 1:48 PM, Brian Candler <b.candler@pobox.com> 
wrote:
> Pascal J. Bourginon
>    (set!
>       (quote a)
are you sure about this
>       (+ b c))
No wonder Lisp has such a bad reputation if everyone is making fun out 
of it.
That is not fair, leave Pascal alone!!!!!!
Mean guys, if you are not happy about CL, why do you post to the CL
mailing list than. Better go somewhere else, maybe ruby-talk?
R.

On Sun, Feb 22, 2009 at 11:57 PM, Martin DeMello
<martindemello@gmail.com> wrote:
> On Mon, Feb 23, 2009 at 8:42 AM, M. Edward (Ed) Borasky
> <zznmeb@gmail.com> wrote:
>>
>> But yeah, who the heck needs another language that's poorly thought out,
>> when Factor, Joy, Eiffel, Dylan, and dozens of other well-thought-out
>> languages burst on the scene and drifted into oblivion? And why not
>> Fortress?
>
> I think Joy, at least, is *influential* - language designers seem to
> pay attention to it, even if users don't.

Joy and Factor are essentially dialects of Forth that attempt to add
some elegance and a functional language perspective. IMHO neither one
of them is as elegant and practical as the RPL language HP put into
the HP-28, 48 and 49 calculators. If you're going to make a reverse
Polish language, RPL is the way to do it.
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

Robert Dober wrote:
> On Mon, Feb 23, 2009 at 1:48 PM, Brian Candler <b.candler@pobox.com> 
> wrote:
>> Pascal J. Bourginon
>>    (set!
>>       (quote a)
> are you sure about this

No, I am not - see footnote to my posting. When is something which looks 
like a function application not actually a function application?

Other languages have their own magic of course. In C/Pascal derived 
languages you have 'lvalues' and 'rvalues', and the assignment operator 
takes an lvalue on the left and an rvalue on the right. The special 
semantics are highlighted by special syntax.

Anyway, this is way off topic. Sorry.

Brian Candler <b.candler@pobox.com> writes:

>     (set!
>        (quote a)
>        (+ b c))
>
> instead?
>
> (Note: untested and probably wrong. I have a sneaking suspicion that 
> set! may be a special-form and so doesn't require its first argument to 
> be quoted. 

In Scheme, there's no option.  It's: (set! a (+ b c))

The point is that whatever the 'message' you 'send', whatever the
'function' you 'call', you always write it the same:

          (<operator>  <argument> <argument> ...)

This allow to process easily any expression, with no parsing, and with
no knownledge of the operators (and their arity or variable arity).

These expression can be processed by user code, by macros, (of course
by the scheme compilers), but also by trivial tools  such as editors,
who need only to know how to count parentheses to correctly parse
lisp expressions.

That's the reason why, since Ruby has some lisp genes, and allows it,
I write my ruby code as:

     (a = (b + c))

It's a little harder than in lisp, because you have strange rules and
exceptions, you have to put the first argument first instead of the
operator (while of all times, in maths you've learned to put the
operator first:  f x,  Σ n,  etc).

But you can see that it's about he same form, and not more complex in
lisp than in ruby:

     (a    = (b + c))
     (set! a (+ b c))

And this allows me to benefit from the structural editing functions of
my editor.


Unfortunately the similarties stop there, and when you need to do
metaprogramming in Ruby, you have to invoke complex parser packages,
and use barbaric syntaxes with a lot of useless characters such as:

    [:=,:a,[:+,:b,:c]]

instead of the simply:

   '(=    a (+ b c))

or just:

   '(set! a (+ b c))

It would not have costed anything to leave the quote operator alone...



> Of course, there is no clue to this in the syntax, or lack of 
> it. That's also ignoring any differences between Scheme and LISP)

In the case of Common Lisp, you don't have "syntactic" clues pers se,
but there are naming conventions for the operators, (and otherwise not
being totally dumb, lisp programmers try to give meaningful names to
their functions to give enough hints), so you can know that:

    (set  (quote <symbol>)  <expression>)

becomes as a shorthand:

    (setq        <symbol>   <expression>)  ; notice the q in setq, which
                                           ; stands for quote.

or the more modern:

    (setf <place> <expression>)            ; the f stands for form, 
since <place>
                                           ; can be (almost) any form.

On Mon, Feb 23, 2009 at 09:48:44PM +0900, Eleanor McHugh wrote:
> >>1.0+2.0/3.0+4.0=5.0,
> >   sum( quotient( sum( 1.0, 2.0 ), 3.0 ), 4.0 )
> I always liked Forth's RPN simplicity :)
I don't much like combining postfix notation with right-to-left
evaluation.  I tend to think that the notation should "precede" the
operands in the direction in which operations are evaluated.  Of course,
that's more a matter of familiarity and comfort for me than any kind of
objective criteria (other than consistency with traditional function
notation), but it's how I feel.

In other words, if the operator notation is going to be placed to the
right of the operands, I'd prefer operands be evaluated right-to-left.

Of course, I don't think *anyone* would like the way that would look, so
that pretty much breaks down to preferring prefix notation over postfix
notation.

> Of course, I don't think *anyone* would like the way that would look, so
> that pretty much breaks down to preferring prefix notation over postfix
> notation.

A little history:

1. Polish notation was originally prefix. It was invented by the
Polish logician Lukaciewicz because it removed parentheses, and was
called "Polish" notation because people had trouble spelling and
pronouncing his name. And yes, I looked it up to get it right. :)

2. That was pretty much that until computers and programming languages
came on the scene. But in the olden days, when every electron was
precious and compactness and efficiency were of the utmost import, it
turned out that *reverse* Polish notation was *slightly* more
efficient. If you look at a parser for algebraic expressions and the
resulting run-time execution engine, you'll see that.

3. Lisp used prefix notation because McCarthy was a disciple of Church
and Church used it. Forth used reverse Polish notation because Chuck
Moore had taken apart the Burroughs compilers and stack architecture
and determined that it was the way to go for maximum compactness and
efficiency.

But the efficiency differences really are negligible these days, and
Lisp / Scheme are much more popular than Forth. Incidentally, the RPL
stands for "Reverse Polish Lisp".
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On 23 Feb 2009, at 19:47, Chad Perrin wrote:
> of
> notation.
But postfix notation is just so natural: load operands on the stack;
operate on operands; get result from stack. Imagine how sweet Lisp
would be without all those damn parentheses:

Brian Candler <b.candler@pobox.com> writes:
> Sure. But why would anyone want to write something like
>
>    a = b + c
>
> when they could just as easily have written
>
>    (set!
>       (quote a)
>       (+ b c))

  b c + set! a

is much easier on the eye :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On Mon, Feb 23, 2009 at 12:21 PM, Eleanor McHugh
<eleanor@games-with-brains.com> wrote:
> Imagine how sweet Lisp would be without
> all those damn parentheses:

The parentheses are in Lisp because functions (and special forms) have
variable arity. If they had fixed arity the parentheses would not be
required. But since S-expressions were defined using parentheses and
Lisp wanted programs to look like S-expressions, variable arity was
thrown in as a bonus. :)
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Feb 23, 2:21 pm, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> Imagine how sweet Lisp would be without all those damn parentheses

But then what would Pascal do with all his newfound free time?

On Mon, Feb 23, 2009 at 8:21 PM, Eleanor McHugh
<eleanor@games-with-brains.com> wrote:
> But postfix notation is just so natural: load operands on the stack; operate
> on operands; get result from stack. Imagine how sweet Lisp would be without
> all those damn parentheses:

But like all obvious elegant simple things, it took someone really
smart working hard to figure it out. See
http://en.wikipedia.org/wiki/Charles_Leonard_Hamblin, IMHO one of the
great unrecognised pioneers of computer science.

Regards,
Sean

Pascal J. Bourguignon wrote:

> These expression can be processed by user code, by macros, (of course
> by the scheme compilers), but also by trivial tools  such as editors,
> who need only to know how to count parentheses to correctly parse
> lisp expressions.

This might be true, but lisp expressions are hard for humans to parse.
The same goes for XML.

> The parentheses are in Lisp because functions (and special forms) have
> variable arity.

This isn't necessarily true, see eg:

http://lambda-the-ultimate.org/node/1646
http://srfi.schemers.org/srfi-49/srfi-49.html

So you can have lisp without parentheses if you can live with that
pythonesque indentation thing -- I personally would prefer the
parentheses though which are quite easy to read when you're used to
it.

To a certain extent I can actually understand Pascal's sympathy for
lisp. The problem with lisp rather is useless (Scheme) or bloated (CL)
standards.

On Mon, Feb 23, 2009 at 10:02 PM, Yossef Mendelssohn <ymendel@pobox.com> 
wrote:
> On Feb 23, 2:21 pm, Eleanor McHugh <elea...@games-with-brains.com>
> wrote:
>> Imagine how sweet Lisp would be without all those damn parentheses
>
> But then what would Pascal do with all his newfound free time?
Do you mean the person or the language?

This is the best thread ever, well to relax at least ....;)
R.

No one's mentioned that the earliest versions of VisiCalc
used left-to-right precendence.  I suspect this was due to
the need to shoehorn as much as possible into the tiny
footprints of the time, and not any attempt to promote
a new visionary approach to arithmetic.  I don't know
if VC switched once 8K chips became standard issue, but
Lotus 1-2-3 certainly supported the order of precedence
we all learned in grade school.

Also at OSCON a few years ago Damian Conway, speaking from
personal experience, claimed that any modern language that
doesn't use a single '=' to indicate assignment is doomed to
failure.  Having been on the wrong end of that argument
I wouldn't hesitate to agree.

- Eric

On Tue, Feb 24, 2009 at 06:41:07AM +0900, Nico Bonada wrote:
> Pascal J. Bourguignon wrote:
> 
> > These expression can be processed by user code, by macros, (of course
> > by the scheme compilers), but also by trivial tools  such as editors,
> > who need only to know how to count parentheses to correctly parse
> > lisp expressions.
> 
> This might be true, but lisp expressions are hard for humans to parse.
> The same goes for XML.

That's why the original conception of LISP used an m-expression syntax
rather than an s-expression syntax.  The s-expression syntax was 
intended
to be an intermediate compilation step, but the Lisp community way back
in the day just kinda stopped at s-expressions and declared it "done".

On Tue, Feb 24, 2009 at 06:59:57AM +0900, Tom wrote:
> 
> So you can have lisp without parentheses if you can live with that
> pythonesque indentation thing -- I personally would prefer the
> parentheses though which are quite easy to read when you're used to
> it.

UCBLogo gives a hint to how you can do it without either the significant
whitespace of Python or the ubiquitous parentheses of Common Lisp.  In
fact, UCBLogo basically *is* a LISP implementation.


> 
> To a certain extent I can actually understand Pascal's sympathy for
> lisp. The problem with lisp rather is useless (Scheme) or bloated (CL)
> standards.

. . . or ignored (UCBLogo), or vaporous (Arc).

On Tue, Feb 24, 2009 at 07:49:24AM +0900, Eric Promislow wrote:
> 
> Also at OSCON a few years ago Damian Conway, speaking from
> personal experience, claimed that any modern language that
> doesn't use a single '=' to indicate assignment is doomed to
> failure.  Having been on the wrong end of that argument
> I wouldn't hesitate to agree.

I'm actually of the opinion that the "need" to differentiate between the
assignment operator and the equality comparison operator is a failure of
language syntactic design, and not the universal necessity everyone 
seems
to assume.

On Feb 23, 2009, at 5:49 PM, Eric Promislow wrote:
> Also at OSCON a few years ago Damian Conway, speaking from
> personal experience, claimed that any modern language that
> doesn't use a single '=' to indicate assignment is doomed to
> failure.  Having been on the wrong end of that argument
> I wouldn't hesitate to agree.

Interesting.  The problems caused by = vs == would seem to
be a counter argument.

I always liked Eiffel's choice of := for assignment and
a single = for comparison.

Gary Wright

On 24 Feb 2009, at 00:15, Gary Wright wrote:
> I always liked Eiffel's choice of := for assignment and
> a single = for comparison.

One of the many things I like about Icon and Unicon is that := for
assignment is augmented by :=: for exchanging values between two
variables. It'd be even neater if =: was also defined...


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Eric Promislow wrote:
> No one's mentioned that the earliest versions of VisiCalc
> used left-to-right precendence.  I suspect this was due to
> the need to shoehorn as much as possible into the tiny
> footprints of the time, and not any attempt to promote
> a new visionary approach to arithmetic.


Having been messing around with my own little language, it was much
easier to make all binary operators equal and apply them left-to-right.
It also makes it easy to have arbitrary binary operators, because they
are all treated the same.


> Also at OSCON a few years ago Damian Conway, speaking from
> personal experience, claimed that any modern language that
> doesn't use a single '=' to indicate assignment is doomed to
> failure.  Having been on the wrong end of that argument
> I wouldn't hesitate to agree.

In my estimation, assignment is performed more often than equality, so I
agree I'd rather have that be a single keypress.

-Justin

On Feb 23, 3:21 pm, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> > evaluation.  I tend to think that the notation should "precede" the
> > Of course, I don't think *anyone* would like the way that would  
> > Sure. But why would anyone want to write something like
>
> is much easier on the eye :)
>
> Ellie
>
> Eleanor McHugh
> Games With Brainshttp://slides.games-with-brains.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason

The Nexus (left-to-right) assignment operator '^' is also referred to
as the 'goes to' operator. The choice of symbol is meaningful, you
might think of the '^' character as an arrow meaning the value you
just put on the stack (the left side of the expression) 'goes to' to
the memory location (i.e. variable) on the right-side of the
expression (i.e. 123^x, 123 'goes to' x).

Gary Wright wrote:

> I always liked Eiffel's choice of := for assignment and
> a single = for comparison.

That is just foolish. You assign more often than you compare, hence you 
should
use the mechanism that's easier to type.

Just because some math professor somewhere experiences a cheap thrill of
self-righteous indignation, seeing = used for assignment, doesn't mean 
we
programmers should be condemned to eternally typing the longer and 
uglier operator.

On Feb 23, 2009, at 9:49 PM, Phlip wrote:

> Gary Wright wrote:
>
>> I always liked Eiffel's choice of := for assignment and
>> a single = for comparison.
>
> That is just foolish. You assign more often than you compare, hence  
> you should use the mechanism that's easier to type.


Foolish? Seems a bit strong.

There are lots of errors caused by = vs ==.  How much time is lost in
that regard?  I think an hour of debugging time is worth a whole lot
of :'s.

Gary Wright

On Sun, Feb 22, 2009 at 11:29 AM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
>>> is no implicit operator precedence, the programmer is forced to be
>> demonstrates explicit operator precedence."
>>
>> Looks like a cross between Ruby and INTERCAL. When 1.0+2.0/3.0+4.0=5.0,
>> that's not a good thing, and will confuse most mathemeticians to no end.
>> And the use of ^ for assignment will also be very unintuitive.
>>
>> At the same time, I don't see *any* conceptual advantages over Ruby. Just
>> different, unintutitive, syntax.
>
> Well if you need to talk about no conceptual advantage and just
> different unintuitive syntax, you can say the same of Ruby vs. Lisp.

Why are you subscribed to ruby-talk if you hate Ruby so much?  Is
someone forcing you to use it?  And if so, how is that our problem.

-greg

Gregory Brown wrote:

> On Sun, Feb 22, 2009 at 11:29 AM, Pascal J. Bourguignon
....
> > Well if you need to talk about no conceptual advantage and just
> > different unintuitive syntax, you can say the same of Ruby vs. Lisp.
> 
> Why are you subscribed to ruby-talk if you hate Ruby so much?  Is
> someone forcing you to use it?  And if so, how is that our problem.
> 
> -greg

He's harmless.  CL (Commode Lord) is so bloated and hideous
that only a religious zealot would use it.

Gary Wright wrote:

> 
> On Feb 23, 2009, at 9:49 PM, Phlip wrote:
> 
> > Gary Wright wrote:
> > 
> >> I always liked Eiffel's choice of := for assignment and
> >> a single = for comparison.

That dates back to Pascal.

> > 
> > That is just foolish. You assign more often than you compare, hence  
> > you should use the mechanism that's easier to type.
> 
> 
> Foolish? Seems a bit strong.
> 
> There are lots of errors caused by = vs ==.  How much time is lost in  
> that regard?  I think an hour of debugging time is worth a whole lot  
> of :'s.

C:

if (over_run = -1)
  self_destruct();

I often arrange my comparisons like

if -1 = over_run

On Tue, Feb 24, 2009 at 02:59:27PM +0900, William James wrote:
> 
> He's harmless.  CL (Commode Lord) is so bloated and hideous
> that only a religious zealot would use it.

I . . . don't think that's really productive at all.  Common Lisp still
has its advantages as a language, even if it's not the LISP many people
wish it could be.

On Tue, Feb 24, 2009 at 11:49:23AM +0900, Phlip wrote:
> Gary Wright wrote:
> 
> >I always liked Eiffel's choice of := for assignment and
> >a single = for comparison.
> 
> That is just foolish. You assign more often than you compare, hence you 
> should use the mechanism that's easier to type.

Actually, depending on the programming style you employ, that may not be
true.  The more "functional" your programming style, the less you're
likely to employ assignments, for instance.

On Mon, Feb 23, 2009 at 10:04 PM, William James <w_a_x_man@yahoo.com> 
wrote:
> That dates back to Pascal.
Actually it dates back to Algol. The people who designed it did it for
a reason, but I can't remember what it was. I think it was to remind
people that assignment was not equality, and the purists pronounce

a := b

as "a becomes b".
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

> I . . . don't think that's really productive at all.  Common Lisp still
> has its advantages as a language, even if it's not the LISP many people
> wish it could be.

Having learned Lisp as Lisp 1.5, I'm much more inclined to Scheme than
Common Lisp, because Scheme fixed a lot of the warts on Lisp 1.5.
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Tue, Feb 24, 2009 at 12:59 AM, William James <w_a_x_man@yahoo.com> 
wrote:
>> -greg
>
> He's harmless.  CL (Commode Lord) is so bloated and hideous
> that only a religious zealot would use it.

Just to clarify... my question was not meant to be patronizing.  My
point is that Pascal would probably benefit more by advocating Common
Lisp in more general forums rather than trying to 'convert' folks who
are interested in Ruby.  I don't think your flame-bait has helped
support that point at all.  That said, kill-files solve problems like
this much faster than long discussions about Netiquette do.

-greg

Avatar wrote:
>>>> 1 2 + 3 / 4 +
>>> notation), but it's how I feel.
>> But postfix notation is just so natural: load operands on the stack;  
>>>       
>> Eleanor McHugh
> expression (i.e. 123^x, 123 'goes to' x).
>
>
>   
A most fascinating thread, coming from a very distant universe, as I do.

As for this use of "^", it is about as needless as yet another poem
about a flower. Don't we already have one, somewhere? I fully realize
that calculation (computer) languages are not poems, but they ARE
containers for thought, and in that they are brothers/sisters to poems.

I'm with Eleanor in loving the exploration of different ways of
thinking/working with stuff (and in having an appreciation for the
elgance of RPN). A large part of the sheer burst of joy that grabbed me
and threw me into the Ruby world, on the occasion of my fifth look at
the language, was the delight I experienced upon finally understanding
that this language was "working" the notion that everything could be an
object, and have access to methods belonging to the class of which it
was a member. The sheer elegance of this was new to me and is still a
very major delight.

So, I have to wonder, when meeting up with a new language, if maybe I'm
about to hear my first Stravinsky ballet, or perhaps run into something
like Spencer Brown's "Laws of form" (1972). Beauty is found in strange
places. If we're all lucky, the Nexus project will come up with some
we've not seen yet. That would be most excellent, howsoever difficult it
may be to achieve.

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

M. Edward (Ed) Borasky wrote:
>> Of course, I don't think *anyone* would like the way that would look, so
>
> and determined that it was the way to go for maximum compactness and
> efficiency.
>
> But the efficiency differences really are negligible these days, and
> Lisp / Scheme are much more popular than Forth. Incidentally, the RPL
> stands for "Reverse Polish Lisp".
>   
Very interesting Ed. Thanks for the contribution. ~t

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Tue, 24 Feb 2009 05:54:58 +0000, William James wrote:

>> -greg
> 
> He's harmless.  CL (Commode Lord) is so bloated and hideous that only a
> religious zealot would use it.

(Yeah but (He) (uses (strange syntax)))
((he) (just might convince (some newbie) (to program Ruby) (as though
((it) (were (LISP)))))

--Ken

Gregory Brown <gregory.t.brown@gmail.com> writes:

>>>> languages with an eye towards simplification. The language itself
>>> evaluated from left to right. Operator precedence is explicity applied
>> Well if you need to talk about no conceptual advantage and just
>> different unintuitive syntax, you can say the same of Ruby vs. Lisp.
>
> Why are you subscribed to ruby-talk if you hate Ruby so much?  Is
> someone forcing you to use it?  And if so, how is that our problem.

If you were using CL (if more people were using CL), and Ruby were not
invented, more bosses would let us use CL as a dynamic language, and
indeed we wouldn't be forced to use Ruby (or worse, perl or python).

Of course, you share the culpability with perl, PHP, Python, Java and
so on.

But I'm mostly justified in thinking this, by the authors of most of
these languages themselves.  Some of these authors are just poor chaps
not knowing better, but some other including Java and Ruby knew very
well Lisp, and instead of choosing to help develop and spread lisp,
they voluntarily chosed to create different and inferior languages,
picking only parts of lisp, and grafting over their abortive creation
some monstruous syntax.

The fact that these monstruous syntaxes view good in the eyes of the
unwashed masses, and that the lack of features (when it's not just the
inclusion of misfeatures) is oblivious to the same masses IS NOT an
excuse.

The only result is that Lisp is relegated as just an elegant weapon
from a more civilized time, still mastered only by a few remaining
Jedi.

But there is still hope!

This is perhaps the good that will come from these evils.  A lot of
programmers are now exposed on the goodness of dynamic languages, and
they may notice (or if not by themselves, *I* will try to make them
notice in threads like this), that their fad language of the day, is
actually some incomplete subset of Lisp, and then why not use the full
and authentic thing?  Common Lisp is this way!


PS: I'm not subscribed to "Ruby-Talk", there's a gateway between this
    mail-list and news:comp.lang.ruby.

On Feb 24, 2:02 am, "M. Edward (Ed) Borasky" <zzn...@gmail.com> wrote:
> > That dates back to Pascal.
>
> Actually it dates back to Algol. The people who designed it did it for
> a reason, but I can't remember what it was. I think it was to remind
> people that assignment was not equality, and the purists pronounce
>
> a := b
>
> as "a becomes b".

If I ever design my own programming language, I'm going to use := for
assignment and == for equality, and let a single = be a syntax error,
just to avoid the whole confusion.

On Tue, Feb 24, 2009 at 1:44 PM, karlvonl <doodpants@mailinator.com> 
wrote:
>>
> If I ever design my own programming language, I'm going to use := for
> assignment and == for equality, and let a single = be a syntax error,
> just to avoid the whole confusion.

Not a bad idea.

-greg

On Tue, Feb 24, 2009 at 04:05:18PM +0900, M. Edward (Ed) Borasky wrote:
> 
> Having learned Lisp as Lisp 1.5, I'm much more inclined to Scheme than
> Common Lisp, because Scheme fixed a lot of the warts on Lisp 1.5.

I've never really gotten past the initial playing-around stage with
either of them, but from my *very* scant experience, and from what I 
know
of the two languages indirectly, I'm more inclined toward Scheme as 
well.

I still don't think the previous comments were very productive, though,
and they really didn't need to be said in that context.

Pascal J. Bourguignon wrote:
> Gregory Brown <gregory.t.brown@gmail.com> writes:
> 
> ...
 >
>> Why are you subscribed to ruby-talk if you hate Ruby so much?  Is
>> someone forcing you to use it?  And if so, how is that our problem.
> 
> If you were using CL (if more people were using CL), and Ruby were not
> invented, more bosses would let us use CL as a dynamic language, and
> indeed we wouldn't be forced to use Ruby (or worse, perl or python).
> 

What perfidy!  Won't someone loosen your chains?

I bet your boss won't let you throw in lots of parentheses in your
Perl code, too.

> Of course, you share the culpability with perl, PHP, Python, Java and
> so on.

Oh, the humanity!

> 
> But I'm mostly justified in thinking this, by the authors of most of
> these languages themselves.  Some of these authors are just poor chaps
> not knowing better, but some other including Java and Ruby knew very
> well Lisp, and instead of choosing to help develop and spread lisp,
> they voluntarily chosed to create different and inferior languages,
> picking only parts of lisp, and grafting over their abortive creation
> some monstruous syntax.

I know what you mean.  I can't understand why people choose to use
such inferior and wimpy regular expression engines when they could
be experiencing the full power of snobol4 pattern matching.

> 
> The fact that these monstruous syntaxes view good in the eyes of the
> unwashed masses, and that the lack of features (when it's not just the
> inclusion of misfeatures) is oblivious to the same masses IS NOT an
> excuse.

Yes, it's all bread and circuses to us.  The world's morals have
truly been weakened by a language that deigns to make users happy!

> 
> The only result is that Lisp is relegated as just an elegant weapon
> from a more civilized time, still mastered only by a few remaining
> Jedi.

And you consider yourself one such Jedi?  I wonder.  I sense much
fear in you, young one.

Every once in a while you should raise the blast shield and look
around.  Even a Jedi will use a Perl blaster when he needs to.

> 
> But there is still hope!

So you're the one prophesied to bring balance to the Language Force.
Great!

> 
> This is perhaps the good that will come from these evils.  A lot of
> programmers are now exposed on the goodness of dynamic languages, and
> they may notice (or if not by themselves, *I* will try to make them
> notice in threads like this), that their fad language of the day, is
> actually some incomplete subset of Lisp, and then why not use the full
> and authentic thing?  Common Lisp is this way!

Impressive, young Skyparenthesizer.  And here I thought Darth Java
had won the Clone/Dup/Bloat War.

You will try to make us notice?  There is no 'try'.  You will find
that leads only to the Dark Side.

Isn't there a better way?  Maybe you can do for CL what others have
done for Java and .Net?  Were you to do that, you'd have more fans
than parentheses.

On [Wed, 25.02.2009 01:14], Pascal J. Bourguignon wrote:
> 
> This is perhaps the good that will come from these evils.  A lot of
> programmers are now exposed on the goodness of dynamic languages, and
> they may notice (or if not by themselves, *I* will try to make them
> notice in threads like this), that their fad language of the day, is
> actually some incomplete subset of Lisp, and then why not use the full
> and authentic thing?  Common Lisp is this way!
> 
> 

In all honesty, but this seriously sounds pretty much like a speech of
a religious fanatic. "We are superior, let us enlighten you".

And just as a hint: by pissing off about everybody on a list, news
group or whatever you are hardly going to achieve your aim.
You aren't showing how "cool" Lisp is, but how narrow minded,
oldfashioned and ignorant Lisp users seem to be. (I know that I am not
allowed to generalize it, and I already apologize to sane Lisp users,
but *you* in particular are just a bad example, not achieving
anything).

We haven't chosen Ruby for no reason, most of us have used other
languages as well, for quite some time, that is, and it is *our*
decission whether we use Ruby, Lisp or BASIC...

Use your CL, be happy, but for god's sake, don't be an zealot...

On Wed, Feb 25, 2009 at 01:14:20AM +0900, Pascal J. Bourguignon wrote:
> 
> If you were using CL (if more people were using CL), and Ruby were not
> invented, more bosses would let us use CL as a dynamic language, and
> indeed we wouldn't be forced to use Ruby (or worse, perl or python).
> 
> Of course, you share the culpability with perl, PHP, Python, Java and
> so on.

[snip a bunch more of the same offensive nonsense]

You're just acting like a troll, now.  Please stop.

On Tue, Feb 24, 2009 at 05:07:05AM +0900, M. Edward (Ed) Borasky wrote:
> 
> 2. That was pretty much that until computers and programming languages
> came on the scene. But in the olden days, when every electron was
> precious and compactness and efficiency were of the utmost import, it
> turned out that *reverse* Polish notation was *slightly* more
> efficient. If you look at a parser for algebraic expressions and the
> resulting run-time execution engine, you'll see that.

More than that -- and still relevant today -- parsers for Polish 
notation
are generally more difficult to *write*.  I know -- I've tried designing
both Polish notation parsers and RPN parsers.  In fact, Polish notation
parsers are more difficult to write for essentially the same reason that
RPN parsers are slightly more efficient from the machine's point of 
view.


> 
> 3. Lisp used prefix notation because McCarthy was a disciple of Church
> and Church used it. Forth used reverse Polish notation because Chuck
> Moore had taken apart the Burroughs compilers and stack architecture
> and determined that it was the way to go for maximum compactness and
> efficiency.

McCarthy was really ahead of his time.  Even Common Lisp and Scheme
haven't caught up with his vision.

On Wed, Feb 25, 2009 at 03:44:26AM +0900, karlvonl wrote:
> 
> If I ever design my own programming language, I'm going to use := for
> assignment and == for equality, and let a single = be a syntax error,
> just to avoid the whole confusion.

I'm leaning more toward = being used for both, and some other signifier
determining how the expression should be evaluated.  I think that would
be more "intuitive" for pretty much everyone involved.

On Tue, Feb 24, 2009 at 2:30 PM, Chad Perrin <perrin@apotheon.com> 
wrote:
> McCarthy was really ahead of his time.  Even Common Lisp and Scheme
> haven't caught up with his vision.

1. Nobody has *ever* caught up with Chuck Moore -- not even he
himself. :) He's still tweaking Forth, even though his disciples
standardized it long ago and are in a second round of standards
negotiation. For Chuck's view, see http://www.intellasys.net/.
Warning: here there be dragons, but not of the Dragon Book. :)

2. Lisp 1 and 1.5 were (elegant) hacks for the IBM 704 and its close
descendants. As such, they're very much as elegant as the early Scheme
interpreters. In one of his papers, McCarthy covers the transition
from his 1960 paper to the physical implementation in another paper.
I'm pretty sure it's on the web, but I don't recall where. It *should*
have been reprinted in "Beautiful Code". :)
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Tue, Feb 24, 2009 at 9:14 AM, Pascal J. Bourguignon <
pjb@informatimago.com> wrote:

> If you were using CL (if more people were using CL), and Ruby were not
> invented, more bosses would let us use CL as a dynamic language, and
> indeed we wouldn't be forced to use Ruby (or worse, perl or python).
>
> Of course, you share the culpability with perl, PHP, Python, Java and
> so on.


So your argument is Common Lisp would win by default if it were the only
game in town?  That's not exactly a confidence boosting argument.

But I'm mostly justified in thinking this, by the authors of most of
> these languages themselves.  Some of these authors are just poor chaps
> not knowing better, but some other including Java and Ruby knew very
> well Lisp, and instead of choosing to help develop and spread lisp,
> they voluntarily chosed to create different and inferior languages,
> picking only parts of lisp, and grafting over their abortive creation
> some monstruous syntax.


Guy Steele, famous for his "drag them halfway to Lisp" quote about Java,
also spent his time making a better Lisp... in his case Scheme.

But this further demonstrates their pragmatism: since it's clear that 
Lisps
will not see widespread popularity, the next best thing is to look to 
Lisp
for good ideas and use those in the creation of new languages.

That's exactly what Matz did with Ruby.

The fact that these monstruous syntaxes view good in the eyes of the
> unwashed masses
>

The quality of a grammar isn't not inversely proportional to its size, 
and
indeed despite the complexity of the Ruby grammar people find it not 
only
easy to read, but easy to transform.

You may wish to place emphasis on the latter as Lisp's homoiconicity 
makes
it easier to conceptualize things like macros, but I prefer to place
emphasis on the former as I spend much more time reading code than
transforming it.

Your "unwashed masses" find it easier to read the code of languages with
complex grammars than they do to read Lisp.  While you seem to attribute
this to some failing on their part, I'd attribute it to Lisp's 
homoiconicity
leading to an excess of tokens, making the language syntactically noisy.
Perhaps the "unwashed masses" simply prefer their languages use a more
complex grammar to eliminate some of that syntactic noise.

This is perhaps the good that will come from these evils.  A lot of
> programmers are now exposed on the goodness of dynamic languages, and
> they may notice (or if not by themselves, *I* will try to make them
> notice in threads like this), that their fad language of the day, is
> actually some incomplete subset of Lisp, and then why not use the full
> and authentic thing?  Common Lisp is this way!
>

On the contrary, I think programmers who decide to learn a Lisp and try 
out
CL as their first are far more likely to be turned off to Lisp in 
general,
as opposed to those who try saner Lisps like Scheme.  That was certainly 
the
case with myself, and I didn't really come to like Lisp until I tried 
out
Scheme.

I think the failure of Lisp to gain widespread popularity can largely be
attributed to Common Lisp itself.

Pascal J. Bourguignon wrote:
> If you were using CL (if more people were using CL), and Ruby were not
> invented, more bosses would let us use CL as a dynamic language,

No one can know that. For all you know, if Ruby were not invented, we
would all be using Bash.

It's also not an argument of superiority -- if C was not invented, more
bosses would let us use assembly. You could argue that higher-level
languages were an inevitability -- and I would similarly argue that a
more readable syntax (like Ruby) was inevitable.

Of course, you could always go try to find a job with Paul Graham, or
found a startup of Lisp people. There's no need to force everyone to use
the same language, when you can always work in whatever language you 
want.

> The fact that these monstruous syntaxes view good in the eyes of the
> unwashed masses, and that the lack of features (when it's not just the
> inclusion of misfeatures) is oblivious to the same masses IS NOT an
> excuse.
>   

What you're trying to argue is that everyone else in the world is wrong,
and you are right.

Extraordinary claims require extraordinary proof, and you haven't
provided any.

The fact that many people prefer this syntax, even when exposed to Lisp
syntax, should tell you something about the value of each. And that's
even before you consider that the purpose of syntax is communication.
Any syntax that is hard to understand has failed at its purpose.

> PS: I'm not subscribed to "Ruby-Talk", there's a gateway between this
>     mail-list and news:comp.lang.ruby.
>   

Then why do you read and participate in comp.lang.ruby? I'm sure you'd
find much more agreement, and maybe even some useful discussion, over at
comp.lang.lisp. (I assume that exists.)



Now, here's the part you really don't want to hear:

"It's easy to talk big. It's damn hard to _implement_ a complex system,
and make it stable and bug-free..."
  -- Linus Torvalds

http://article.gmane.org/gmane.linux.kernel/232093

I was involved in a discussion overlapping the kernel mailing list, and
this is perhaps the only email I've received directly from Linus
Torvalds, addressed to me.

It made me sit down, and shut up, and actually try to get something done
before I opened my big mouth again.

So I am curious -- what have you actually done in Common Lisp? How does
it address the challenges of communication and organization of a large
project? How fast can you whip up small, 100-line scripts to process
text, or to provide a simple service over HTTP and REST? How many cores
(or machines) do your programs scale to, and how much time do you spend
dealing with concurrency issues?

It's easy to talk big.

But you haven't even done that -- you've listed no advantage of Lisp,
other than claiming other languages have "monstrous syntax" -- how so?

One more link for you:

http://xkcd.com/224/

Pascal J. Bourguignon wrote:

> 
> If you were using CL

CL = COBOL Lisp

> well Lisp, and instead of choosing to help develop and spread lisp,
> they voluntarily chosed to create different and inferior languages,
> picking only parts of lisp, and grafting over their abortive creation
> some monstruous syntax.

In his city R'lyeh, dead Cthulhu lies dreaming.
"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!"

> 
> The fact that these monstruous syntaxes view good in the eyes of the
> unwashed masses, and that the lack of features (when it's not just the
> inclusion of misfeatures) is oblivious to the same masses IS NOT an
> excuse.
> 
> The only result is that Lisp is relegated as just an elegant weapon
> from a more civilized time, still mastered only by a few remaining
> Jedi.

The poor frightened wretch won't admit that CL (COBOL Lisp) is
a flint knife and that Ruby is a samurai sword.

He fears and trembles at Ruby's overtowering superiority.

I've asked him to disgorge some feculent COBOL Lisp code here
so that we, while holding our noses, can demonstrate how Ruby
can perform the same task more elegantly and concisely,
and less malodorously.

He hasn't done so.  He will never do so.

And he is so idiotic that he can't comprehend that COBOL Lisp
isn't the only Lisp---is, in fact, the worst of the lot.
He can't learn Clojure because to his fossilized brain
COBOL, COBOL-LISP, APL, and FORTRAN are new and radical languages.


> 
> But there is still hope!
> 
> This is perhaps the good that will come from these evils.  A lot of
> programmers are now exposed on the goodness of dynamic languages, and
> they may notice (or if not by themselves, *I* will try to make them
> notice in threads like this), that their fad language of the day, is
> actually some incomplete subset of Lisp, and then why not use the full
> and authentic thing?  Common Lisp is this way!

The Way, The Truth, and The Light.  He's a faithful disciple.

"Common Lisp" is cult jargon to conceal the True Name of their god:
Commode Lord.

Gregory Brown wrote:

> I don't think your flame-bait has helped

Calling it "flame-bait" is in itself flame-bait, proving that
you are devoid of integrity and possesed of overweening
conceit and arrogance.

On 24 Feb 2009, at 13:44, Tom Cloyd wrote:
> A most fascinating thread, coming from a very distant universe, as I  
> do.
>
> As for this use of "^", it is about as needless as yet another poem  
> about a flower. Don't we already have one, somewhere? I fully  
> realize that calculation (computer) languages are not poems, but  
> they ARE containers for thought, and in that they are brothers/ 
> sisters to poems.


There seems to be a fairly clean divide between the folks who like
language for being language, and those who like language for the
specific things it can do. I'll admit that I'm one of the former and
some of my favourite programs have minimal value in the latter sense,
but the form of them makes my heart soar.

> I'm with Eleanor in loving the exploration of different ways of  
> thinking/working with stuff (and in having an appreciation for the  
> elgance of RPN). A large part of the sheer burst of joy that grabbed  
> me and threw me into the Ruby world, on the occasion of my fifth  
> look at the language, was the delight I experienced upon finally  
> understanding that this language was "working" the notion that  
> everything could be an object, and have access to methods belonging  
> to the class of which it was a member. The sheer elegance of this  
> was new to me and is still a very major delight.

After years of battling with VB, C++ and Java the discovery of Ruby
was one of those doh! moments. I haven't looked back :)
Ruby and beauty are not always synonymous - it very much depends on
the writer - but it's a language that I find it hard to be ugly in and
that I think is a wonderful property.

But then again I've seen beautiful code in C and Assembler, even in
Pascal (see my favourite book, Programming Languages: An Interpreter-
based Approach for some wonderful examples) and perhaps one day I'll
see beautiful code in Nexus. That alone will be justification enough
for the love and effort its developers are pouring into it.

As for Common Lisp, it reminds me of Esperanto: those who are
attracted to it seem often to be those least suited to using it
gracefully and perhaps that says more about them than the language
itself.

> So, I have to wonder, when meeting up with a new language, if maybe  
> I'm about to hear my first Stravinsky ballet, or perhaps run into  
> something like Spencer Brown's "Laws of form" (1972). Beauty is  
> found in strange places. If we're all lucky, the Nexus project will  
> come up with some we've not seen yet. That would be most excellent,  
> howsoever difficult it may be to achieve.

We abandon the quest for beauty at our peril as it is the keenest
guide to correctness that we possess. Unfortunately an age of
aesthetic relativism has given it a bum wrap by attributing its
quality to things which patently aren't beautiful and are far from
correct.

And once more RT has gone completely OT :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On 24 Feb 2009, at 16:14, Pascal J. Bourguignon wrote:
>
<snip long rant>

Some of us know Lisp, we just don't like it. That's an aesthetic
choice, and if that bugs you I suggest you consider the relative
numbers of people worldwide employed programming in Lisp and Ruby -
it's pretty much zilch on both counts. Why? Because many many more
people choose to program in truly monstrous languages like Java lol


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
http://www.linkedin.com/in/eleanormchugh

David Masover wrote:
> 
> One more link for you:
> 
> http://xkcd.com/224/

Too funny!

Which brings me to my point in this rather interesting exchange.

Having wandered the halls of Basic, Fortran, COBOL, C, C++, Pascal,
Forth, Java, etc, etc I have noted that each language introduced me
to new concepts and modes of thought.

I have enjoyed that tremendously but when I want to get something
done (these days) I reach for Ruby.

It suites the way I think, the way I write code and I rather enjoy
it's almost playful antagonism to burdensome formalisms.

I like my tools light, sharp and powerful. Today, that means Ruby.

Tomorrow, it may mean something else but I haven't seen it yet...

(And BTW, Java should have been smothered in it's crib)

Regards

karlvonl wrote:
> If I ever design my own programming language, I'm going to use := for
> assignment and == for equality, and let a single = be a syntax error,
> just to avoid the whole confusion.

I used <- in a language I designed once.

"M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:

>> I think Joy, at least, is *influential* - language designers seem to
>> pay attention to it, even if users don't.
>
> Joy and Factor are essentially dialects of Forth that attempt to add
> some elegance and a functional language perspective. IMHO neither one
> of them is as elegant and practical as the RPL language HP put into
> the HP-28, 48 and 49 calculators. If you're going to make a reverse
> Polish language, RPL is the way to do it.

Ah, what memories :)

I still have my HP-48SX and 2 volume programming manual, what a great
machine. As an undergrad in a numerical analysis class, the prof said
we could use any language we wanted for a particular assignment
(multiple linear regression?), so I asked if I could use the HP-48SX,
and he said sure. It was a blast to crank out on that calculator, and
I'm pretty sure it was a fraction of the size of all the submissions.

On Tue, Feb 24, 2009 at 6:49 PM, Clifford Heath <no@spam.please.net> 
wrote:
> karlvonl wrote:
>>
>> If I ever design my own programming language, I'm going to use := for
>> assignment and == for equality, and let a single = be a syntax error,
>> just to avoid the whole confusion.
>
> I used <- in a language I designed once.

So does R and IIRC all the other dialects of S. Also IIRC R allows

a = b
a <- b
b -> a

which have equivalent meaning -- "a becomes (a reference to the
object) b". But "formal" R code uses "<-", "->" is deprecated and "="
appears in a lot of actual code. And "==" is the equality test
operator.

At one point R also allowed

a _ b

but I think that disappeared sometime since I first learned R. I
remember that one couldn't have names like

descent_rate

but had to use

descent.rate

because dot was a letter and underscore wasn't. But underscore is now a 
letter.

--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Tue, Feb 24, 2009 at 8:40 PM, Brian Adkins <lojicdotcom@gmail.com> 
wrote:
> Ah, what memories :)
>
> I still have my HP-48SX and 2 volume programming manual, what a great
> machine. As an undergrad in a numerical analysis class, the prof said
> we could use any language we wanted for a particular assignment
> (multiple linear regression?), so I asked if I could use the HP-48SX,
> and he said sure. It was a blast to crank out on that calculator, and
> I'm pretty sure it was a fraction of the size of all the submissions.

I had a 28S which I just loved. It died and got replaced by an HP100LX
and Derive for DOS. When *that* died I stopped buying pocket sized
machines. Now I have the latest model HP-49 and a bunch of TI
scientific calculators. But the HP is still the one I use.
--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

M. Edward (Ed) Borasky wrote:
> 
> The parentheses are in Lisp because functions (and special forms) have
> variable arity. If they had fixed arity the parentheses would not be
> required. But since S-expressions were defined using parentheses and
> Lisp wanted programs to look like S-expressions, variable arity was
> thrown in as a bonus. :)

The parentheses are there for power: code is data, data is code.  When 
evaluated as a language only, putting aside external issues such as 
mindshare, it is an objective statement to say that lisp is more 
powerful than any language which does not have the code-data 
equivalence.  And the only languages which have it are lisp-like (with 
the possible exception of Dylan).

Without end we could discuss popularity, "naturalness," "well I like 
...", blah blah blah.  But it remains an empirical fact some things can 
be done in lisp which cannot be done in ruby, unless ruby greenspuns its 
own code processor.  In lisp you can manipulate code _in code_.  The 
curious can ponder the implications of that, and/or learn some lisp to 
get a sense of it.  The incurious will rage against it and call me a 
troll.

If I understand Pascal's point, if he has one, it is that the vast 
majority of programmers do not realize that the non-lisp language they 
use is preventing them from thinking certain thoughts.  If after reading 
the previous sentence you shouted "bullshit!", then you might not be 
fully aware of this special code-data equivalence and why it makes lisp 
and lisp-like languages different.  I still remember sudden realization 
I had when saw what the comma does inside a lisp macro.  It has no 
counterpart in other languages.

I am not soliciting opinions on what is more practical, what you prefer, 
what is better, or what your favorite color is.  I am just giving an 
overview of the core language itself, with all those issues aside.

"M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:
> At one point R also allowed
>
> a _ b
>
> but I think that disappeared sometime since I first learned R.

In the old times, the code 95 often displayed as ←
and the code 94 displayed as ↑

It's only on newer terminals that you would see: a _ b
it was originally:                               a ← b

On Wed, Feb 25, 2009 at 8:30 AM, Chad Perrin <perrin@apotheon.com> 
wrote:

> are generally more difficult to *write*.  I know -- I've tried designing
> both Polish notation parsers and RPN parsers.  In fact, Polish notation
> parsers are more difficult to write for essentially the same reason that
> RPN parsers are slightly more efficient from the machine's point of view.
>

That's seems funny because bison uses RPN as an example. The syntax 
isn't
complex and once you have tokens you just need to shift the values onto 
a
stack and when an operator comes along you just apply it to the last two
values then push the result. Or you can create a tree where each value
becomes a node and the following operation the parent.

Mike Gold wrote:
> The parentheses are there for power: code is data, data is code.  When 
> evaluated as a language only, putting aside external issues such as 
> mindshare, it is an objective statement to say that lisp is more 
> powerful than any language which does not have the code-data 
> equivalence.

How is it more powerful than any other language which allows reflection?
Including Ruby, with ParseTree?

> Without end we could discuss popularity, "naturalness," "well I like 
> ...", blah blah blah.  But it remains an empirical fact some things can 
> be done in lisp which cannot be done in ruby, unless ruby greenspuns its 
> own code processor.  In lisp you can manipulate code _in code_.

Right. Like ParseTree.

I have found Ruby's reflection to be more immediately useful, but I
didn't use Lisp long enough to really be sure. I'm talking about the
more specialized stuff, like define_method and instance_eval.

> If I understand Pascal's point, if he has one, it is that the vast 
> majority of programmers do not realize that the non-lisp language they 
> use is preventing them from thinking certain thoughts.  If after reading 
> the previous sentence you shouted "bullshit!", then you might not be 
> fully aware of this special code-data equivalence and why it makes lisp 
> and lisp-like languages different.
>   

Actually, I shouted "bullshit!" because a language cannot _prevent_
thoughts.

For example: Ruby has blocks, where JavaScript does not. But JavaScript
does have anonymous functions.

So while Javascript doesn't support this:

foo.each do |obj|
  # do something with 'obj'...
end

It does support this (using jQuery):

$.each(foo, function() {
  // do something with 'this'...
});

// or, on a jQuery wrapped object:
foo.each(function() {
  // do something with 'this'...
});

The question then becomes whether a language actually makes certain
things impossible, or impractical, or just annoying. And Ruby does have
ParseTree.

> I am not soliciting opinions on what is more practical, what you prefer, 
> what is better, or what your favorite color is.  I am just giving an 
> overview of the core language itself, with all those issues aside.
>   

However, Pascal's point was that Lisp was unarguably the _best_
language, and implied that we were all "unwashed masses" for using Ruby
(and that we probably didn't know about Lisp). I think if we're really
going to have a discussion about "best", practicality has to play a part
of that.

In fact, even if we're only talking about the most powerful language,
power is also subjective. Ruby, for example, allows me to define a DSL
as a subset of Ruby, and have the DSL be very readable -- the
parentheses alone would make that harder in Lisp. All the flexibility
that I like about Ruby's practice of duck typing would bother someone
who wanted strict compiler checks and mathematical provability -- that
is, the power to ignore type would bother someone who wanted the power
to enforce it.

"Power" is subjective.

> And Ruby does have ParseTree.

BTW does ParseTree work with ruby 1.9? The last time I tried it
didn't.

Anyway, ruby isn't really made for that kind of thing. If you look at
the example at their homepage, the :scope and :block node seem to be
superfluous when dealing with code as data, and something like
"[:call, [:lvar, :arg1], :==, [:array, [:lit, 0]]]" also seems more
complicate than it could be. I think it's a good start but it doesn't
really match lisp capabilities in this respect where there is no
structural difference between the code and the data that represents
that code. That syntax most people in this thread were mocking has its
advantages and if you're denying that, the difference to "those cl
advocates" is only a marginal one.

Maybe you should rather ask if in ruby it is really necessary to
manipulate code as data the way it is necessary in lisp. With a few
exceptions, I have seldom felt a need for it whereas in lisp the use
of macros is something you do all the time.

Tom <micathom@gmail.com> writes:

> really match lisp capabilities in this respect where there is no
> structural difference between the code and the data that represents
> that code. That syntax most people in this thread were mocking has its
> advantages and if you're denying that, the difference to "those cl
> advocates" is only a marginal one.
>
> Maybe you should rather ask if in ruby it is really necessary to
> manipulate code as data the way it is necessary in lisp. With a few
> exceptions, I have seldom felt a need for it whereas in lisp the use
> of macros is something you do all the time.

Auto-meta-programming is only part of the picture.

Of course, when programming in Lisp, we use auto-meta-programming
obliviously all the time, but there are also a lot of lisp programs
written to implement DSL or to generate inferior languages.  For these
heterogenous meta- programming applications, Ruby can be used too.

Here is for example how I generate C++ code from Ruby:

      (class MapType
         (def makeToStringExpression(fieldAccess , mandatory , inVector 
= false , encoding = nil)
            (if mandatory
               (e = fieldAccess)
               (ib = [["." , e , :begin]])
               (ie = [["." , e , :end]])
             else
               (e = [[ "." , fieldAccess , :getValuePtr]])
               (ib = [["->" , e , :begin]])
               (ie = [["->" , e , :end]])
             end)
            (k = (@keyType     . makeToStringExpression(["->" , :i , 
:first]  , true , encoding)))
            (v = (@elementType . makeToStringExpression(["->" , :i , 
:second] , true , encoding)))
            (s = [:block ,
                  [:inline , "typedef " + (self . cxxPath) + " 
map_type;"] ,
                  (Cxx::Variable . new(:i , (Cxx::Type . new((self . 
cxxPath)+"::"+"const_iterator")) , ib)) ,
                  (Cxx::Variable . new(:e , (Cxx::Type . new((self . 
cxxPath)+"::"+"const_iterator")) , ie)) ,
                  [ "<<" , :s , " (map"] ,
                    [:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
                      [:block , ["<<", :s , " ("] , k , ["<<", :s , " . 
"] , v , ["<<", :s , ")"]]] ,
                   [ "<<" , :s , ")"]])
          end)
       end)


and how I would do it from Lisp:

(defmethod make-to-string-expression ((self map-type) field-access 
mandatory &optional in-vector encoding)
  (let ((f (if mandatory field-access `(\. ,field-access 
get-value-ptr))))
    `(block
      (typedef ,(cxx-path self) map-type)
      (variable (scope ,(cxx-path self) const-iterator) i (,(if 
mandatory '\. '->) ,f begin))
      (variable (scope ,(cxx-path self) const-iterator) e (,(if 
mandatory '\. '->) ,f end))
      (<< s "(map ")
      (for (nil (!= i e) (post++ i))
           (block
            (<< s " (")
            ,(make-to-string-expression (key-type self) `(-> i first)  t 
encoding)
            (<< s " . ")
            ,(make-to-string-expression (key-type self) `(-> i second) t 
encoding)
            (<< s ")")))
      (<< s ")"))))


(The generator written in Ruby cuts off the C++ syntax at the level of
 types and variable expressions, hence the inline and instanciations.
 In Lisp, since I could use auto-meta-programming I could easily and
 in less time implement the syntax for all the parts of C++, so
 there's no need to cross the language boundaries.)

David Masover wrote:
> Mike Gold wrote:
>> The parentheses are there for power: code is data, data is code.  When 
>> evaluated as a language only, putting aside external issues such as 
>> mindshare, it is an objective statement to say that lisp is more 
>> powerful than any language which does not have the code-data 
>> equivalence.
> 
> How is it more powerful than any other language which allows reflection?
> Including Ruby, with ParseTree?

Because in lisp, the metalanguage is the same as the language.  Tweaking 
ParseTree data is different than writing ruby code.  In lisp, the two 
activities are the same.

>> Without end we could discuss popularity, "naturalness," "well I like 
>> ...", blah blah blah.  But it remains an empirical fact some things can 
>> be done in lisp which cannot be done in ruby, unless ruby greenspuns its 
>> own code processor.  In lisp you can manipulate code _in code_.
> 
> Right. Like ParseTree.

You are supporting my point here.  ParseTree only runs on 1.8 CRuby, 
being tied to the C implementation's AST.  If ruby as a language 
supported a retrievable AST structure, then it could be put alongside 
dylan as one of the non-lisp languages which supports code as data.  But 
Matz has explicitly decided against this.

> I have found Ruby's reflection to be more immediately useful, but I
> didn't use Lisp long enough to really be sure. I'm talking about the
> more specialized stuff, like define_method and instance_eval.

Reflection is different from code-data equivalence.

> Actually, I shouted "bullshit!" because a language cannot _prevent_
> thoughts.

Most people are surprised when they learn lisp macros.  I know I was, 
and I know many students who were.  Why did it surprise us?  Because we 
hadn't thought of that before.  It is not that a language prevents the 
thoughts willfully like a evil demon, it's that the thoughts never arise 
in the first place.

> 
> The question then becomes whether a language actually makes certain
> things impossible, or impractical, or just annoying. And Ruby does have
> ParseTree.

Not in 1.9 or JRuby.  Nor is it planned.  Let me know if it happens.

> "Power" is subjective.

No, not in the way I used the term.  Because of code-data equivalence, 
lisp can do things which ruby cannot.  In this formal, objective sense, 
lisp is more powerful.  Even if ruby greenspuns its own tools like 
ParseTree, the language will still be different than the metalanguage. 
Don't take it personally.  This fact is well understood.  There is no 
sense wiggling around it just to somehow respond with a 
counter-argument.

Matz has called lisp "extreme abstraction", which is one way to put it. 
Lisp allows for more abstractions than ruby.  It was his choice to 
relinquish some of those abstractions, some of that power, in the design 
of ruby.  After all, despite all the catch phrases, ruby is not lisp, by 
design.

pjb@informatimago.com (Pascal J. Bourguignon) writes:

>                (e = [[ "." , fieldAccess , :getValuePtr]]) 
>                     [:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
>                       [:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] , 
>                    [ "<<" , :s , ")"]])
>           end)
>        end)

Pascal, I'm curious about your use of parentheses above. Do you use
them because it makes some things easier in your editor, or to compare
more directly with the Lisp example I elided, or simply to try and
make your Ruby code look as much like Lisp as posisble, or ... ?

On Wed, Feb 25, 2009 at 12:44 PM, Brian Adkins <lojicdotcom@gmail.com> 
wrote:
>>                (ie = [["." , e , :end]])
>>                   (Cxx::Variable . new(:e , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) ,
> make your Ruby code look as much like Lisp as posisble, or ... ?
>
> --
> Brian Adkins
> http://lojic.com/
>
>

I think he was making a point to compare Ruby code with LISP code and
showing how similar it is at the core. At least, that's what I saw.

Jason

On Tue, Feb 24, 2009 at 11:04 PM, Mike Gold 
<mike.gold.4433@gmail.com>wrote:

>
> The parentheses are there for power: code is data, data is code.  When
> evaluated as a language only, putting aside external issues such as
> mindshare, it is an objective statement to say that lisp is more
> powerful than any language which does not have the code-data
> equivalence.


Homoiconicity doesn't afford power so much as simplicity.  Using parse
transformations in Ruby requires learning what the Ruby parser's "sexps"
look like, whereas in Lisp you write your code directly in those sexps 
so
there is no disconnect.

Once you have the Ruby parser's sexps, the same class of transformations 
are
still available, as they are in any language which allows you to
programatically retrieve parser output and invoke the compiler from 
within
the language itself.

However, for day-to-day programming tasks I find code in sexp form 
harder to
read (and write) than code in a more complex grammar which is able to
express the same idea with fewer tokens and less syntactic noise.

Lisp is certainly better optimized for macros, but in my opinion Ruby is
better optimized for day-to-day use and readability.

Chad Perrin wrote:
> I'm leaning more toward = being used for both, and some other signifier
> determining how the expression should be evaluated.

What should that other signifier be? I guess you could say that 
assignment has
no value (instead of returning the assigned value as it usually does) 
and
then interpret = as checking for equality when it's used in a place 
where a
(boolean) value is expected and as assignment when it's not. But I 
imagine
that could become confusing as well. Also it'd make it impossible to do
things like "while item = get_item" (which may or may not be a good 
thing
depending on your point of view, of course).

Mike Gold wrote:
>> How is it more powerful than any other language which allows reflection?
>> Including Ruby, with ParseTree?
>>     
>
> Because in lisp, the metalanguage is the same as the language.  Tweaking 
> ParseTree data is different than writing ruby code.  In lisp, the two 
> activities are the same.
>   

I consider that to be a strength of Ruby.

It's possible I simply haven't done enough Lisp to miss some obvious
cases where macros would be helping. However, all the other
metaprogramming (instance_variable_set, define_method, etc) all work
pretty naturally as part of the language. The ParseTree stuff, while it
makes ParseTree itself slightly harder to learn (as you have to learn
how it represents Ruby code), allows the language to be easier and
cleaner when you don't need it.

Even when you do, I'd argue that ParseTree tends to match the structure
that you have in your head for that code, anyway.

> Reflection is different from code-data equivalence.
>   

Code-data equivalence is a kind of reflection.

>> "Power" is subjective.
>>     
>
> No, not in the way I used the term.  Because of code-data equivalence, 
> lisp can do things which ruby cannot.

I believe I've shown that either of the following is true:

Ruby can do everything Lisp can (ParseTree, etc)...
 - OR -
there are things Ruby can do that Lisp cannot.

If we accept that ParseTree counts, Ruby can do everything Lisp can,
with the additional point that not all dialects of Lisp have a concept
of objects.

If we decide that ParseTree doesn't count, then "power" is at least
somewhat based on a superficial, syntactical difference when writing
functionally-equivalent code. In which case, I can find plenty of things
I can do with Ruby syntax that I can't do with Lisp.

>   In this formal, objective sense, 
> lisp is more powerful.  Even if ruby greenspuns its own tools like 
> ParseTree, the language will still be different than the metalanguage.

Again, a _syntactical_ difference.

For this kind of reflection, Lisp wins. For everything else, Ruby syntax
is much more readable, at least to me.

>  Don't take it personally.  This fact is well understood.  There is no 
> sense wiggling around it just to somehow respond with a 
> counter-argument.
>   

Then try responding to that counter-argument, rather than "wiggling
around it" by simply repeating your own, and tacking on an argument from
authority.

Brian Adkins <lojicdotcom@gmail.com> writes:

>>                (ie = [["." , e , :end]])
>>                   (Cxx::Variable . new(:e , (Cxx::Type . new((self . cxxPath)+"::"+"const_iterator")) , ie)) , 
>>                   [ "<<" , :s , " (map"] ,
>>                     [:for , [ nil , ["!=" , :i , :e],["post++",:i]] ,
>>                       [:block , ["<<", :s , " ("] , k , ["<<", :s , " . "] , v , ["<<", :s , ")"]]] , 
>>                    [ "<<" , :s , ")"]])
>>           end)
>>        end)
>
> Pascal, I'm curious about your use of parentheses above. Do you use
> them because it makes some things easier in your editor, 

Yes, definitely. I use emacs with paredit-mode.


> or to compare
> more directly with the Lisp example I elided, 

Not specifically, but it's a nice side effect.


> or simply to try and
> make your Ruby code look as much like Lisp as posisble, or ... ?

Yes, definitely.  It makes me feel if not at home, at least, at a
strange aunt's, vs. in a totally strange home in a totally strange
land.

On 25 Feb 2009, at 21:24, Pascal J. Bourguignon wrote:
> Brian Adkins <lojicdotcom@gmail.com> writes:
>> or simply to try and
>> make your Ruby code look as much like Lisp as posisble, or ... ?
>
> Yes, definitely.  It makes me feel if not at home, at least, at a
> strange aunt's, vs. in a totally strange home in a totally strange
> land.

And that is precisely the point that many Lispers overlook. Lisp is a
mathematical notation and so people of a mathematical inclination feel
at home, however languages with "complex" syntax approximate natural
language notation and that's a place where the vast majority of
literate humans feel comfortable.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On 25.02.2009 01:41, Eleanor McHugh wrote:

> But then again I've seen beautiful code in C and Assembler, even in  
> Pascal (see my favourite book, Programming Languages: An Interpreter- 
> based Approach for some wonderful examples) and perhaps one day I'll  
> see beautiful code in Nexus. That alone will be justification enough  
> for the love and effort its developers are pouring into it.

Of course, this provokes the question "what is beauty?" (or "what is a
beautiful program?").  Pascal seems to like cascades of brackets so he
even writes Ruby code that way (or maybe it's just a habit) - other
people will like something else.  IIRC there is this saying about the
"eye of the beholder"... :)

What I probably wanted to say was: if you consider beauty as a criterion
for discussing languages it comes as no surprise that there is so little
agreement among people. :-)

And yes, we've gone completely OT. :-)

Kind regards

  robert


PS: For me beauty in a program is clear structure and few but well
chosen lines of code.

Tony Arcieri wrote:
> Homoiconicity doesn't afford power so much as simplicity.  Using parse
> transformations in Ruby requires learning what the Ruby parser's "sexps"
> look like, whereas in Lisp you write your code directly in those sexps so
> there is no disconnect.

Actually, you can have complex syntax *and* easy manipulation, by
delegating the building of the AST to the tool that already knows how
to do that anyway: the compiler.

The Converge Programming Language (<http://ConvergePL.Org/>) is a
great example of compile time metaprogramming in a language with
complex syntax (Pythonic in this case). It uses quasi-quoting to let
you build ASTs using the *concrete* syntax of the language and it uses
splice points to allow you to splice AST fragments back into the AST.

For things that are too complex for simple quoting and splicing,
Converge has an abstract standardized API to the compiler.

jwm

PS: Consider this my entry to "what Reia could steal from other
    languages" (-:

On Feb 23, 2009, at 11:02 PM, M. Edward (Ed) Borasky wrote:

> Actually it dates back to Algol. The people who designed it did it for
> a reason, but I can't remember what it was. I think it was to remind
> people that assignment was not equality, and the purists pronounce
>
> a := b

IIRC, that's similar to how the production is written in BNF, and made
sense in the context of creating compilers. But really, this
discussion is primarily about syntactic sugar. The whole point of a
high level programming language is to enable to let people think as
people do and translate those constructs into something that machines
can process efficiently. Many people, myself included, don't have
stack-based architectures and thus don't think well in RPN. So Forth
might not be my language of first choice.

But in the end, any T-complete language should allow you to (or should
I say "not prevent you from") do(ing) your job.

On Wed, Feb 25, 2009 at 09:30:26AM +0900, William James wrote:
> Gregory Brown wrote:
> 
> > I don't think your flame-bait has helped
> 
> Calling it "flame-bait" is in itself flame-bait, proving that
> you are devoid of integrity and possesed of overweening
> conceit and arrogance.

I don't think that's necessarily true of identifying flame-bait what it
is.  If I did, I'd have responded to you with something like "Calling it
'flame-bait' is in itself flame-bait, proving that you are devoid of
integrity and possessed of overweening conceit and arrogance."  I don't
really feel like saying all that nasty stuff about you though, William,
since I don't even know you.

On Wed, Feb 25, 2009 at 05:22:35AM +0900, Glen F. Pankow wrote:
> 
> Impressive, young Skyparenthesizer.  And here I thought Darth Java
> had won the Clone/Dup/Bloat War.

You forgot "Blub" amongst those pejoratives.

I find my randomly selected signature block stragely ironic.

Robert Klemme wrote:
> even writes Ruby code that way (or maybe it's just a habit) - other 
>
>     robert
>
>
> PS: For me beauty in a program is clear structure and few but well 
> chosen lines of code.
>
>
Not me. It was the beauty I saw in Ruby that drew me in. Beauty in art
is often about a kind of integrity - be it structural (music, sculpture,
architecture, programming), expressive (graphic art, poetry,
programming) textural (drawing, music).  A very incomplete analysis, of
course, but the point is that certain abstract qualities tickle the
brain, and our brains all come from the same genetic pool, so we share
common joys. Drawing closer to a clear vision of how that happens is
also beautiful, I think.

Beauty also has something to do with novelty, with surprise. I find both
surprise (sorry, Matz), and integrity in Ruby, and love both. Surprise
that a relative few powerful ideas can be so gainfully permuted, and
with such integrity. Stravinsky knew how to do that.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Wed, Feb 25, 2009 at 09:24:23AM +0900, William James wrote:
> 
> And he is so idiotic that he can't comprehend that COBOL Lisp
> isn't the only Lisp---is, in fact, the worst of the lot.
> He can't learn Clojure because to his fossilized brain
> COBOL, COBOL-LISP, APL, and FORTRAN are new and radical languages.

To be fair, I'm not terribly likely to learn Clojure any time soon, for 
a
number of reasons:

  1. While code written for the JDK/JVM is very portable across systems
  with the JDK/JVM installed, and code written for the JRE is very
  portable across systems with the JRE installed, code written for one 
is
  sometimes not so portable to the other, and doG forbid you try running
  code written for either on some third-party Java VM.  Since Clojure is
  a language designed to run atop a Java implementation, this could be
  relevant, and results in it not providing me a whole lot of benefit
  over Ruby, Perl, et cetera, for purposes of portability.  At least,
  that's my experience.

  2. The JVM and JRE distributions of the official Java implementation
  are not as protable as people like to think, themselves.  On some 
OSes,
  it's a real bear to get 'em installed and keep 'em updated.

  3. I like to get started in a language with simple command line tools,
  and don't much like having to start up a huge effin' VM like Java's to
  run simple command line tools.

Clojure sounds like a great language, though.

On Wed, Feb 25, 2009 at 03:57:48PM +0900, Dylan Evans wrote:
> stack and when an operator comes along you just apply it to the last two
> values then push the result. Or you can create a tree where each value
> becomes a node and the following operation the parent.

I'm not sure how that "seems funny", considering you just confirmed some
of what I said -- that RPN parsers are easier to write than Polish
notation parsers.

On Thu, Feb 26, 2009 at 05:18:24AM +0900, Sebastian Hungerecker wrote:
> depending on your point of view, of course).
I'm not sure about the specifics of how I'd want to set up the syntax,
but I don't see why the potential problems you bring up can't be worked
around.  Hell, just adding "let" to the assignment operation could clear
that up -- though I'm not convinced that's the best way to do it, 
because
I'm not sure how much I care about the addition of an additional
syntactic element there.

    while let item = get_item

On Wed, Feb 25, 2009 at 09:41:56AM +0900, Eleanor McHugh wrote:
> 
> There seems to be a fairly clean divide between the folks who like  
> language for being language, and those who like language for the  
> specific things it can do. I'll admit that I'm one of the former and  
> some of my favourite programs have minimal value in the latter sense,  
> but the form of them makes my heart soar.

Meh.  I'm pretty big on both.  I guess I'm neither an "ass man" nor a
"breast man", but more of a "total package man".  Pray pardon my
reference to a crude, but common, idiom by way of analogy.


> 
> After years of battling with VB, C++ and Java the discovery of Ruby  
> was one of those doh! moments. I haven't looked back :)
> Ruby and beauty are not always synonymous - it very much depends on  
> the writer - but it's a language that I find it hard to be ugly in and  
> that I think is a wonderful property.

I love Ruby.  Ironically, though, I seem to be going in the other
direction, somewhat -- getting (back) into C a bit more now.


> 
> But then again I've seen beautiful code in C and Assembler, even in  
> Pascal (see my favourite book, Programming Languages: An Interpreter- 
> based Approach for some wonderful examples) and perhaps one day I'll  
> see beautiful code in Nexus. That alone will be justification enough  
> for the love and effort its developers are pouring into it.

I have to guess you haven't seen beautiful C code using the GNU style
guide.  That stuff makes me shudder, as does the ritual abuse of GCC
specific compiler features.


> 
> As for Common Lisp, it reminds me of Esperanto: those who are  
> attracted to it seem often to be those least suited to using it  
> gracefully and perhaps that says more about them than the language  
> itself.

That's an analogy I hadn't considered before.  I guess, if CL is like
Esperanto, Ruby is like Japanese, Perl is like American English, Python
is like English as spoken in India, and Scheme is a bit like Toki Pona.

Of those, Toki Pona and Japanese are by far my favorites, in terms of 
the
basic structures of the various languages, but American English is the
language with which I'm still the most comfortable, the most fluent, and
the most expressive.

I'm not sure where C would fit into all that.


> 
> We abandon the quest for beauty at our peril as it is the keenest  
> guide to correctness that we possess. Unfortunately an age of  
> aesthetic relativism has given it a bum wrap by attributing its  
> quality to things which patently aren't beautiful and are far from  
> correct.

quoth Rainer Maria Rilke:

    "For beauty is nothing but the beginning of terror which we are
    barely able to endure, and it amazes us so, because it serenely
    disdains to destroy us."

On 25 Feb 2009, at 21:54, Robert Klemme wrote:
> a beautiful program?").  Pascal seems to like cascades of brackets  
> so he even writes Ruby code that way (or maybe it's just a habit) -  
> other people will like something else.  IIRC there is this saying  
> about the "eye of the beholder"... :)
>
> What I probably wanted to say was: if you consider beauty as a  
> criterion for discussing languages it comes as no surprise that  
> there is so little agreement among people. :-)

A lot of these arguments though have less to do with beauty per se
than they do with an evangelical zeal to save the poor benighted
heathens from their dark and superstitious coding ways. Personally I
like my superstitious ways and I'm happy to leave benighted heathens
to their own devices :)

> And yes, we've gone completely OT. :-)
>
> Kind regards
>
>   robert
>
>
> PS: For me beauty in a program is clear structure and few but well  
> chosen lines of code.

The same here, and I like to believe that insofar as there are any
objective criterion for beauty in code those are the most easily
expressed.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On Thu, Feb 26, 2009 at 8:53 AM, Chad Perrin <perrin@apotheon.com> 
wrote:

> that
> of what I said -- that RPN parsers are easier to write than Polish
> notation parsers.


My mistake, i thought you were saying the opposite of that. None the 
less it
sounds like a challenge. I guess the easiest way would be to read tokens
into an array and then parse them as RPN, but that's not very elegant
besides being a little harder. So i'll come back to using a tree, 
presumably
were using ruby since this is a ruby list so i would choose to implement 
my
branch nodes as Hashs of the form;

{ :op => '+', : lval => 7, :rval => 8 }

There are two ways to do it from here, but in both you read the tokens
creating a node if an operator is read or by populating it's values, the
difference is whether you choose to evaluate a node when it's complete 
or
the whole expression when it is finished.
Is that more complex? I'm not really sure, i think i'll write it up when 
i
finish work.

On Thu, Feb 26, 2009 at 4:01 AM, Chad Perrin <perrin@apotheon.com> 
wrote:
>
> I find my randomly selected signature block stragely ironic.
>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
> Common Reformulation of Greenspun's Tenth Rule:  Any sufficiently
> complicated non-Lisp program contains an ad hoc informally-specified
> bug-ridden slow implementation of half of Common Lisp.

But don't forget: Any sufficiently well-documented Lisp program
contains an ML program in the comments :)

martin

David Masover wrote:
> Mike Gold wrote:

> I believe I've shown that either of the following is true:
> 
> Ruby can do everything Lisp can (ParseTree, etc)...
>  - OR -
> there are things Ruby can do that Lisp cannot.

Uh, what?  Where are you getting this?

In ruby, can you take a given method and make some of its arguments
lazily evaluated, without changing a thing in the program except the
method definition?  Not even ParseTree will help you there.  I rest my
case.

Incidentally, 1.8 is odd because it is one big AST in C, with no
compilation.  Obviously 1.8 is very slow because of this.  ParseTree
is just giving back what is already there.  ParseTree is not available
in 1.9 or JRuby, nor is there a plan for it (and due to the nature of
compilation and optimization, I don't think it will happen).  MRI is a
prototype, implementation-wise.

>>   In this formal, objective sense, 
>> lisp is more powerful.  Even if ruby greenspuns its own tools like 
>> ParseTree, the language will still be different than the metalanguage.
> 
> Again, a _syntactical_ difference.

Nope, not just a syntactical difference.  In ruby, from a method you do
not have access to the caller's argument expressions, even with
ParseTree.  That is just one example.

>>  Don't take it personally.  This fact is well understood.  There is no 
>> sense wiggling around it just to somehow respond with a 
>> counter-argument.
> 
> Then try responding to that counter-argument, rather than "wiggling
> around it" by simply repeating your own, and tacking on an argument from
> authority.

Uh, what?

Well I've had enough experience to recognize incuriosity when I see
it.  You are missing a specific piece of knowledge.  If you were
curious, you could spend a few minutes reading about lisp macros in
order to gain some understanding of the issue at hand.  But you want
to sit back and watch me "prove" something to you.  No, I cannot make
you learn.  It never works; you must learn for yourself.

I have already given sufficient context, and now I have provided a
specific case: lazy evaluation.

If you don't want to learn, then that's fine.  But at least have the
good sense to recognize when you don't know something.

Tony Arcieri wrote:
> On Tue, Feb 24, 2009 at 11:04 PM, Mike Gold 
> <mike.gold.4433@gmail.com>wrote:
> 
>>
>> The parentheses are there for power: code is data, data is code.  When
>> evaluated as a language only, putting aside external issues such as
>> mindshare, it is an objective statement to say that lisp is more
>> powerful than any language which does not have the code-data
>> equivalence.

> Homoiconicity doesn't afford power so much as simplicity.  Using parse
> transformations in Ruby requires learning what the Ruby parser's "sexps"
> look like, whereas in Lisp you write your code directly in those sexps 
> so there is no disconnect.

No, it is more than convenience or simplicity.  See below.

> Once you have the Ruby parser's sexps, the same class of transformations 
> are still available, as they are in any language which allows you to
> programatically retrieve parser output and invoke the compiler from 
> within the language itself.

Aha! Now we are getting somewhere.  How are you going to get the
sexps?  You could convert your source to sexps, but then what?  How
will you relate the sexps to the running code?  If someone gives you a
Method instance, how will you find its sexp?  Or if your sexp says how
Foo.bar was defined, how do you know the definition has not changed
during run-time?  Or when you are inside a method, how can you get the
sexps of the argument expressions before they were passed?

> However, for day-to-day programming tasks I find code in sexp form
> harder to read (and write) than code in a more complex grammar which
> is able to express the same idea with fewer tokens and less
> syntactic noise.
> 
> Lisp is certainly better optimized for macros, but in my opinion
> Ruby is better optimized for day-to-day use and readability.

I said earlier that I was leaving subjective issues aside.  Lisp
programmers eventually do not see parens, so your subjective
assessment does not apply to them.

If you look at my posting history, you'll see that I do ruby.

On Thu, Feb 26, 2009 at 12:03 AM, Mike Gold 
<mike.gold.4433@gmail.com>wrote:

> Incidentally, 1.8 is odd because it is one big AST in C, with no
> compilation.  Obviously 1.8 is very slow because of this.  ParseTree
> is just giving back what is already there.  ParseTree is not available
> in 1.9 or JRuby, nor is there a plan for it (and due to the nature of
> compilation and optimization, I don't think it will happen).  MRI is a
> prototype, implementation-wise.
>

Yes, you are correct, and I really wish ruby-core would embrace 
ParseTree
and make it a standard feature of the language.  The fact they haven't 
has
precluded alternative implementations like JRuby from implementing it.
There is JParseTree for JRuby but it isn't actively maintained.  And of
course YARV practically precludes a ParseTree implementation so there's
little motivation for alternative implementations to even try to support
it.  The future of Ruby seems to be one without ParseTree.

So Lisp 1, Ruby 0 I guess.

> during run-time?  Or when you are inside a method, how can you get the
> sexps of the argument expressions before they were passed?
>

Conceeded, and given I accept the future of Ruby is one without 
ParseTree
this argument is moot.


> I said earlier that I was leaving subjective issues aside.  Lisp
> programmers eventually do not see parens, so your subjective
> assessment does not apply to them.
>

Yes, however I would count them among the extreme minority of 
programmers,
and would argue this is indicative of the fact that humans prefer 
complex
grammars where more structure can be expressed by fewer tokens.  Humans 
have
really awesome brains which can infer meaning from ambiguous grammatical
constructions no computer possibly can (at least until computers become
sentient), so minimalistic grammars are really an insult to human
intelligence.  But I guess there's a certain class of Lisp weenie who 
would
rather parse grammars like a computer :)

2009/2/26 Eleanor McHugh <eleanor@games-with-brains.com>:
> On 25 Feb 2009, at 21:54, Robert Klemme wrote:

>> What I probably wanted to say was: if you consider beauty as a criterion
>> for discussing languages it comes as no surprise that there is so little
>> agreement among people. :-)
>
> A lot of these arguments though have less to do with beauty per se than they
> do with an evangelical zeal to save the poor benighted heathens from their
> dark and superstitious coding ways. Personally I like my superstitious ways
> and I'm happy to leave benighted heathens to their own devices :)

I see we seem to have a quite similar approach to those language
"discussions".  That's why my engagement in them is usually brief.
There is no point in trying to "convert" someone of a different
"belief".

<wandering even="more off topic">I find the meta discussion about what
makes people have such strong feelings about particular positions and
why they want to convert others much more interesting.  I guess it has
something to do with basic instincts of humans who need to know where
they "belong to", i.e. what is their peer group and what are their
convictions.  But this discussion is rarely seen in our forums; maybe
it has something to do with IT guys (they mostly are - unfortunately)
seeing themselves as rational people who believe there are rational
reasons for most or all of their decision. Which reminds me of
zealotry in political leftist circles who also believe(d) that they
know how history works and what it needs to make everyone happy. I
find it surprising that after Third Reich and Gulag there are still
people who believe that they are able to force happiness on
everyone...</wandering>

>> PS: For me beauty in a program is clear structure and few but well chosen
>> lines of code.
>
> The same here, and I like to believe that insofar as there are any objective
> criterion for beauty in code those are the most easily expressed.

What a wonderful conclusion of a lengthy debate!

Warm regards

robert

Admittedly you would need to create an object or struct and manage 
memory in
other languages, but here's my take on polish notation in ruby.



class PN
    #Cause why not? That's why
    attr_reader :result
    def initialize
        @result = 0
    end

    def op(token)
        #create the node saving the previous node if any
        @node = { :parent => @node, :op => token, :lval => nil}
    end

    def val(token)
        if(@node[:lval].nil?) then
            #If this is the first token then it is the lval
            @node[:lval] = token
        else
            #Otherwise the operation can be resolved
            case(@node[:op])
            when '+' then
                res = @node[:lval] + token
            when '-' then
                res = @node[:lval] - token
            when '/' then
                res = @node[:lval] / token
            when '*' then
                res = @node[:lval] * token
            end
            if(@node[:parent].nil?) then
                #This is the last(aka first) operation so save the 
result
                @result = res
                @node = nil
            else
                #Send the result to the parent
                @node = @node[:parent]
                val(res)
            end
        end
    end
end


#  32 * (10 + 5) + 3
pn = PN.new
token_list = ['+', '*', 32, '+', 10, 5, 3]

token_list.each { |el|
    if(el.is_a?(String)) then
        pn.op(el)
    else
        pn.val(el)
    end
}

puts pn.result

On 26 Feb 2009, at 08:21, Robert Klemme wrote:
> "discussions".  That's why my engagement in them is usually brief.
> There is no point in trying to "convert" someone of a different
> "belief".

I just like a good argument ;) Plus I've always believed that the best
way to find out stuff is to make someone who already knows it so
defensively apoplectic that they give you their very best material in
defence. Lather, rinse, repeat :)

> know how history works and what it needs to make everyone happy. I
> find it surprising that after Third Reich and Gulag there are still
> people who believe that they are able to force happiness on
> everyone...</wandering>

Rationality has its uses, but carried to extremes it leaves the mind
trapped in a particular logical fallacies with no means of breaking
free. The universe after all is nothing more than a multi-dimensional
bumpy phase space full of highly misleading localised minima and
anyone who sits atop one is bound to be even more misguided than those
of us who get to the top of one slope and then decide to go for a
wander into the next valley. Who knows what exciting rabbit-holes we
may find there >8p


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Mike Gold wrote:
> Well I've had enough experience to recognize incuriosity when I see
> it.  You are missing a specific piece of knowledge.  If you were
> curious, you could spend a few minutes reading about lisp macros in
> order to gain some understanding of the issue at hand.

I have spent a few, before this discussion. I didn't see much to
interest me -- it seemed like a glorified preprocessor, so I wasn't
terribly interested.

But...

> I have already given sufficient context, and now I have provided a
> specific case: lazy evaluation.
>   

Yes, you have. I stand corrected -- thank you.

Mike Gold wrote:
> Method instance, how will you find its sexp?
That's solvable -- easy enough just to add an instance method to Method
objects. After all, we already have things like #arity, on Method and on
Proc objects.

> Or if your sexp says how
> Foo.bar was defined, how do you know the definition has not changed
> during run-time?

Of course you don't. How do you know this hasn't happened in Lisp?

That's like insisting that we can know that

class Foo
  def bar
    ...
  end
end

hasn't changed. Of course it can:

Foo.send :remove_method, :bar

> Or when you are inside a method, how can you get the
> sexps of the argument expressions before they were passed?
>   

Ah, that would be trickier, and depends very much on how much order of
execution is allowed to change.

I see no reason to believe it wouldn't be possible with a slight
departure from current Ruby syntax -- as an alternate way to accept
arguments. The question is whether that's worth the potential confusion
-- after all, we can already get explicit lazy evaluation easily enough
by passing a block instead of arguments.

For example, it's possible to imagine a construct like this:

if foo(a = b)
  # do something with a
end

If a method is allowed to lazily evaluate its arguments -- or not
evaluate them at all -- I can't count on 'a' being set, there, if 'foo'
decides to do something strange. I'm guessing this kind of thing
wouldn't come up much in practice, but I'm not sure.

Eleanor McHugh wrote:
> There seems to be a fairly clean divide between the folks who like 
> language for being language, and those who like language for the 
> specific things it can do.

I would say, these aren't completely unrelated -- the grammar and
structure of a language, the way in which it lends itself to
communication, or to poetry, is one of the things a language can do.

And yet, part of the beauty of a language can be revealed in what it can
actually do. For example, I consider this to be beautiful:

get '/' do
  'Hello, world!'
end

But while I'm sure someone can demonstrate far more elegant examples of
Sinatra code, and of code that Sinatra does better than other
frameworks, it might be difficult to show the full extent of its beauty
without the context that this is an http service, matching a request to
an intended response.

That was a bit of a 'duh' moment for me. I was still relatively new to
Rails and REST, but it was both aesthetically pleasing and immediately
obvious what it does -- it was as if a full web stack hit my brain in an
instant.

I would say, dissolving beauty into separate ideas of form and function,
and then appreciating one without the other, is a bit like falling in
love with a photograph, never having met the person behind it. I am not
saying photographs cannot be beautiful, but if that is all you see in a
person, you are missing a lot.

> We abandon the quest for beauty at our peril as it is the keenest 
> guide to correctness that we possess. Unfortunately an age of 
> aesthetic relativism has given it a bum wrap by attributing its 
> quality to things which patently aren't beautiful and are far from 
> correct.

The most blatant reminder of this that I've seen was in this 
presentation:

http://rubyhoedown2007.confreaks.com/session09.html

I won't spoil it, though -- anyone who hasn't seen this, just find an
hour and watch it for yourself.

On Thu, Feb 26, 2009 at 02:10:59PM +0900, Martin DeMello wrote:
> But don't forget: Any sufficiently well-documented Lisp program
> contains an ML program in the comments :)

Nice.  I hadn't heard that one.

On Thu, Feb 26, 2009 at 05:21:11PM +0900, Robert Klemme wrote:
> zealotry in political leftist circles who also believe(d) that they
> know how history works and what it needs to make everyone happy. I
> find it surprising that after Third Reich and Gulag there are still
> people who believe that they are able to force happiness on
> everyone...</wandering>

I think a more elegant schema would use:

    <wander where="even more off-topic"></wandering>

Tony Arcieri wrote:
> On Thu, Feb 26, 2009 at 12:03 AM, Mike Gold <mike.gold.4433@gmail.com>wrote:
>> Incidentally, 1.8 is odd because it is one big AST in C, with no
>> compilation.  Obviously 1.8 is very slow because of this.  ParseTree
>> is just giving back what is already there.  ParseTree is not available
>> in 1.9 or JRuby, nor is there a plan for it (and due to the nature of
>> compilation and optimization, I don't think it will happen).  MRI is a
>> prototype, implementation-wise.
> Yes, you are correct, and I really wish ruby-core would embrace ParseTree
> and make it a standard feature of the language.  The fact they haven't has
> precluded alternative implementations like JRuby from implementing it.

Actually, I believe it is the other way round: embracing ParseTree
would preclude alternative implementations like JRuby from being
implemented in the first place.

Well, I admit, I was exaggerating. However, until recently, JRuby
*had* a (somewhat) ParseTree-compatible AST. The reason why they
decided to drop ParseTree-compatibility was simply that it would be
impossible to evolve the compiler while keeping the AST compatible.

ParseTree is intimately tied to the actual layout of the AST inside
MRI and to the actual inner workings of MRI. That would mean that the
alternative implementations would be intimately tied to the inner
workings of MRI -- in other words, they wouldn't actually be
"alternative" implementations any more, just clones.

This is especially bad, since MRI is actually a pretty marginal edge
case: it only supports Ruby 1.8, most other implementations support
either Ruby 1.9 or Ruby 1.8 *and* 1.9 in the same parser. MRI is the
only pure interpreter, *every* other implementation (and there's about
a dozen of them) has a compiler -- some even have *only* a compiler
and no interpreter at all. And, last but not least, even MRI's creator
doesn't consider it a very good Ruby Implementation.

JRuby is actually a pretty extreme countercase: where MRI's parser and
AST are doing exactly one thing, JRuby's parser and AST are used to
implement an interpreter, a dynamic JIT and a static ahead-of-time
batch compiler within the JRuby project, plus an interactive resident
background parser for syntax checking, syntax highlighting, code
formatting, code generation, code completion, static analysis, type
inference, code transformation and refactoring in at least 3 different
IDEs, and even to implement a compiler and type inference engine for
*another* language implementation (Duby).

> There is JParseTree for JRuby but it isn't actively maintained.  And of
> course YARV practically precludes a ParseTree implementation so there's
> little motivation for alternative implementations to even try to support
> it.  The future of Ruby seems to be one without ParseTree.
> 
> So Lisp 1, Ruby 0 I guess.

I wouldn't say that. There are better ways than ParseTree. A
standardized generic, abstract, high-level parser API for example.

Countless man-hours and dollars, and even entire companies have been
lost in the battle for implementation-independent ASTs. There is a
reason why JVM bytecode and not ANDF rules the world. Let's learn from
those mistakes.

jwm

On 26.02.2009 11:17, Eleanor McHugh wrote:
>> "discussions".  That's why my engagement in them is usually brief.
>> There is no point in trying to "convert" someone of a different
>> "belief".
> 
> I just like a good argument ;)

Hm, ok then we do have a bit different approach.

> Plus I've always believed that the best  
> way to find out stuff is to make someone who already knows it so  
> defensively apoplectic that they give you their very best material in  
> defence.

I see.  But you do have to admit that it can be painful at times (not
necessarily for you but the peer). :-)

> Lather, rinse, repeat :)

LOL

>> know how history works and what it needs to make everyone happy. I
> wander into the next valley. Who knows what exciting rabbit-holes we  
> may find there >8p

That's another interesting way to look at it.  May way to look at
decision making is this: rational decision making can only do "I choose
X because of Y".  Then you have to say "I choose Y because of Z".
Basically the chain would not end unless at some point Y is something
which you simply do not question.  It's either a requirement coming from
the outside or it is a value that is part of your system of convictions.
  In that sense rational decision making is a myth because all decisions
are rooted in the irrational.  Hopefully I wasn't too cryptic...

Kind regards

  robert

On 26 Feb 2009, at 22:14, Robert Klemme wrote:
> That's another interesting way to look at it.  May way to look at
> decision making is this: rational decision making can only do "I  
> choose X because of Y".  Then you have to say "I choose Y because of  
> Z". Basically the chain would not end unless at some point Y is  
> something which you simply do not question.  It's either a  
> requirement coming from the outside or it is a value that is part of  
> your system of convictions.  In that sense rational decision making  
> is a myth because all decisions are rooted in the irrational.   
> Hopefully I wasn't too cryptic...

It seems we're both rationally irrational then as opposed to
irrationally rational lol


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

Jörg W Mittag wrote:
> Actually, I believe it is the other way round: embracing ParseTree
> would preclude alternative implementations like JRuby from being
> implemented in the first place.
 >
> Well, I admit, I was exaggerating. However, until recently, JRuby
> *had* a (somewhat) ParseTree-compatible AST. The reason why they
> decided to drop ParseTree-compatibility was simply that it would be
> impossible to evolve the compiler while keeping the AST compatible.

Not impossible...there's just been practically *zero* demand, limited
resources, and other things that needed more attention. I'm not opposed
to supporting PT in JRuby, but it's never been a very high priority. And
now that ruby_parser can be used for almost all the offline PT-based
tools, there's even less motivation.

> ParseTree is intimately tied to the actual layout of the AST inside
> MRI and to the actual inner workings of MRI. That would mean that the
> alternative implementations would be intimately tied to the inner
> workings of MRI -- in other words, they wouldn't actually be
> "alternative" implementations any more, just clones.

I've also had an issue with PT basically just *being* MRI's AST. We've
made numerous changes to the structure of the AST, some of them for very
good reasons. We've also unified a number of constructs that MRI still
keeps separate. In short, we've evolved, and while PT did a good job
exposing the general structure of MRI's AST, it also exposes MRI's
implementation warts. We don't feel a strong need to emulate those
warts. But it's doable :) The fact that it hasn't been done says more
about the demand for it than the challenge of making it happen.

> I wouldn't say that. There are better ways than ParseTree. A
> standardized generic, abstract, high-level parser API for example.

ruby_parser handles some of this, but it's another all-at-once parser;
you can't stop and start it or handle subsections of code easily.
Really, it's just a port of MRI's Yacc/Bison parser to Racc.

- Charlie

On Fri, Feb 27, 2009 at 1:52 AM, Chad Perrin <perrin@apotheon.com> 
wrote:
> On Thu, Feb 26, 2009 at 02:10:59PM +0900, Martin DeMello wrote:
>>
>> But don't forget: Any sufficiently well-documented Lisp program
>> contains an ML program in the comments :)
>
> Nice.  I hadn't heard that one.

I've sadly lost the attribution, been trying to find it again for
years because I really would like to give credit to the genius who
came up with it.

martin

Charles Oliver Nutter wrote:
> And now that ruby_parser can be used for almost all the offline 
> PT-based tools, there's even less motivation.

Merb uses ParseTree for something called ActionArgs feature which, as I
understand it, actually relies on the name of function parameters. For
example, if you have an action which takes an argument called 'foo', and
that URL is hit with a querystring like ?foo=bar, it will pass that
value ('bar', in that case) as that argument.

This actually seems to no longer need ParseTree -- that's used on MRI --
but it also seems to have very different code for each of the three VMs
supported.

It's worth mentioning that Merb is being merged into Rails. Merb 2 will
be Rails 3, and vice versa. So, while it's solved, it's not an entirely
obscure concern.

> while PT did a good job exposing the general structure of MRI's AST, 
> it also exposes MRI's implementation warts. We don't feel a strong 
> need to emulate those warts.

Ideally, the goal wouldn't be to emulate MRI's warts, but to expose
something generic enough to be common, but practical. I would hope it
would do a good job of exposing the original structure of the source
code, even if that is completely annihilated by optimizations in the
version actually executed.

In fact, I think the closest we have to "something like ParseTree" which
"helps support alternate implementations" might be Rubinius.
Unfortunately, I don't seem to see any of the other alternate
implementations moving in that direction.

>     <wander where="even more off-topic"></wandering>
                                          ^ Parse error,
                                            Wandering does not
compute.

David Masover wrote:
> Merb uses ParseTree for something called ActionArgs feature which, as I 
> understand it, actually relies on the name of function parameters. For 
> example, if you have an action which takes an argument called 'foo', and 
> that URL is hit with a querystring like ?foo=bar, it will pass that 
> value ('bar', in that case) as that argument.
> 
> This actually seems to no longer need ParseTree -- that's used on MRI -- 
> but it also seems to have very different code for each of the three VMs 
> supported.

Well, in JRuby this is taking advantage of us being the most reflectable
Ruby implementation. Basically it's a bit of Ruby code that accesses
JRuby internals directly to get at the method args. That approach works
reasonably well for small cases, but we'd probably want to expose our
AST to Ruby in a more direct way that could then be massaged into sexps.
JParseTree tried to do this, but without any JRuby runtime/API
help...I'm willing to provide that help, if someone wanted to give it
another go.

However there's another complication with exposing the AST: sometimes we
don't have one. For example, if a script is precompiled to JVM bytecode,
there's no AST to present. And we would like to get to a point where JIT
compiling a method at runtime makes its associated AST eligible for GC,
since a substantial portion of memory in a typical Ruby app is taken up
by the AST itself. What do we do in those cases?

> Ideally, the goal wouldn't be to emulate MRI's warts, but to expose 
> something generic enough to be common, but practical. I would hope it 
> would do a good job of exposing the original structure of the source 
> code, even if that is completely annihilated by optimizations in the 
> version actually executed.

Sure, I'm game for that. And with a little more revising, I think the
"unified parse tree" in later PT releases is pretty close. If we wanted
to do this right, we'd get the implementers together to agree what a
standard sexp-based representation of Ruby code should look like,
avoiding impl-specific warts and conveying exactly the information 
needed.

> In fact, I think the closest we have to "something like ParseTree" which 
> "helps support alternate implementations" might be Rubinius. 
> Unfortunately, I don't seem to see any of the other alternate 
> implementations moving in that direction.

Rubinius is actually eliminating the intermediate sexps now because
going from parse to sexp to AST to compilation is just too slow. But
they're still basically using MRI's C parser, so PT is probably still
supportable in some capacity.

- Charlie

On Fri, Feb 27, 2009 at 02:19:56PM +0900, Martin DeMello wrote:
> came up with it.
Please let me know if you figure it out.

On Fri, Feb 27, 2009 at 04:47:37PM +0900, Leo wrote:
> >     <wander where="even more off-topic"></wandering>
>                                           ^ Parse error,
>                                             Wandering does not
> compute.

Damn.  Typo.

Pascal J. Bourguignon wrote:

> 
> 
> > or simply to try and
> > make your Ruby code look as much like Lisp as posisble, or ... ?
> 
> Yes, definitely.  It makes me feel if not at home, at least, at a
> strange aunt's, vs. in a totally strange home in a totally strange
> land.

This tends to prove the hypothesis that Commune Lisp users are
incapable of becoming fluent in other languages.  They lack the
ability to change and to grow; their minds seem to be fossilized.
They believe that the evolution of programming languages ended
with FORTRAN.

On Wednesday 25 February 2009 05:53 pm, Chad Perrin wrote:
> I'm not sure how that "seems funny", considering you just confirmed 
some
> of what I said -- that RPN parsers are easier to write than Polish
> notation parsers.

Maybe somebody can clarify / remind me of the terminology (it's been a
long time since I really dealt with that stuff--pre-1970 iirc).

Anyway, I remember RPN (Reverse Polish Notation) which is like 3 3 +

I remember infix (notation?) (which is like 3 + 3 =)

Then I remember there was the "inverse" of RPN, which is like + 3 3
(iirc)--is that what you're calling Polish notation (it makes sense,
just wasn't sure) (I think maybe we just called it something like
prefix notation--we referred to prefix, infix, and postfix, with
postfix being RPN)

What I remember is that writing compiler type stuff in RPN  (or to
handle RPN) was much easier than for infix notation.  I don't remember
doing experimentation with prefix, but I assume we must have (it was
that kind of school).

Randy Kramer

Randy Kramer <rhkramer@gmail.com> writes:
> Anyway, I remember RPN (Reverse Polish Notation) which is like 3 3 +
>
> I remember infix (notation?) (which is like 3 + 3 =)
>
> Then I remember there was the "inverse" of RPN, which is like + 3 3 
> (iirc)--is that what you're calling Polish notation (it makes sense, 
> just wasn't sure)

Would the "inverse" of reverse polish notation be polish notation?

[3,3,:+].inverse -> undefined method `inverse' for [3, 3, :+]:Array

Seems that's nonsense...  On the other hand:

[3,3,:+].reverse -> [:+, 3, 3]

In the beginning (1920s / 1930s) there was one notation, with
parentheses. We now call that infix, but I don't think it had a name
because it was the only notation anybody used. Then Lukaciewicz
invented Lukaciewicz notation, which was a prefix notation -- operator
followed by operands. Nobody could spell or pronounce his name, so it
became known as Polish notation because he was Polish. It was still
prefix and not widely used until the early days of programming
language.

Then came reverse Polish or postfix notation. So now we have three 
notations:

Polish, aka prefix
Reverse Polish, aka postfix
normal, aka infix


--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

On Sun, Mar 01, 2009 at 12:14:01AM +0900, Pascal J. Bourguignon wrote:
> 
> Would the "inverse" of reverse polish notation be polish notation?
> 
> [3,3,:+].inverse -> undefined method `inverse' for [3, 3, :+]:Array
> 
> Seems that's nonsense...  On the other hand:
> 
> [3,3,:+].reverse -> [:+, 3, 3]

Actually, it's not so much that Polish notation is the reverse of 
Reverse
Polish Notation, but that RPN is the reverse of Polish notation.  Ahem.

If I recall my efforts correctly, though, the *implementation* of Polish
notation felt more like the "inverse" of RPN than either being the
"reverse" of the other.  In fact, implementing prefix notation felt a 
bit
like turning RPN inside out.

On Sat, Feb 28, 2009 at 03:54:01PM +0900, William James wrote:
> 
> This tends to prove the hypothesis that Commune Lisp users are
> incapable of becoming fluent in other languages.  They lack the
> ability to change and to grow; their minds seem to be fossilized.
> They believe that the evolution of programming languages ended
> with FORTRAN.

That's a patently false stereotype, judging by my observations.

Pascal J. Bourguignon wrote:

>             (if mandatory
>                (e = fieldAccess)
>                (ib = [["." , e , :begin]])
>                (ie = [["." , e , :end]])
>              else
>                (e = [[ "." , fieldAccess , :getValuePtr]]) 
>                (ib = [["->" , e , :begin]])
>                (ie = [["->" , e , :end]])
>              end)


e, ib, ie =
  if mandatory
    [ field_access, [["." , e , :begin]], [["." , e , :end]] ]
  else
    [ [[ "." , field_access , :get_value_ptr]],
      [["->" , e , :begin]],
      [["->" , e , :end]]
    ]
  end

On Wed, Feb 25, 2009 at 05:22:35AM +0900, Glen F. Pankow wrote:
>Impressive, young Skyparenthesizer.  And here I thought Darth Java
>had won the Clone/Dup/Bloat War.
>

No! Please stop. I can't take any more.... Please, before I die
laughing URGGHHHH

David Masover wrote:
> Charles Oliver Nutter wrote:
>> And now that ruby_parser can be used for almost all the offline 
>> PT-based tools, there's even less motivation.
> Merb uses ParseTree for something called ActionArgs feature which, as I 
> understand it, actually relies on the name of function parameters. For 
> example, if you have an action which takes an argument called 'foo', and 
> that URL is hit with a querystring like ?foo=bar, it will pass that 
> value ('bar', in that case) as that argument.

Actually, this could be much better solved by a well-structured
Signature object à la Python's PEP362 "Function Signature Object":
<http://Python.Org/dev/peps/pep-0362/>

jwm

Jörg W Mittag wrote:
> Signature object à la Python's PEP362 "Function Signature Object":
> <http://Python.Org/dev/peps/pep-0362/>

... which will appear[1] in Ruby 1.9.2. Nice work!

jwm

[1] https://GitHub.Com/RubySpec/MatzRuby/blob/trunk/proc.c#L694-710