Lambda the Ultimate

But as far as looking like English, well, I don't know. Does speed.r look like English to you?

And, this is friendly to naive users?

"To download a copy of REBOL, you need to indicate that it is binary. Here's how:"

write/binary %rebol.zip
    read/binary http://www.rebol.com/downloads/core031.zip

But computation isn't computation, except in the very trivial case of "being computable", and even here you need to specify the computable problem set.

Rebol does not necessarily achieve the goal of being english like, nonetheless it is a specific goal. A goal that has generally been more closely achieved at the simple one or two line scripts, like

write %currentlambda.html read http://lambda-the-ultimate.org

I never thought i would live to the day i would see clipper in these lambda pages... :P

More generally, something like:

If a subexpression could "go with" either its left or right context, to be disambiguated by precedence and/or associativity, then the whitespace on the side it "goes with" must be <= the whitespace on the other side (where "no space" < "one or more spaces" < "newline"). So "1 + {NEWLINE} 2 * 3" would be fine, but "1 + 2 {NEWLINE} * 3" would be a compile error. Does anybody else think this is a good idea?

Of course, 1 + 2 * 3 has meant (1 + 2) * 3 for years if you're a Smalltalk programmer.

I remember reading about some language (L, I think--maybe it was here on LtU) that used the amount of whitespace to indicate binding strength. In other words,

1+2 * 3

was different from

1 + 2*3

and so on. I've also seen languages (does Lisp do this) that when parse the following differently:

-3

and

- 3

such that the first is the literal "negative three"; the second is a minus sign operator followed by the literal "three".

I like the latter use of whitespace more than the former--it's quite useful in a highly-parenthesized language like Lisp. Of course, that's my $.04

I'm a hot-under-the-collar stick-in-the mud about this topic. My $0.02:

I just cannot fathom how anybody could want to come up with an arbitrary system for mathematical notation when there already exists a perfectly well-defined and understood notation.

Even if the person writing the code knows how the whitespace works and uses it, what about when I go to read the code because I'm trying to track down an error? I have to then go look up what cockamamy syntax the system is using, when instead I could just have gone with stuff I've known and used since I was a kid!

Please, for the love of Something, don't anybody ever do this! I know that things like Smalltalk have already screwed the proverbial pooch in this regard, let us learn from that rather than continue down such a pernicious road.

[Edit: basically, I mean 'precedence' instead of 'notation', see below.]

You must have gone to quite a different school from me. I didn't use AND and OR in algebraic expressions, not even .

I guess that's why I prefer a system with as few rules as possible (Smalltalk is good; Scheme is great), because then I can just look and know, rather than have to go to a precedence table to find out if

Yes, that seems to be the idea. This feature is not for arthimetics but for all the other millions of infix operators. It might be noted that languages like APL and J which use a lot of inifix syntax also abandond precedens rules. and simply parses from the right. ie 2 * 3 + 4 is 2 * (3 + 4).

I wonder if any languages have ever tried parsing from the left to be more English-like, so 4 + 3 * 2 would be interpreted as 4 plus 3, times 2.

Then explicit parens could be used to force a lookahead by spawning and reducing new local evaluation contexts as in 2 * 3 + (7 div (4 + 9)).

Don't you think a 5 line signature for a 4 line post is a bit excessive? Especially considering your name is already attached to every post you write?

The signature feature has just been removed, so you shouldn't be bothered by this kind of thing in future. I'm leaving this subthread as-is, as a reminder of the bad old days, now behind us. ;)

Yes. Both Smalltalk and Rebol does that.

I agree that on the whole having to look up operator precedence sucks.

But I think that if you force Smalltalk-like evaluation upon the mathematical operators (OR and AND would be in that category as discrete math when used as such, even if bit shifting isn't) then you are throwing away a perfectly usable system. See, I pretty much wouldn't ever have to look things up if they are * and +. If somebody did have to look them up then they didn't graduate from high school?

So can we separate those things which have predefined 'universal' precedence, like math, from 'arbitrary' precedence, like pointer arithmetic vs. dereferencing? I dunno, but that to me is a much more worthy goal than this claim to make things more like English.

(And if the whole idea is to be more like English, then you have to fix what OR means - I think most folks use it in the XOR sense!)

More precisely, mathematical notation is frequently ad-hoc--subdisciplines (or even individual authors and papers) will have their own definitions; and the various symbols used may have different meaning in different contexts.

Mathematical notation is also very dependent on such things as position, font size (sub/superscripting), font effects (bold, italics, "blackboard"), etc.-- things which are notoriously difficult to specify in a text editor, without resorting to some markup language--Tex/LaTex, XML/MathML, etc.

The notion of a "universal" mathematical notation simply doesn't exist. Given that most uses of mathematical notation are intended to be read by humans, not by computers, and it's assumed that the reader/student has the appropriate context, this isn't a problem for printed mathematical works.

But it's a different story for describing algorithms and constraints to a computer.

One way to deal with this, I suppose, is to have languages/parsers which will accept MathML (and be able translate it meaningfully into a suitable computer-language grammar). More generally; languages should have a "kernel" grammar which is clean, unambiguous, and well-defined--and mathematical notation, should it be needed, can be viewed as a DSL.

Now, the case of operator precedence (for well-defined issues like multiplication and addition), accomodating the mathematical world isn't unreasonable--many languages do this already. But for the more generic mathematical universe---ugh.

For sure, mathematical notation is a very rich and complex thing. However, I don't believe that in any mathematical system that I've seen would one condsider 1+2 * 3 != 1 + 2 * 3 (which is the example from Merd, above). So, yeah, having the precedence in the programming language match the basics from mathematics is the very minimum I'd require. Speaking for myself.

Regarding going beyond ASCII, I think things like Fortress are cool in that they want to make sure ASCII is still allowed. If we are interested in languages that can become widely used, I think we (very unfortunately) have to realize that ASCII is the only thing we can count on - I agree that trying to use XML or something is just fraught with peril, wailing and gnashing of teeth.

Any code that requires you know the precedence of the binary operators is not properly written - parenthesis are cheap and make this stuff obvious. I don't think code like (1 + 2 * 3) should see the light of day.

... is one of tradeoffs between suitability for humans, and suitability for computers. Suitability for humans can be further broken down into ease of reading, and ease of writing.

Mathematical notation, when professionally typeset, is easy to read (compared to the alternatives, and assuming the reader is suitably trained in math). It's a royal pain to write and edit--whether you're using Latex, MathML, Microsoft Word, FrameMaker, troff, or chalk on a blackboard.

Handwritten mathemathical notation is easy to write (though some effects like bold and italics can be tricky); but it can be difficult to read--especially if you studied under some of the professors I had. :)

Fully-parenthesized expressions (whethern infix, postfix, or prefix) have the nicety of being unambiguous. But really complicated ones are difficult for many people to read. This is one reason many mathematical texts will use different sized parentheses at different (nested) levels of grouping--even though changing the size of a printed ( or ) doesn't change it's meaning; it makes things easier for humans to read. And it's a reason why most languages provide more "human intuitive" syntaxes, even if it makes parsing more complicated and introduces ambiguity into the mix. (Many argue that it's a reason why Lisp--one language which doesn't provide infix syntax, reader macros nonwithstanding--hasn't been more successful. How true that is, I don't know).

Like many things, this is a user interface issue. Coming up with the right answer is not a simple problem--and no matter what you do (and how much research backs your decision), someone ain't gonna like it.