Prev: Is Matlab "libstruct" able to recognize the nested-C structure?
Next: Mex error directory invalid
From: Bruno Luong on 23 Apr 2010 02:19
"Zaphod " <a3904429(a)owlpic.com> wrote in message <hqr1g9$t5p$1(a)fred.mathworks.com>...
>
> My contention is essentially that Matlab should handle this case in the same way as every other language.

Agreed, this is due to the lack of support for cascading of indexing/evaluation, not only for anonymous functions but for generic functions/arrays.

Bruno
From: us on 23 Apr 2010 02:51
"Zaphod " <a3904429(a)owlpic.com> wrote in message <hqr1g9$t5p$1(a)fred.mathworks.com>...
> Disclaimer: I don't use Matlab much, and have expectations formed from years of programming in other languages. Taking this into consideration, I think that Matlab does not correctly implement anonymous functions.

> I think that (@(x) x + 1) should be evaluated first (the outer parens denoting order of operations) and return a value of type int->int, then that function should be applied to the argument 1. This behavior seems particularly inconsistent because the following matlab code works:
>
> f = @(x) @(y) x + y
> f(4) ----> evaluates to @(y) x + y
>
> The above example shows that at least in some sense, matlab is capable of evaluating an expression to a value with a function type.
>
> My contention is essentially that Matlab should handle this case in the same way as every other language (I gave examples in python and javascript, but I think that an analogous example can be made in AS3, C++ with Boost, SML and Haskell as well).

i'm glad it's the way it is - and - i hope it will never change...

us
From: Zaphod on 23 Apr 2010 18:55
Steve Eddins wrote:
------------------------
> exclude feval, the documented way to call a function handle &#8232;without assigning it to a variable first, and then you complain that you &#8232;can't call a function handle without assigning it to a variable first.&#8232;
You have a fair point here. As I mentioned, my gripe is that it is syntactically inconsistent, not that the missing functionality is useful.


Walter Roberson wrote:
-----------------------------

> Both parts of your gripe are mistaken.

Nuh uh.. your a poopy head.

> Let us start with the second one first: what-ever other use the language
> might have for them, () are used to denote argument lists to functions
> in computer languages such as Fortran, LISP, BASIC, C, C++, perl, Maple,
> SNOBOL, m4, ALGOL -- need I go on? Algol 68 was one of the first
> languages to treat procedures as first-class objects; it was also
> considered for a number of years to be too complex for it to be
> theoretically possible to build a parser for.

It doesn't matter that () denotes function calls in these languages. It also denotes order of evaluation. As long as it is unambiguous, there should be no problem. Too complex to parse? Are you kidding? Parsing has been a solved problem in computer science for 20+ years. All you have to do is specify an unambiguous grammar and programs like lex and yacc automatically compile a parser and lexer. "It's too difficult to parse" is not a valid excuse for any competent computer scientist in 2010. Implementing a parser that can deal with this is undergraduate coursework nowadays.

>
> The first half of first gripe, that it is inconsistent with other
> languages is trivially correct, but so what? The way python does it is
> inconsistent with the way that Algol 68 does it, but do you see gripes
> that python should be redesigned to be consistent with venerable
> languages such as Algol 68?

You haven't actually shown an example in Algol 68 of how this would be handled differently. Furthermore, Algol 68 is archaic, whereas all of the examples I gave are modern languages in common use. My example works the same in C++, AS3, JavaScript, Python, SML, OCML, Haskell, and probably many others. Matlab is the only widely used modern language that claims to support anonymous functions, but does not handle this case consistently. If you can give a single example of a modern language other than Matlab where this doesn't hold, I would be prepared to consider that as a valid point.

> The second half of your first gripe, that "many of which are quite
> consistent in how this is handled" reflects a lack of experience and
> reflection in the "use-mention" inconsistencies in most computer
> languages. Every computer language that permits assignments of the form

First, your comments about 'use-mention' are totally irrelevant to the matter at hand. The fact that you are babbling about 'use-mention' indicates that you have missed the whole point of this discussion, which is applying a function without first naming it!

Second, it is a fact that most other languages handle this case consistently. Here are a few more examples:

Standard ML:
(fn x => x + 1)(2) ---> evaluates to 3

ActionScript 3 (i.e. Flash):
trace(function(x){return x+1;}(2)); ----> prints 3

Third, I do not lack experience or reflection. I have written compilers that support this case.

> Now let name2 be an anonymous procedure whose _value_ (as an anonymous &#8232;> procedure) has become the "use" of name2 .

If you are naming a function 'name2', it is not anonymous (by definition). In the example I showed, I tried to apply a truly anonymous function, i.e. one that never has a name. There is a difference between an anonymous function (one that has no name), a value with type function, and a lambda-expression. A lambda-expression is part of the abstract syntax of a language, and evaluates to a value of type function. That value is anonymous if it does not have a name.

> And that requires &#8232;> that the language knows *at run time* that the value associated with &#8232;> name1 be examined and if it is an anonymous procedure

As I understand it, Matlab does a whole bunch of type checking at runtime to figure out how to apply a function.
Compilers are perfectly capable of figuring this stuff out at compile time, and have been for over 20 years (see 'The Implementation of Functional Programming Languages,' Simon Peyton Jones, 1987). Its called "static type inference." There are pros and cons to static vs. dynamic languages. As I understand it, Matlab is dynamic. Both static and dynamic languages are able to apply anonymous functions (SML is static, Python is dynamic).

> Oh, and by the way, if parens denote order of operations, then why is it
> that the order of evaluation is unspecified for tuples in python, which
> are a parenthesized notation ?
> http://docs.python.org/reference/expressions.html#parenthesized-forms
> Whereas the order is specified for "list displays",
> "When a comma-separated list of expressions is supplied, its elements
> are evaluated from left to right and placed into the list object in that
> order." Isn't that a bit backwards from what you were saying, in that
> brackets in the python language impose an order of evaluation, but
> parens do not?

In python you can write:

x = ((1+2)*3, 1)

after which x has the tuple value (9, 1). Python has no problem resolving ambiguity between parens for tuples, order of evaluation, and function calls, and handles them in a perfectly consistent way.

I think the point you are trying to make is that python's spec does not guarantee an order in which the elements of the tuple will be evaluated. The only case where this matters is if you are trying to create a tuple with values that are returned from functions with side-effects. For example:

def foo():
print "foo"
return 1

def bar():
print "bar"
return 2

x = (foo(), bar())

In this example, x will have the value (1,2), but the python spec is saying that there is no guarantee that it will print "foo" then "bar" instead of the other way around. In practice however, python 2.6 will actually output "foo" "bar", so evaluation order works the same as lists. The python spec does however say that if you did this:

x = [foo(), bar()]

it would output "foo" then "bar".
From: Zaphod on 24 Apr 2010 00:36
Walter Roberson <roberson(a)hushmail.com> wrote in message <hqthjq$96d$1(a)canopus.cc.umanitoba.ca>...
> Zaphod wrote:
> >> Algol 68 was one of
> >> the first languages to treat procedures as first-class objects; it was
> >> also considered for a number of years to be too complex for it to be
> >> theoretically possible to build a parser for.
>
> > It doesn't matter that () denotes function calls in these languages. It
> > also denotes order of evaluation. As long as it is unambiguous, there
> > should be no problem.
>
> Then what is your complaint about Matlab's use of () ? Matlab's () denote
> order of execution to pretty much the same extent that C's () denote order of
> execution (Fortran is stricter.) A procedure call using () to denote the
> argument list is *not* a matter of order of execution.

I said parens can denote several things in a language, namely order, invocation, tuples, etc. The key point here is that in this expression:

(@(x) x + 1)(2)

the reasonable result is 3, whereas in Matlab it is a syntax error. Also, it is not true that Matlab's parens denote order to the same extent as C. In C, you could write (slightly abbrevd):

void foo() {}

void main()
{
void* f = (void*)foo;
(f)();
}

In this case, the parens in (f) will be used for order of operation. The expression evaluates to a function pointer, which is then be applied. In Matlab, whether parens mean order of operation or syntax error (in cases where they unambiguously do not mean anything else), depends on if the enclosed expression is a function or not. That is the inconsistency.


I will admit that I don't know enough about Matlab to say that this is a completely unambiguous case. If you want to argue that I am wrong, this would be the place to make your point.


> "Those who do not study history are doomed to repeat it."

Right... the authors of Matlab didn't study the history of languages such as Algol, and thus repeated the mistake of defining a language that cannot be described with a context free grammar (or made a language that can be described with a CFG, but implemented an ad-hoc parser). Algol gained something in generality and power through its complex syntax. In the case I am pointing out, it is not clear that Matlab gains anything by failing to support this syntax.

> > You haven't actually shown an example in Algol 68 of how this would be
> > handled differently.
>
> (int x, y, z;
> proc xyz = void: (x := 1; y := 2; z := 3);
> xyz; xyz; xyz )

The example you give does not illustrate an attempt to apply an anonymous function, which is what all of my examples are about. In your example, the expression "void: (x := 1; y := 2; z := 3)" is assigned to the name xyz before it is applied. The fact that you don't need parens to indicate the application is irrelevant. I downloaded the Algol 68 Genie Mark 15.1 compiler (released January 2009) and attempted to run your example. It doesn't even compile. Here is an example in algol 68 that does compile, and illustrates that Algol 68 handles order of evaluation in the same way as every other language I gave as an example:

main: ( printf($"Hello World!"l$) )
---> prints "Hello World"

main: ( (printf)($"Hello World!"l$) )
---> not a syntax error, still prints "Hello World"

Algol 68 actually supports my perspective, not yours.

> > Furthermore, Algol 68 is archaic, whereas all of
> > the examples I gave are modern languages in common use.
>
> Your posting said, and I quote,
>
> "my gripe here isn't that missing this functionality is a big inconvenience,
> but that it is inconsistent with other languages"
>
> You did not, in your gripe, restrict yourself to "modern languages in common
> use". Did you think that Fortran is not a "modern language in common use" ?

I am aware that Fortan is still widely used. I don't know if it supports anonymous functions though. If it does, it would be interesting to know how it handles this case.

> Fortran had a revision report in 2008, C had technical corrections to the
> standard in 2004 ("TC3") and started the standards revision cycle in 2007;
> perl is redefined every month or so (the implementation of perl is defined as
> being the Standard for perl); Maple is a 2009 release and there are solid
> rumours of a 2009 release; LISP had a very active 50th anniversary in 2008,
> and its close descendant Scheme had a new standards release in 2008.
>

Is this your list of modern languages? Every one of them (with the possible exception of Maple, which I don't know about) would handle the case I am suggesting in the way I say should be expected. I have already illustrated this for JavaScript, AS3, Python, SML, C and Algol 68. Here's is yet another example, this time in Scheme:

((lambda (x) (+ x 1)) 2)
--> evaluates to 3

>
> Right. And if I point one out, you'll say it is not "modern" or "widely used".
>

I gave examples in 7 languages... you have given 0 legit examples (as your example of Algol 68 actually illustrates my point).


> > First, your comments about 'use-mention' are totally irrelevant to the
> > matter at hand.

The matter at hand is *applying an anonymous function*. Your comments about 'use-mention' are barely related. Demonstrating that other languages have inconsistencies isn't the point.

> Well, your cited languages such as python and C++ are also inconsistent in how they treat
> anonymous functions; the inconsistencies becomes most apparent when you
> examine the bindings between names and values

Yes, there are inconsistencies in other languages. Does this mean we cannot point out inconsistencies in Matlab? Pointing out flaws like this might lead to a better language. If you find these problems in other languages to be a grievance, bring it up in the appropriate forum (as I did here).


>
> > I think the point you are trying to make is that python's spec does not
> > guarantee an order in which the elements of the tuple will be evaluated.
>
> You took such pains to claim that parens denote order of execution, and yet in
> your favorite example language, they do not!
>

I said parens can denote order of evaluation, function application or tuples, and that in Python, the meaning is not ambiguous. You tried to represent an inconsequential footnote in Python's spec as though it were somehow a major inconsistency. As I showed in my examples, it is not. Even if you had successfully demonstrated an inconsistency in python, it would still boil down to an argument of 'don't criticize matlab because python is inconsistent also'. I never said other languages are perfectly consistent. I said that most languages are consistent in how they handle this particular case (applying an anonymous function), but Matlab isn't.

Also, C++ is my favorite.

>
> Your gripes are a mish-mash of inconsistent ideas. You blame a language for
> not being as you expect, and compare it to nameless "other computer languages"

I have given specific examples of how this case is handled consistently by C, JavaScript, Scheme, SML, Python, AS3 and Algol 68. These are not "nameless".


> and then reject it when I point out the long history of other computer
> languages having the same behaviour.

You pointed out one language that is ancient, not widely used, and gave a bogus example that actually illustrates my point and contradicts yours.

> You blame a language for being
> inconsistent with respect to certain functionality, and yet are unable to see
> the inconsistencies in your chosen reference languages.

I never said other languages were consistent in every way. I said that they are consistent in handling the case of applying an anonymous function.

>You treat a complex
> language that you do not know as being "archaic"

You are saying Algol 68 is not archaic? The 68 stands for 1968.
I looked for lists of most used programming languages and couldn't even find one listing Algol.
http://www.devtopics.com/most-popular-programming-languages/
http://langpop.com/

> and only worthy of attention
> at the undergrad level,

I said that writing a parser that handles this case is undergraduate coursework. I did not say the study of programming languages was.

> when in fact it was the only language jointly designed
> by the founding fathers of strict formalism in computer languages, and takes
> such extremes of consistency and flexibility that it in practice embeds an
> extensive and extensible programming language of *types*, and as such cannot
> be analyzed by any static set of production rules such as are embodied by lex
> and yacc.
>
> You have create compilers; did you study denotational semantics? Did you
> pursue denotational semantics far enough to recognize that it is not able to
> finitely represent all of mathematics (not even the mathematics of integers),
> and thus that there will always be programs that *cannot* be represented with
> *any* finite and consistent system of strong semantics (which other branches
> would call "axioms")? Goedel's Incompleteness Theorems applies to computer
> languages too -- and the only answer, if we wish to be able to reason in such
> areas, is for us to accept inconsistencies in our computing languages.

You are misinterpreting Goedel's theorem in the context of programming languages. What Goedel's theorem says about languages is that there exist languages such that deciding if a string belongs to that language is not computable. The take-home message as it applies to programming language design is not that one must accept inconsistency, but that one should avoid designing languages that cannot be parsed.
From: Zaphod on 24 Apr 2010 13:56
To be more correct, Goedel's theorem doesn't say anything about languages. It is about Peano arithmetic. However, the result I stated is the most closely analogous incompleteness result for languages.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Is Matlab "libstruct" able to recognize the nested-C structure?
Next: Mex error directory invalid