Nexus Programming Language

Robert D. wrote:

On Mon, Feb 23, 2009 at 1:48 PM, Brian C. [email protected]
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.

On Mon, Feb 23, 2009 at 1:48 PM, Brian C. [email protected]
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.

Brian C. [email protected] 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
; 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 :slight_smile:
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.

On 23 Feb 2009, at 19:47, Chad P. 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 C. [email protected] 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 :slight_smile:

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
[email protected] 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. :slight_smile:

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.

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. :slight_smile:

  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 Feb 23, 2:21 pm, Eleanor McHugh [email protected]
wrote:

Imagine how sweet Lisp would be without all those damn parentheses

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

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.

On Mon, Feb 23, 2009 at 8:21 PM, Eleanor McHugh
[email protected] 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

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 M. [email protected]
wrote:

On Feb 23, 2:21 pm, Eleanor McHugh [email protected]
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 …:wink:
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 P. 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 P. 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 W.

Eric P. 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 24 Feb 2009, at 00:15, Gary W. 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

Gary W. 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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs