Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RFC: A shorter lambda syntax (#L reader macro)
334 views
Skip to first unread message
Krzysztof Drewniak
Dec 22, 2011, 5:52:23 PM12/22/11
to
I have created a new reader macro to make writing lambda-heavy code less
cumbersome. Code that used mapcar and friends a lot tends to include
many instances of:
(lambda (x) (frob x))
My macro reduced the amount of typing needed to get a lambda function.
Instead of writing (lambda (x) ...), one writes
#L(x [code that uses x])
If the lambda needs to take something other then one requires argument,
parentheses are needed around the first expression, which is the lambda
list. For example:
#L((x y) (expt x y))
#L((&rest elms) (reverse elms))
Here's the implementation:
(set-dispatch-macro-character
#\# #\L
#'(lambda (stream char1 char2)
(let ((l-form (read stream t nil t)))
(when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
(apply #'list 'lambda l-form))))
--
X-Real-Email-With-Antispam: krzysdrewniak at gmail dot com
pgp key on keyserver.ubuntu.com 2388E924
cumbersome. Code that used mapcar and friends a lot tends to include
many instances of:
(lambda (x) (frob x))
My macro reduced the amount of typing needed to get a lambda function.
Instead of writing (lambda (x) ...), one writes
#L(x [code that uses x])
If the lambda needs to take something other then one requires argument,
parentheses are needed around the first expression, which is the lambda
list. For example:
#L((x y) (expt x y))
#L((&rest elms) (reverse elms))
Here's the implementation:
(set-dispatch-macro-character
#\# #\L
#'(lambda (stream char1 char2)
(let ((l-form (read stream t nil t)))
(when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
(apply #'list 'lambda l-form))))
--
X-Real-Email-With-Antispam: krzysdrewniak at gmail dot com
pgp key on keyserver.ubuntu.com 2388E924
Zach Beane
Dec 22, 2011, 6:17:29 PM12/22/11
to
Krzysztof Drewniak <krzysdrew...@gmail.com> writes:
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
It seems more likely to use #'frob in this situation.
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
>
> If the lambda needs to take something other then one requires argument,
> parentheses are needed around the first expression, which is the lambda
> list. For example:
>
> #L((x y) (expt x y))
>
> #L((&rest elms) (reverse elms))
>
> Here's the implementation:
>
> (set-dispatch-macro-character
> #\# #\L
> #'(lambda (stream char1 char2)
> (let ((l-form (read stream t nil t)))
> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
> (apply #'list 'lambda l-form))))
(apply #'list x list) is better written (list* x list).
Zach
Krzysztof Drewniak
Dec 22, 2011, 7:20:32 PM12/22/11
to
Zach Beane <xa...@xach.com> writes:
> Krzysztof Drewniak <krzysdrew...@gmail.com> writes:
>
>> I have created a new reader macro to make writing lambda-heavy code less
>> cumbersome. Code that used mapcar and friends a lot tends to include
>> many instances of:
>>
>> (lambda (x) (frob x))
>
> It seems more likely to use #'frob in this situation.
>
True. I probably should have used a different example. I was thinking of
> Krzysztof Drewniak <krzysdrew...@gmail.com> writes:
>
>> I have created a new reader macro to make writing lambda-heavy code less
>> cumbersome. Code that used mapcar and friends a lot tends to include
>> many instances of:
>>
>> (lambda (x) (frob x))
>
> It seems more likely to use #'frob in this situation.
>
situations like
(remove-if (lambda (x) (= a-constant x)) a-list)
And stuff that can't be reduced to something like #'frob .
>> My macro reduced the amount of typing needed to get a lambda function.
[snip]
>> (set-dispatch-macro-character
>> #\# #\L
>> #'(lambda (stream char1 char2)
>> (let ((l-form (read stream t nil t)))
>> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
>> (apply #'list 'lambda l-form))))
>
> I suggest using destructuring-bind.
>
How would I use destructuring-bind here?
>> #\# #\L
>> #'(lambda (stream char1 char2)
>> (let ((l-form (read stream t nil t)))
>> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
>> (apply #'list 'lambda l-form))))
>
> I suggest using destructuring-bind.
>
> (apply #'list x list) is better written (list* x list).
>
Thanks. I didn't know about list* .
>
> Zach
Thanks for the feedback.
Kaz Kylheku
Dec 22, 2011, 7:22:52 PM12/22/11
to
On 2011-12-22, Krzysztof Drewniak <krzysdrew...@gmail.com> wrote:
> --=-=-=
> Content-Transfer-Encoding: quoted-printable
{|x| (frob x)}
It's way less useful than you might think, because it only saves typing.
It doesn't implement any conceptual transformation.
By the way, a project called Arnesi has a #L lambda macro already!
Look here:
http://common-lisp.net/project/bese/docs/arnesi/html/index.html
Under "A reader macro for simple lambdas".
If you want to make "lambda-heavy" code less cumbersome, what will help you is
to make yourself some operators for combining functions, and for partial
evaluation.
In MIT's language Goo, there is an operator called op.
For instance, (op + _ 1) produces a function f of 1 argument such that
(f x) is equivalent to (+ x 1). I think, by default, there is one
required argument so (op + 1) produces the equivalent of Lisp's 1+ function.
In CL we have the 1+ function, so we can do:
(mapcar #'1+ '(1 2 3)) -> (2 3 4)
With the op operator this could be:
(mapcar (op + 1) '(1 2 3)) -> (2 3 4)
or
(mapcar (op _ + 1) '(1 2 3)) -> (2 3 4)
There is a Common Lisp utility which introduces a very similar operator:
http://code.google.com/p/cl-op/
In addition to this, you might want a few combinators: functions that
take functions as arguments and produce different functions.
For instance, suppose you have a list of items and you want to test
whether it contains an item x for which (foo-p x) is true and (bar-p x)
is also true.
straightforward way with lambda:
(find-if (lambda (x) (and (oddp x) (integerp (sqrt x)))) '(11 25)) -> 25
Now suppose I have a function called ANDF which takes zero or more
one-argument functions, and returns a one-argument function which will call
them one by one with an argument, and return nil when it encounters
the first function call that returns nil, or else returns the value of
the last function call:
(find-if (andf #'oddp (lambda (x) (integerp (sqrt x)))) '(11 25))
We still have a lambda because we have no way of combining integerp and sqrtx.
For that, we can invent another functional function called chain: chain will
take several one-argument functions and produce a single function which is
their composition:
(find-if (andf #'oddp (chain #'sqrt #'integerp)) '(11 25))
I.e. find the element that is odd, and whose square root satsifies integerp.
Possible definitions for ANDF and CHAIN are:
(defun andf (&rest functions)
(let ((result t))
(lambda (arg)
(dolist (f functions result)
(unless (setf result (funcall f arg))
(return nil))))))
(defun chain (&rest functions)
(lambda (x)
(reduce (lambda (arg fun) (funcall fun arg))
functions :initial-value x)))
Now here is where we might want to have some syntactic sugar so that
we don't have to write #':
(find-if (andf oddp (chain sqrt integerp)) '(11 25))
But note that now ANDF has to recognize (chain ...) specially, and
any other operator like (op ...) from that package.
But even so, we don't have to use the reader to achieve the syntactic
sugar, just regular macros.
> --=-=-=
> Content-Transfer-Encoding: quoted-printable
>
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
I did too, as a Lisp newbie.
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
Mine looked something like this:
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
{|x| (frob x)}
It's way less useful than you might think, because it only saves typing.
It doesn't implement any conceptual transformation.
By the way, a project called Arnesi has a #L lambda macro already!
Look here:
http://common-lisp.net/project/bese/docs/arnesi/html/index.html
Under "A reader macro for simple lambdas".
If you want to make "lambda-heavy" code less cumbersome, what will help you is
to make yourself some operators for combining functions, and for partial
evaluation.
In MIT's language Goo, there is an operator called op.
For instance, (op + _ 1) produces a function f of 1 argument such that
(f x) is equivalent to (+ x 1). I think, by default, there is one
required argument so (op + 1) produces the equivalent of Lisp's 1+ function.
In CL we have the 1+ function, so we can do:
(mapcar #'1+ '(1 2 3)) -> (2 3 4)
With the op operator this could be:
(mapcar (op + 1) '(1 2 3)) -> (2 3 4)
or
(mapcar (op _ + 1) '(1 2 3)) -> (2 3 4)
There is a Common Lisp utility which introduces a very similar operator:
http://code.google.com/p/cl-op/
In addition to this, you might want a few combinators: functions that
take functions as arguments and produce different functions.
For instance, suppose you have a list of items and you want to test
whether it contains an item x for which (foo-p x) is true and (bar-p x)
is also true.
straightforward way with lambda:
(find-if (lambda (x) (and (oddp x) (integerp (sqrt x)))) '(11 25)) -> 25
Now suppose I have a function called ANDF which takes zero or more
one-argument functions, and returns a one-argument function which will call
them one by one with an argument, and return nil when it encounters
the first function call that returns nil, or else returns the value of
the last function call:
(find-if (andf #'oddp (lambda (x) (integerp (sqrt x)))) '(11 25))
We still have a lambda because we have no way of combining integerp and sqrtx.
For that, we can invent another functional function called chain: chain will
take several one-argument functions and produce a single function which is
their composition:
(find-if (andf #'oddp (chain #'sqrt #'integerp)) '(11 25))
I.e. find the element that is odd, and whose square root satsifies integerp.
Possible definitions for ANDF and CHAIN are:
(defun andf (&rest functions)
(let ((result t))
(lambda (arg)
(dolist (f functions result)
(unless (setf result (funcall f arg))
(return nil))))))
(defun chain (&rest functions)
(lambda (x)
(reduce (lambda (arg fun) (funcall fun arg))
functions :initial-value x)))
Now here is where we might want to have some syntactic sugar so that
we don't have to write #':
(find-if (andf oddp (chain sqrt integerp)) '(11 25))
But note that now ANDF has to recognize (chain ...) specially, and
any other operator like (op ...) from that package.
But even so, we don't have to use the reader to achieve the syntactic
sugar, just regular macros.
Kaz Kylheku
Dec 22, 2011, 7:24:07 PM12/22/11
to
On 2011-12-22, Zach Beane <xa...@xach.com> wrote:
> I suggest using destructuring-bind.
>
> (apply #'list x list) is better written (list* x list).
And (list* one two) is better written (cons one two).
> I suggest using destructuring-bind.
>
> (apply #'list x list) is better written (list* x list).
*huge wink*
:)
Kaz Kylheku
Dec 22, 2011, 8:55:43 PM12/22/11
to
On 2011-12-23, Krzysztof Drewniak <krzysdrew...@gmail.com> wrote:
> Zach Beane <xa...@xach.com> writes:
>
>> Krzysztof Drewniak <krzysdrew...@gmail.com> writes:
>>
>>> I have created a new reader macro to make writing lambda-heavy code less
>>> cumbersome. Code that used mapcar and friends a lot tends to include
>>> many instances of:
>>>
>>> (lambda (x) (frob x))
>>
>> It seems more likely to use #'frob in this situation.
>>
> True. I probably should have used a different example. I was thinking of
> situations like
>
> (remove-if (lambda (x) (= a-constant x)) a-list)
See, that is clear currying situation. You're only introducing the lambda
> Zach Beane <xa...@xach.com> writes:
>
>> Krzysztof Drewniak <krzysdrew...@gmail.com> writes:
>>
>>> I have created a new reader macro to make writing lambda-heavy code less
>>> cumbersome. Code that used mapcar and friends a lot tends to include
>>> many instances of:
>>>
>>> (lambda (x) (frob x))
>>
>> It seems more likely to use #'frob in this situation.
>>
> True. I probably should have used a different example. I was thinking of
> situations like
>
> (remove-if (lambda (x) (= a-constant x)) a-list)
as a gimmick to reduce a two-argument function to a one-argument function.
Your lambda is not even capturing any lexical environment that you care about;
i.e. it's not being a closure.
So if you want a short hand, here is one:
;; using that Goo-like cl-op library:
(remove-if (op = a-constant) a-list)
In the syntaxes of some functional languages, that would just be:
remove-if (= a-constant) a-list
Any function, if not given enough arguments, simply produces a function
which binds the arguments that were given, and accepts the remaining
arguments.
That's pretty dumb though, because it behooves us to distinguish the
error case when a 3 argument function is given only 2 arguments by
accident, rather than by the intent to curry to one argument.
Tim Bradshaw
Dec 23, 2011, 3:41:13 AM12/23/11
to
> Mine looked something like this:
>
> {|x| (frob x)}
>
It seems to me that, now probably every CL has a character set which
>
> {|x| (frob x)}
>
includes a lambda character that the solution to most of this stuff is to
use that. It's easy (and, modulo character encoding questions, portable)
to define the appropriate macro, is within a couple of characters of the
shortest reasonable readmacro, and looks visually attractive. The thing
that is a bit harder is to make ((lambda (...) ...) ...) work, I think. I
think Ron Garret may have had something which did that.
Rainer Joswig
Dec 23, 2011, 5:01:55 AM12/23/11
to
On Dec 22, 11:52 pm, Krzysztof Drewniak
> application_pgp-signature_part
> < 1KViewDownload
(lambda (a b) (foo a b c d) ...)
is more cumbersome than
#L((a b) (foo a b c d) ...)
Really? For a few characters I would have more visual noise and I have
to give up prefix notation?
If typing a lambda expression or other more demanding expressions is a
problem then I prefer the following:
* functional abstraction
* macro-based syntactic abstraction
* an editor extension (an editor macro, auto expansion, code
templates, ...)
> < 1KViewDownload
(lambda (a b) (foo a b c d) ...)
is more cumbersome than
#L((a b) (foo a b c d) ...)
Really? For a few characters I would have more visual noise and I have
to give up prefix notation?
If typing a lambda expression or other more demanding expressions is a
problem then I prefer the following:
* functional abstraction
* macro-based syntactic abstraction
* an editor extension (an editor macro, auto expansion, code
templates, ...)
Chris Riesbeck
Dec 23, 2011, 2:20:13 PM12/23/11
to
On 12/23/2011 2:41 AM, Tim Bradshaw wrote:
> Kaz Kylheku<k...@kylheku.com> wrote:
>
>> I did too, as a Lisp newbie.
>
>> Mine looked something like this:
>>
>> {|x| (frob x)}
>>
>
> It seems to me that, now probably every CL has a character set which
> includes a lambda character that the solution to most of this stuff is to
> use that. It's easy (and, modulo character encoding questions, portable)
> to define the appropriate macro, is within a couple of characters of the
> shortest reasonable readmacro, and looks visually attractive.
Drew McDermott did
> Kaz Kylheku<k...@kylheku.com> wrote:
>
>> I did too, as a Lisp newbie.
>
>> Mine looked something like this:
>>
>> {|x| (frob x)}
>>
>
> It seems to me that, now probably every CL has a character set which
> includes a lambda character that the solution to most of this stuff is to
> use that. It's easy (and, modulo character encoding questions, portable)
> to define the appropriate macro, is within a couple of characters of the
> shortest reasonable readmacro, and looks visually attractive.
(defmacro | | (&rest l) (cons 'lambda l))
enabling
(mapcar (\ (x) (* x x x)) '(1 2 3 4))
He did it with a straight face too!
Xah Lee
Dec 26, 2011, 12:30:11 PM12/26/11
to
you don't care, or is your site gone for good?
Xah
Xah Lee
Dec 26, 2011, 12:39:38 PM12/26/11
to
On Dec 22, 2:52 pm, Krzysztof Drewniak <krzysdrewniakNOS...@gmail.com>
wrote:
if you want to still code in lisp, best to do is to create a alias so
that 「λ」 stands for 「lambda」, and let that be it.
if you want to get fancy, start a systematic M-expression layer like
Mathematica.
For example, lambda in Mathematica is this:
Function[{x},x^2]
Function[{x,y},x^2+y]
Function[{x,y,z},x^2+y+z]
etc.
but the short hand is:
#1^2 &
#1^2 + #2 &
#1^2 + #2 + #3 &
and in general, #n is the nth argument, and the “&” is a postfix for
lambda.
for full intro, see:
〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html
〈Programing: a Example of Mathematica's Expressiveness: Writing a
Vector Normalization Function〉
http://xahlee.org/UnixResource_dir/writ/Mathematica_expressiveness.html
〈Short Intro of Mathematica For Lisp Programers (list processing
example)〉
http://xahlee.org/UnixResource_dir/writ/notations_mma.html
Xah
wrote:
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
>
> If the lambda needs to take something other then one requires argument,
> parentheses are needed around the first expression, which is the lambda
> list. For example:
>
> #L((x y) (expt x y))
>
> #L((&rest elms) (reverse elms))
>
> Here's the implementation:
>
> (set-dispatch-macro-character
> #\# #\L
> #'(lambda (stream char1 char2)
> (let ((l-form (read stream t nil t)))
> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
> (apply #'list 'lambda l-form))))
not good.
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
>
> If the lambda needs to take something other then one requires argument,
> parentheses are needed around the first expression, which is the lambda
> list. For example:
>
> #L((x y) (expt x y))
>
> #L((&rest elms) (reverse elms))
>
> Here's the implementation:
>
> (set-dispatch-macro-character
> #\# #\L
> #'(lambda (stream char1 char2)
> (let ((l-form (read stream t nil t)))
> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
> (apply #'list 'lambda l-form))))
if you want to still code in lisp, best to do is to create a alias so
that 「λ」 stands for 「lambda」, and let that be it.
if you want to get fancy, start a systematic M-expression layer like
Mathematica.
For example, lambda in Mathematica is this:
Function[{x},x^2]
Function[{x,y},x^2+y]
Function[{x,y,z},x^2+y+z]
etc.
but the short hand is:
#1^2 &
#1^2 + #2 &
#1^2 + #2 + #3 &
and in general, #n is the nth argument, and the “&” is a postfix for
lambda.
for full intro, see:
〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html
〈Programing: a Example of Mathematica's Expressiveness: Writing a
Vector Normalization Function〉
http://xahlee.org/UnixResource_dir/writ/Mathematica_expressiveness.html
〈Short Intro of Mathematica For Lisp Programers (list processing
example)〉
http://xahlee.org/UnixResource_dir/writ/notations_mma.html
Xah
Tim Bradshaw
Dec 26, 2011, 3:09:56 PM12/26/11
to
Xah Lee <xah...@gmail.com> wrote:
> Function[{x},x^2]
> Function[{x,y},x^2+y]
> Function[{x,y,z},x^2+y+z]
> etc.
>
> but the short hand is:
>
> #1^2 &
> #1^2 + #2 &
> #1^2 + #2 + #3 &
>
>
Mathematica is some kind of object lesson in how not to learn any lessons
> Function[{x},x^2]
> Function[{x,y},x^2+y]
> Function[{x,y,z},x^2+y+z]
> etc.
>
> but the short hand is:
>
> #1^2 &
> #1^2 + #2 &
> #1^2 + #2 + #3 &
>
>
at all from previous languages, presumably because, with a head
sufficiently large, the decreased surface-to-volume ratio means no
information at all can actually penetrate from outside. Using it makes me
itch.
However, if you do have to use it, it's worth knowing that there's a less
insanely-bad notation for functions: you can write {x} -> x^2 say (where
"->" is some special symbol which you type by, I think, ESC-f-n-ESC (and
it's really an arrow with a flat tail, not just an arrow)). With both the
(terrible) trailing-& notation (positional parameters, yes!) and the
(better) arrow-notation you have to care about precedence, to the extent
that it is almost always safest to just parenthesise the thing.
Xah Lee
Dec 26, 2011, 9:18:39 PM12/26/11
to
it's positive about Mathematica or not (but i guess it's not).
the thing about symbol precedence is that it's a natural complexity
that is not avoidable. When you have just a few symbols, and if they
are widely used, such as + - ^ / && || , the precedence is burned into
the brain, no problem. But as the symbols increase, inevitably it
becomes a problem to memorize. Yet, you do want a lot symbols, because
they (the symbols/operator) makes the notation far more shorter and
easier to understand if you have to work with it long term.
i detailed here
Xah
Richard Fateman
Dec 27, 2011, 2:12:59 PM12/27/11
to
I was curious as to why Xah Lee thought Tim could possibly be praising
Mathematica. So I looked at his link.
from http://xahlee.org/math/function_and_operators.html
....
Though, almost all computer languages does not have a regular syntax, in
fact, non of any major computer lang has a syntax specification. The
closest one that has a somewhat regular and simple syntax grammar is
Mathematica.
....
From this I conclude that Xah has imbibed some Mathematica Kool Aid.
Wolfram does not provide any formal grammar for Mathematica's language.
This is in contrast to "almost all computer languages" which DO have a
syntax described in Backus-Naur Form. (The term "regular" wrt syntax
has a particular formal distinction).
RJF
On 12/26/2011 6:18 PM, Xah Lee wrote:
....
Xah Lee
Dec 27, 2011, 5:43:51 PM12/27/11
to
On Dec 27, 11:12 am, Richard Fateman <fate...@cs.berkeley.edu> wrote:
> I was curious as to why Xah Lee thought Tim could possibly be praising
> Mathematica. So I looked at his link.
>
> from http://xahlee.org/math/function_and_operators.html
> ....
>
> Though, almost all computer languages does not have a regular syntax, in
> fact, non of any major computer lang has a syntax specification. The
> closest one that has a somewhat regular and simple syntax grammar is
> Mathematica.
>
> ....
>
> From this I conclude that Xah has imbibed some Mathematica Kool Aid.
> Wolfram does not provide any formal grammar for Mathematica's language.
to do whether the language in fact has a systemic formal grammar
that's exceedingly simple.
And of course Wolfram doesn't publish it. It's a commercial language
with value that runs Wolfram Alpha, not the failed Macsyma or the now
open source garbage Maxima.
> This is in contrast to "almost all computer languages" which DO have a
> syntax described in Backus-Naur Form.
c++, python, perl, php, html, xml.
i think the only exception is Scheme Lisp, which, as we know, has
little syntax to talk about.
But also, the fact that a lang do have published a grammar spec has
little to do whether it is regular.
> (The term "regular" wrt syntax has a particular formal distinction).
known antagonism against Mathematica and Wolfram, am not sure i'd get
answers that's unbiased and useful to me.
Xah
Richard Fateman
Dec 27, 2011, 6:38:52 PM12/27/11
to
On 12/27/2011 2:43 PM, Xah Lee wrote:
>
> On Dec 27, 11:12 am, Richard Fateman<fate...@cs.berkeley.edu> wrote:
>
> you are a well know hater of Mathematica.
Um, thanks, I guess.
>
> On Dec 27, 11:12 am, Richard Fateman<fate...@cs.berkeley.edu> wrote:
>
> you are a well know hater of Mathematica.
>
>> Wolfram does not provide any formal grammar for Mathematica's language.
>
> Whether Wolfram published a formal grammar of Mathematica has little
> to do whether the language in fact has a systemic formal grammar
> that's exceedingly simple.
doesn't have one that is simple. You could, of course, prove me wrong
by publishing a formal grammar that is correct and complete.
Personally, having taught parser construction methods including
automated syntax-directed techniques, and having written a parser for
Mathematica (version 3, much of version 8) in Lisp, I think the two
don't go together very well.
>
> And of course Wolfram doesn't publish it. It's a commercial language
> with value that runs Wolfram Alpha,
programs written in it that have value?
what is the value of Wolfram Alpha? it says alpha*($6,613.87) per
metric ton as of July, 1998.
not the failed Macsyma or the now
> open source garbage Maxima.
>
>> This is in contrast to "almost all computer languages" which DO have a
>> syntax described in Backus-Naur Form.
>
> No they don't. Show me some. Let's say the most popular ones: java, c,
> c++, python, perl, php, html, xml.
OK, I thought you had access to Google and could find these yourself..
>> This is in contrast to "almost all computer languages" which DO have a
>> syntax described in Backus-Naur Form.
>
> No they don't. Show me some. Let's say the most popular ones: java, c,
> c++, python, perl, php, html, xml.
the C grammar is in
Kernighan and Ritchie, The C Programming Language, App. A,
the Java grammar is in
http://java.sun.com/docs/books/jls/second_edition/html/syntax.doc.html
the Python grammar is in
http://www.python.org/doc//current/reference/expressions.html
C++ is probably in various places, including
http://www.nongnu.org/hcb/
perl is, I think not amenable to systematic context-free description, in
that it uses some odd tricks during lexical analysis. (As does
Mathematica).
html is not a programming language but a markup language; it is
described formally not by bnf but by a formal SGML DTD.
I'm not familiar enough with PHP to say anything about it except that
from googling for its grammar, it seems to be a piece of malleable garbage..
Other languages, like Algol-60, Pascal, FORTRAN, Basic, ... also have
(annotated) formal syntax descriptions, typically available in any
reference manual for them.
>
> i think the only exception is Scheme Lisp, which, as we know, has
> little syntax to talk about.
>
> But also, the fact that a lang do have published a grammar spec has
> little to do whether it is regular.
>
>> (The term "regular" wrt syntax has a particular formal distinction).
>
> Sure, and i would ask you some questions about syntax, but given your
> known antagonism against Mathematica and Wolfram, am not sure i'd get
> answers that's unbiased and useful to me.
right and left linear grammars, for example.
Happy new year.
RJF
David Golden
Dec 27, 2011, 7:36:31 PM12/27/11
to
On 27/12/11 23:38, Richard Fateman wrote:
> html is not a programming language but a markup language; it is
> described formally not by bnf but by a formal SGML DTD.
Just a heads up, HTML 5* is breaking with that. It still *looks* a lot
> html is not a programming language but a markup language; it is
> described formally not by bnf but by a formal SGML DTD.
like SGML, but it's no longer how it's specified. Well, the enterprisey
XML variant is presumably still notionally SGML insofar as XML itself
is, but that's not the main focus.
* Note also how they're now just saying "<!doctype html>" without
anything like version info. Uh huh.
http://dev.w3.org/html5/spec/parsing.html#parsing
"""
While the HTML syntax described in this specification bears a close
resemblance to SGML and XML, it is a separate language with its own
parsing rules.
Some earlier versions of HTML (in particular from HTML2 to HTML4) were
based on SGML and used SGML parsing rules. However, few (if any) web
browsers ever implemented true SGML parsing for HTML documents; the only
user agents to strictly handle HTML as an SGML application have
historically been validators. The resulting confusion — with validators
claiming documents to have one representation while widely deployed Web
browsers interoperably implemented a different representation — has
wasted decades of productivity. This version of HTML thus returns to a
non-SGML basis.
Authors interested in using SGML tools in their authoring pipeline are
encouraged to use XML tools and the XML serialization of HTML.
"""
Tim Bradshaw
Dec 28, 2011, 7:49:37 AM12/28/11
to
Xah Lee <xah...@gmail.com> wrote:
> Tim, i have a hard time trying to get what you are saying, whether
> it's positive about Mathematica or not (but i guess it's not).
>
Well, I've paid for both 7 and 8 myself, and it tends to be one of the
> Tim, i have a hard time trying to get what you are saying, whether
> it's positive about Mathematica or not (but i guess it's not).
>
things that is running on my laptop all the time, so let's say I have mixed
feelings, at best. The notebook interface is reasonably close to what I
think interfaces to this sort of interactive application should be like, at
least in outline, and having a competent (if perhaps idiosyncratic) algebra
system with easy, seamless visualisation tools is something I find very
useful indeed. The only other system I've used which gets close (in a
different area) is LispWorks (I'm not including the Genera interface for
reasons of performance and lack of availability).
But I think the language design is poor at best: it has the right idea of a
substrate language (which in Mathematica is the op[arg...] language) with a
surface syntax friendly to people who want to type maths: I want to type
"x+y+z" not "Plus[x,y,z]" or whatever the underlying operator is, when I'm
typing maths (note the caveat here: do not take this as an argument that I
think Lisp should have a surface syntax for programming). But because it
really does not expose the way that surface syntax gets defined *and*
because it defines a huge amount of surface syntax, it ends up being
fragile and hard to extend. There are various botches to get around this,
such as the whole upvalues/downvalues thing, but that's clearly just a
botch.
And the substrate language, well. I think this gets to the core of the
problem: things like scope, extent and evaluation rules are just a huge
mess, in a way which might have been reasonable in the 60s, before people
had got this stuff sorted out. It's just a mass of weird & opaque special
cases, which completely misses the underlying things which got sorted out
in Lisp & (more so) Scheme in, I guess, the 70s (maybe the 80s if you want
a clean macro system, though actually CL's is fine). And I think the
reason it is that way is because its author (who is clearly extremely
smart, don't get me wrong) has such an inflated idea of his own genius that
he will not listen to anyone else, ever. That really shows in the
documentation, which spends half its time crowing about how clever it all
is: that leaves a really bad taste in my mouth.
But it's the best tool I know of (other than pen & paper) for a lot of the
casual-thinking-about-physics I like to do.
> the thing about symbol precedence is that it's a natural complexity
> that is not avoidable. When you have just a few symbols, and if they
> are widely used, such as + - ^ / && || , the precedence is burned into
> the brain, no problem. But as the symbols increase, inevitably it
> becomes a problem to memorize. Yet, you do want a lot symbols, because
> they (the symbols/operator) makes the notation far more shorter and
> easier to understand if you have to work with it long term.
the notational-laziness that you can when writing something for consumption
by a person. For instance I can write "E/hc" and I know that what I mean
is "E/(hc)", but a program will almost certainly interpret this as "(E/h)c"
which is radically different. I think the problem Mathematica has is that
it has a single "space" of surface syntax with *all* the syntax there at
once, where what you really want is the ability to construct spaces
(contexts?) where only the bits you care about are, and also a way of
defining what the surface syntax is. It's possible it even has this: I am
mostly a casual user of it.
--tim
Xah Lee
Dec 30, 2011, 3:30:13 PM12/30/11
to
2011-12-28
Dear Richard,
you are, perhaps the top 10 haters of Mathematica/Wolfram on this
earth. Me, is a dedicated lover of Mathematica, and actually i admire
Stephen Wolfram, his ideas, personality, too, in fact many of his
views, philosophies, are in alignment with my own. (one other guy i
could think of is Bertrand Russell)
Richard Fateman wrote:
> This is in contrast to "almost all computer languages" which DO have a
> syntax described in Backus-Naur Form.
> the Python grammar is inhttp://www.python.org/doc//current/reference/expressions.html
> C++ is probably in various places, includinghttp://www.nongnu.org/hcb/
english. Just read grammar books!
i didn't clarify myself before. Let me do now.
No major programing language in use has a formal grammar for their
syntax. By formal grammar, i mean a “formal language” (in the context
of symbolic logic. See http://en.wikipedia.org/wiki/Formal_language .
Parsing Expression Grammar would be a example of such formal
language).
In particular, let's look at 2 examples. Java and Python.
Neither have a FORMAL LANGUAGE spec of their syntax. Worse, both
their “spec” is not sufficient to implement the language, even just
the syntax part. The vast majority of “language spec” are like that.
They are more of “a guide to implementation”, and that's it.
Fateman wrote:
> (The term "regular" wrt syntax has a particular formal distinction).
> Sure, and i would ask you some questions about syntax, but given your
> known antagonism against Mathematica and Wolfram, am not sure i'd get
> answers that's unbiased and useful to me.
> Google is your friend. Look up "regular grammar" to find out about
> right and left linear grammars, for example.
Now, let me discuss my idea about “regular syntax”. (i don't know if
there's a term for this idea, so i just say “my idea”. Actually i
should call it “systematic syntax”. That would be better than “regular
syntax”.)
The “systematic syntax” i have in mind is this:
• a language with a formal language spec of the syntax.
• this formal language spec, is “regular” in the sense that it is very
simple, perhaps just a handful of rules. As a example of opposite, you
could have a formal language spec for Java syntax, but that would be
tens or hundreds of pages.
Now, my claim about Mathematica is this: its syntax specified in a
general formal language would be very small, yet the syntax is very
rich. No other major lang comes close. (lisp would also have a very
simple syntax spec in formal lang, but its syntax isn't rich).
Now, we can discuss what is meant by “simple”.
First, let me give a formal lang spec in BNF for a simplifed lisp
syntax.
• The set of symbols are english letters a to z, and the parens “(”
and “)” and space “ ”.
• let's call the letters a to z as atoms, and denote it by α.
starting strings:
• α
• ()
transformation rules
• α → (α)
• (α) → (α α …)
• (α) → ((α))
That's it. Very simple.
Now, a lang can have such simple syntax, but usually such simple ones
are not useful, not expressive, hard to read. For example, assembly
langs. Or think of arithmetic with just “+”.
What we want is a rich syntax, but still regular with simple rules
(that can be specified by a formal language with just a few rules.) In
some sence, such syntax grammar is a systematic one.
I don't like the dwellers of comp.lang.lisp (they are idiots), because
lisp do have very simple syntax, yet it is totally irregular, yet the
typical lisp fans don't realize it almost in ANY WAY, but drivel all
day about sexp and macros and certain “code is data” fucking total
meaningless bizarre idea. (lisp macros is another major idiocy.)
as a example of the complexities of C-like syntax, let's have a peek
show:
i++
++i
for(;;){}
while(){}
0x123
expr1 ? expr2 : expr3
sprint(…%s,#@$#!%*&fuck@#)
Further readings:
• 〈Pattern Matching vs Lexical Grammar Specification〉
http://xahlee.org/cmaci/notation/pattern_matching_vs_pattern_spec.html
• 〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
• 〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html
• 〈Programing Language: Fundamental Problems of Lisp〉
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Btw, a little extra tip for my readers:
There is a confusion of the word “formal”. When people say “formal”,
as in “formal proof”, even mathematians, they usually mean “rigorous”.
Basically, they use the word “formal” as a synonym of “rigor”. (And
what's “rigorous” changes with time. Usually it just means the current
standard, accepted by other mathematicians.)
This is partly a abuse of language, partly a establish english usage
habit (called “phraseme”). Still, many mathematicians are ignorant of
“formal” in formal languages. In fact, many of them sneer at the idea
of David Hilbert's formalism or Bertrand Russel logicism, like idiots.
For more, see:
〈Math Notations, Computer Languages, and the “Form” in Formalism〉
http://xahlee.org/cmaci/notation/lang_notation_formalism.html
〈State Of Theorem Proving Systems 2008〉
http://xahlee.org/cmaci/notation/theorem_proving_systems.html
> Happy new year.
>
> RJF
Happy New Year to you too Richard!
Xah Lee
Dear Richard,
you are, perhaps the top 10 haters of Mathematica/Wolfram on this
earth. Me, is a dedicated lover of Mathematica, and actually i admire
Stephen Wolfram, his ideas, personality, too, in fact many of his
views, philosophies, are in alignment with my own. (one other guy i
could think of is Bertrand Russell)
Richard Fateman wrote:
> This is in contrast to "almost all computer languages" which DO have a
> syntax described in Backus-Naur Form.
Xah wrote:
> No they don't. Show me some. Let's say the most popular ones: java, c,
> c++, python, perl, php, html, xml.
> No they don't. Show me some. Let's say the most popular ones: java, c,
> c++, python, perl, php, html, xml.
Richard Fateman wrote:
> OK, I thought you had access to Google and could find these yourself..
>
> the C grammar is in
> Kernighan and Ritchie, The C Programming Language, App. A,
> the Java grammar is inhttp://java.sun.com/docs/books/jls/second_edition/html/syntax.doc.html
> OK, I thought you had access to Google and could find these yourself..
>
> the C grammar is in
> Kernighan and Ritchie, The C Programming Language, App. A,
> the Python grammar is inhttp://www.python.org/doc//current/reference/expressions.html
> C++ is probably in various places, includinghttp://www.nongnu.org/hcb/
>
> perl is, I think not amenable to systematic context-free description, in
> that it uses some odd tricks during lexical analysis. (As does
> Mathematica).
>
> html is not a programming language but a markup language; it is
> described formally not by bnf but by a formal SGML DTD.
>
> I'm not familiar enough with PHP to say anything about it except that
> from googling for its grammar, it seems to be a piece of malleable garbage..
>
> Other languages, like Algol-60, Pascal, FORTRAN, Basic, ... also have
> (annotated) formal syntax descriptions, typically available in any
> reference manual for them.
they have syntax spec in the same sense that there's syntax spec for
> perl is, I think not amenable to systematic context-free description, in
> that it uses some odd tricks during lexical analysis. (As does
> Mathematica).
>
> html is not a programming language but a markup language; it is
> described formally not by bnf but by a formal SGML DTD.
>
> I'm not familiar enough with PHP to say anything about it except that
> from googling for its grammar, it seems to be a piece of malleable garbage..
>
> Other languages, like Algol-60, Pascal, FORTRAN, Basic, ... also have
> (annotated) formal syntax descriptions, typically available in any
> reference manual for them.
english. Just read grammar books!
i didn't clarify myself before. Let me do now.
No major programing language in use has a formal grammar for their
syntax. By formal grammar, i mean a “formal language” (in the context
of symbolic logic. See http://en.wikipedia.org/wiki/Formal_language .
Parsing Expression Grammar would be a example of such formal
language).
In particular, let's look at 2 examples. Java and Python.
Neither have a FORMAL LANGUAGE spec of their syntax. Worse, both
their “spec” is not sufficient to implement the language, even just
the syntax part. The vast majority of “language spec” are like that.
They are more of “a guide to implementation”, and that's it.
Fateman wrote:
> (The term "regular" wrt syntax has a particular formal distinction).
> Sure, and i would ask you some questions about syntax, but given your
> known antagonism against Mathematica and Wolfram, am not sure i'd get
> answers that's unbiased and useful to me.
> Google is your friend. Look up "regular grammar" to find out about
> right and left linear grammars, for example.
there's a term for this idea, so i just say “my idea”. Actually i
should call it “systematic syntax”. That would be better than “regular
syntax”.)
The “systematic syntax” i have in mind is this:
• a language with a formal language spec of the syntax.
• this formal language spec, is “regular” in the sense that it is very
simple, perhaps just a handful of rules. As a example of opposite, you
could have a formal language spec for Java syntax, but that would be
tens or hundreds of pages.
Now, my claim about Mathematica is this: its syntax specified in a
general formal language would be very small, yet the syntax is very
rich. No other major lang comes close. (lisp would also have a very
simple syntax spec in formal lang, but its syntax isn't rich).
Now, we can discuss what is meant by “simple”.
First, let me give a formal lang spec in BNF for a simplifed lisp
syntax.
• The set of symbols are english letters a to z, and the parens “(”
and “)” and space “ ”.
• let's call the letters a to z as atoms, and denote it by α.
starting strings:
• α
• ()
transformation rules
• α → (α)
• (α) → (α α …)
• (α) → ((α))
That's it. Very simple.
Now, a lang can have such simple syntax, but usually such simple ones
are not useful, not expressive, hard to read. For example, assembly
langs. Or think of arithmetic with just “+”.
What we want is a rich syntax, but still regular with simple rules
(that can be specified by a formal language with just a few rules.) In
some sence, such syntax grammar is a systematic one.
I don't like the dwellers of comp.lang.lisp (they are idiots), because
lisp do have very simple syntax, yet it is totally irregular, yet the
typical lisp fans don't realize it almost in ANY WAY, but drivel all
day about sexp and macros and certain “code is data” fucking total
meaningless bizarre idea. (lisp macros is another major idiocy.)
as a example of the complexities of C-like syntax, let's have a peek
show:
i++
++i
for(;;){}
while(){}
0x123
expr1 ? expr2 : expr3
sprint(…%s,#@$#!%*&fuck@#)
Further readings:
• 〈Pattern Matching vs Lexical Grammar Specification〉
http://xahlee.org/cmaci/notation/pattern_matching_vs_pattern_spec.html
• 〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
• 〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html
• 〈Programing Language: Fundamental Problems of Lisp〉
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Btw, a little extra tip for my readers:
There is a confusion of the word “formal”. When people say “formal”,
as in “formal proof”, even mathematians, they usually mean “rigorous”.
Basically, they use the word “formal” as a synonym of “rigor”. (And
what's “rigorous” changes with time. Usually it just means the current
standard, accepted by other mathematicians.)
This is partly a abuse of language, partly a establish english usage
habit (called “phraseme”). Still, many mathematicians are ignorant of
“formal” in formal languages. In fact, many of them sneer at the idea
of David Hilbert's formalism or Bertrand Russel logicism, like idiots.
For more, see:
〈Math Notations, Computer Languages, and the “Form” in Formalism〉
http://xahlee.org/cmaci/notation/lang_notation_formalism.html
〈State Of Theorem Proving Systems 2008〉
http://xahlee.org/cmaci/notation/theorem_proving_systems.html
> Happy new year.
>
> RJF
Happy New Year to you too Richard!
Xah Lee
Don Geddis
Dec 30, 2011, 9:22:39 PM12/30/11
to
Xah Lee <xah...@gmail.com> wrote on Fri, 30 Dec 2011:
> What we want is a rich syntax, but still regular with simple rules
> (that can be specified by a formal language with just a few rules.)
Why is that an interesting goal, in the design of a programming
> What we want is a rich syntax, but still regular with simple rules
> (that can be specified by a formal language with just a few rules.)
language?
You appear to have just made up a random property, but not provided any
motivation for why anyone ought to care.
> I don't like the dwellers of comp.lang.lisp (they are idiots)
"I'm rubber and you're glue ... it bounces off me and sticks to you."
Just curious: are you yourself a member of the set of dwellers of c.l.l?
Are you in the set of all sets that do not contain themselves?
> Still, many mathematicians are ignorant of "formal" in formal
> languages. In fact, many of them sneer at the idea of David Hilbert's
> formalism or Bertrand Russel logicism, like idiots.
But perhaps your mathematical education and understanding never
progressed much beyond the early 1900's...
Hint: the last century has been a pretty exciting time in the field of
mathematics!
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
My parents put us to sleep by tossing us up in the air. Of course, you
have to have low ceilings for this method to work.
Harald Hanche-Olsen
Dec 31, 2011, 4:04:41 AM12/31/11
to
[Xah Lee <xah...@gmail.com>]
> There is a confusion of the word “formal”.
Agreed.
> When people say “formal”,
> as in “formal proof”, even mathematians, they usually mean “rigorous”.
Nope. Whenever I see mathematicians use the phrase “formal proof”, they
mean a proof by performing formula manipulations /without/ paying
attention to rigour. Like, for example, interchanging the order of
integration in a double integral without checking to see if the
conditions for using the Fubini (or Tonelli) theorem hold.
It used to confuse me too, until I caught onto the normal usage.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
> There is a confusion of the word “formal”.
> When people say “formal”,
> as in “formal proof”, even mathematians, they usually mean “rigorous”.
mean a proof by performing formula manipulations /without/ paying
attention to rigour. Like, for example, interchanging the order of
integration in a double integral without checking to see if the
conditions for using the Fubini (or Tonelli) theorem hold.
It used to confuse me too, until I caught onto the normal usage.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Richard Fateman
Dec 31, 2011, 12:20:14 PM12/31/11
to
On 12/30/2011 12:30 PM, Xah Lee wrote:
> 2011-12-28
>
> Dear Richard,
>
> you are, perhaps the top 10 haters of Mathematica/Wolfram on this
> earth.
I didn't know there was a rating service for this.
> 2011-12-28
>
> Dear Richard,
>
> you are, perhaps the top 10 haters of Mathematica/Wolfram on this
> earth.
I would prefer to categorize my attitude towards Mathematica as
rationally critical of its faults, and disdainful of its hype.
After all, I have a paper on my web site suggesting improvements
to (for example) its rule processing, and an implementation of its
evaluator and matcher in lisp.
I think that my view of Dr. Wolfram is pretty much irrelevant to
a discussion of Mathematica's design unless one can in particular
pin a design failure to Wolfram himself rather than someone else.
> Me, is a dedicated lover of Mathematica, and actually i admire
> Stephen Wolfram, his ideas, personality, too, in fact many of his
> views, philosophies, are in alignment with my own. (one other guy i
> could think of is Bertrand Russell)
Wolfram. Maybe you should check out Isaac Newton.
>
> Richard Fateman wrote:
>> This is in contrast to "almost all computer languages" which DO have a
>> syntax described in Backus-Naur Form.
... snip
> Richard Fateman wrote:
>> This is in contrast to "almost all computer languages" which DO have a
>> syntax described in Backus-Naur Form.
>>
>> (RF) Other languages, like Algol-60, Pascal, FORTRAN, Basic, ... also have
>> (annotated) formal syntax descriptions, typically available in any
>> reference manual for them.
>
> (XL) they have syntax spec in the same sense that there's syntax spec for
>> reference manual for them.
>
> english. Just read grammar books!
no, some grammar specification for English does not define English. It
attempts to explain it, in part.
>
> i didn't clarify myself before. Let me do now.
>
> No major programing language in use has a formal grammar for their
> syntax. By formal grammar, i mean a “formal language” (in the context
> of symbolic logic. See http://en.wikipedia.org/wiki/Formal_language .
> Parsing Expression Grammar would be a example of such formal
> language).
>
> In particular, let's look at 2 examples. Java and Python.
>
> Neither have a FORMAL LANGUAGE spec of their syntax. Worse, both
> their “spec” is not sufficient to implement the language, even just
> the syntax part. The vast majority of “language spec” are like that.
> They are more of “a guide to implementation”, and that's it.
You are requiring that the syntax document also specify the SEMANTICS.
> i didn't clarify myself before. Let me do now.
>
> No major programing language in use has a formal grammar for their
> syntax. By formal grammar, i mean a “formal language” (in the context
> of symbolic logic. See http://en.wikipedia.org/wiki/Formal_language .
> Parsing Expression Grammar would be a example of such formal
> language).
>
> In particular, let's look at 2 examples. Java and Python.
>
> Neither have a FORMAL LANGUAGE spec of their syntax. Worse, both
> their “spec” is not sufficient to implement the language, even just
> the syntax part. The vast majority of “language spec” are like that.
> They are more of “a guide to implementation”, and that's it.
This is not the point here. Mathematica has no BNF in its
documentation. Contrast that with Java, Python, etc.
Formal specification (to the level of making an implementation a trivial
"parsing" of the specification itself) of a programming language is
rarely pursued in theory, and (I suspect) never in practice.
>
> Fateman wrote:
>> (The term "regular" wrt syntax has a particular formal distinction).
>> Sure, and i would ask you some questions about syntax, but given your
>> known antagonism against Mathematica and Wolfram, am not sure i'd get
>> answers that's unbiased and useful to me.
>
>> Google is your friend. Look up "regular grammar" to find out about
>> right and left linear grammars, for example.
>
> Now, let me discuss my idea about “regular syntax”. (i don't know if
> there's a term for this idea, so i just say “my idea”. Actually i
> should call it “systematic syntax”. That would be better than “regular
> syntax”.)
You should certainly use a different term than "regular syntax".
> Fateman wrote:
>> (The term "regular" wrt syntax has a particular formal distinction).
>> Sure, and i would ask you some questions about syntax, but given your
>> known antagonism against Mathematica and Wolfram, am not sure i'd get
>> answers that's unbiased and useful to me.
>
>> Google is your friend. Look up "regular grammar" to find out about
>> right and left linear grammars, for example.
>
> Now, let me discuss my idea about “regular syntax”. (i don't know if
> there's a term for this idea, so i just say “my idea”. Actually i
> should call it “systematic syntax”. That would be better than “regular
> syntax”.)
>
> The “systematic syntax” i have in mind is this:
>
> • a language with a formal language spec of the syntax.
>
> • this formal language spec, is “regular” in the sense that it is very
> simple, perhaps just a handful of rules. As a example of opposite, you
> could have a formal language spec for Java syntax, but that would be
> tens or hundreds of pages.
trivial. Formal specification of programming languages is not unknown,
in theory.
>
> Now, my claim about Mathematica is this: its syntax specified in a
> general formal language would be very small, yet the syntax is very
> rich.
and (b) is very small?
No other major lang comes close. (lisp would also have a very
> simple syntax spec in formal lang, but its syntax isn't rich).
Google "context free", "context sensitive" for a start.
>
> Now, we can discuss what is meant by “simple”.
>
> First, let me give a formal lang spec in BNF for a simplifed lisp
> syntax.
>
> • The set of symbols are english letters a to z, and the parens “(”
> and “)” and space “ ”.
>
> • let's call the letters a to z as atoms, and denote it by α.
>
> starting strings:
>
> • α
> • ()
>
> transformation rules
>
> • α → (α)
> • (α) → (α α …)
> • (α) → ((α))
>
> That's it. Very simple.
Elaboration. Your "system" cannot generate (a b () c).
Rules in BNF can only have single symbols on the left hand side.
Now you are free to require context sensitive rules in YOUR "system"
but be warned that people who have studied such things for, oh, 60
or 70 years think that is not a good idea unless you really really
need it.
>
> Now, a lang can have such simple syntax, but usually such simple ones
> are not useful, not expressive, hard to read. For example, assembly
> langs. Or think of arithmetic with just “+”.
>
> What we want is a rich syntax, but still regular with simple rules
> (that can be specified by a formal language with just a few rules.) In
> some sence, such syntax grammar is a systematic one.
You haven't defined rich OR regular OR simple OR expressive OR formal or
> Now, a lang can have such simple syntax, but usually such simple ones
> are not useful, not expressive, hard to read. For example, assembly
> langs. Or think of arithmetic with just “+”.
>
> What we want is a rich syntax, but still regular with simple rules
> (that can be specified by a formal language with just a few rules.) In
> some sence, such syntax grammar is a systematic one.
for that matter, what you mean by grammar.
>
> I don't like the dwellers of comp.lang.lisp (they are idiots),
let's not talk about them, let's talk about what you are saying..
>
> as a example of the complexities of C-like syntax, let's have a peek
> show:
>
> i++
> ++i
> for(;;){}
> while(){}
> 0x123
> expr1 ? expr2 : expr3
> sprint(…%s,#@$#!%*&fuck@#)
some sort asking what is the longest string of (non repeating) operators
possible that has a meaning in Mathematica. e.g. symbols like
_@?!+%*. I can't spot it via Google, but I think that the length
exceeded 12. I described the Mathematica shorthand syntax as "runic".
..snip...
>
> Btw, a little extra tip for my readers:
>
> There is a confusion of the word “formal”. When people say “formal”,
> as in “formal proof”, even mathematians, they usually mean “rigorous”.
> Basically, they use the word “formal” as a synonym of “rigor”. (And
> what's “rigorous” changes with time. Usually it just means the current
> standard, accepted by other mathematicians.)
I think you have to define "people" here. Computer scientists have a
> Btw, a little extra tip for my readers:
>
> There is a confusion of the word “formal”. When people say “formal”,
> as in “formal proof”, even mathematians, they usually mean “rigorous”.
> Basically, they use the word “formal” as a synonym of “rigor”. (And
> what's “rigorous” changes with time. Usually it just means the current
> standard, accepted by other mathematicians.)
notion of a formal grammar. You are not really free to redefine it
in that context.
>
> This is partly a abuse of language, partly a establish english usage
> habit (called “phraseme”). Still, many mathematicians are ignorant of
> “formal” in formal languages. In fact, many of them sneer at the idea
> of David Hilbert's formalism or Bertrand Russel logicism, like idiots.
I like the image of mathematicians sneering. Do they do that a lot?
> This is partly a abuse of language, partly a establish english usage
> habit (called “phraseme”). Still, many mathematicians are ignorant of
> “formal” in formal languages. In fact, many of them sneer at the idea
> of David Hilbert's formalism or Bertrand Russel logicism, like idiots.
WJ
Jan 24, 2013, 11:30:01 PM1/24/13
to
Krzysztof Drewniak wrote:
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
>
> If the lambda needs to take something other then one requires argument,
> parentheses are needed around the first expression, which is the lambda
> list. For example:
>
> #L((x y) (expt x y))
>
> #L((&rest elms) (reverse elms))
>
> Here's the implementation:
>
> (set-dispatch-macro-character
> #\# #\L
> #'(lambda (stream char1 char2)
> (let ((l-form (read stream t nil t)))
> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
> (apply #'list 'lambda l-form))))
Bigloo:
> I have created a new reader macro to make writing lambda-heavy code less
> cumbersome. Code that used mapcar and friends a lot tends to include
> many instances of:
>
> (lambda (x) (frob x))
>
> My macro reduced the amount of typing needed to get a lambda function.
> Instead of writing (lambda (x) ...), one writes
>
> #L(x [code that uses x])
>
> If the lambda needs to take something other then one requires argument,
> parentheses are needed around the first expression, which is the lambda
> list. For example:
>
> #L((x y) (expt x y))
>
> #L((&rest elms) (reverse elms))
>
> Here's the implementation:
>
> (set-dispatch-macro-character
> #\# #\L
> #'(lambda (stream char1 char2)
> (let ((l-form (read stream t nil t)))
> (when (symbolp (car l-form)) (setf (car l-form) (list (car l-form))))
> (apply #'list 'lambda l-form))))
(define-macro ($ . exprs) `(lambda (%) ,exprs))
(define-macro ($$ . exprs) `(lambda (%1 %2) ,exprs))
1:=> (map ($ * % %) '(1 2 3 4))
(1 4 9 16)
1:=> (map ($$ min %1 %2) (iota 9) (reverse (iota 9)))
(0 1 2 3 4 3 2 1 0)
smh
Jan 26, 2013, 1:48:57 AM1/26/13
to
Two remarks, one semi serious, and one genuinely serious.
If you have devised an extended syntax, and implicitly proposed its general adoption, have you also devised some pprint-dispatch entries which can reliably reverse this reader macrology, so programming tools will remain transparently comprehensible to poor ignorant programmers?
Now the more serious comment, which has two parts.
The great Kent Pitman used to comment that it is not only important for languages to have portable implementations; it is even more important that programmers be portable across mainline implementations of a language. (BTW, I'm the guy formerly of X3J13 who hired Kent to finish the ANS for CL, and figured out the several "open source" industry contracts to fund his work, and which made the text of the ANS publicly available so that Kent was able to create the Hyperspec.
That means that while CL with its mutable reader syntax and powerful macro facilities allows a programmer do redefine the language to look syntactically like almost anything, this isn't necessarily a good thing. After you've quit programming and become a punk guitarist, somebody else might be called upon to read and maintain your code. Writing in the lingua franca is important, because that facilitates your follower being able to do that job. Facile readability is in the long run more important than facile writability.
Less obvious, but more important, is the issue of macros. Sometimes it is said that Lisp is characterized by 5 characteristic, possession about 4 of which qualifies a language to be considered a Lisp. I'll leave the other four for extra credit, but one is the syntactic representation of code parse trees in the same language as code. That means that a human (or a macro, or a macro^2) trying to code a macro can easily pattern match (aka "destructure") the input form (which is a sexpr tree). Many years ago marketing pressures to use hoi polloi C syntax prevented the very promising Lisp dialect called Dylan from having macros. That became a failed language. The same mistaek was committed by the designers of Java, which has become another failed language. (Curiously, many of the designers of Java were aging lispers.) Lack of usable macros means that the language wasn't expressive enough for real programmers to get work done.
Powerful, _recurively_ powerful macros require the input syntax and output syntax be the same. Lisp's got that. Other languages don't/
In standard CL reader syntax, the only reader macros (outside syntax for various constants) that are not isomorphic to cons trees are the reader macros for quote and function (' and #'). IMO that's about the optimal operating point.
If you have devised an extended syntax, and implicitly proposed its general adoption, have you also devised some pprint-dispatch entries which can reliably reverse this reader macrology, so programming tools will remain transparently comprehensible to poor ignorant programmers?
Now the more serious comment, which has two parts.
The great Kent Pitman used to comment that it is not only important for languages to have portable implementations; it is even more important that programmers be portable across mainline implementations of a language. (BTW, I'm the guy formerly of X3J13 who hired Kent to finish the ANS for CL, and figured out the several "open source" industry contracts to fund his work, and which made the text of the ANS publicly available so that Kent was able to create the Hyperspec.
That means that while CL with its mutable reader syntax and powerful macro facilities allows a programmer do redefine the language to look syntactically like almost anything, this isn't necessarily a good thing. After you've quit programming and become a punk guitarist, somebody else might be called upon to read and maintain your code. Writing in the lingua franca is important, because that facilitates your follower being able to do that job. Facile readability is in the long run more important than facile writability.
Less obvious, but more important, is the issue of macros. Sometimes it is said that Lisp is characterized by 5 characteristic, possession about 4 of which qualifies a language to be considered a Lisp. I'll leave the other four for extra credit, but one is the syntactic representation of code parse trees in the same language as code. That means that a human (or a macro, or a macro^2) trying to code a macro can easily pattern match (aka "destructure") the input form (which is a sexpr tree). Many years ago marketing pressures to use hoi polloi C syntax prevented the very promising Lisp dialect called Dylan from having macros. That became a failed language. The same mistaek was committed by the designers of Java, which has become another failed language. (Curiously, many of the designers of Java were aging lispers.) Lack of usable macros means that the language wasn't expressive enough for real programmers to get work done.
Powerful, _recurively_ powerful macros require the input syntax and output syntax be the same. Lisp's got that. Other languages don't/
In standard CL reader syntax, the only reader macros (outside syntax for various constants) that are not isomorphic to cons trees are the reader macros for quote and function (' and #'). IMO that's about the optimal operating point.
Norbert_Paul
Jan 27, 2013, 6:38:35 AM1/27/13
to
smh wrote:
> Less obvious, but more important, is the issue of macros. Sometimes it is said that Lisp is characterized by 5 characteristic, possession about 4 of which qualifies a language to be considered a Lisp. I'll leave the other four for extra credit, but one is the syntactic representation of code parse trees in the same language as code. That means that a human (or a macro, or a macro^2) trying to code a macro can easily pattern match (aka "destructure") the input form (which is a sexpr tree). Many years ago marketing pressures to use hoi polloi C syntax prevented the very promising Lisp dialect called Dylan from having macros. That became a failed language. The same mistaek was committed by the designers of Java, which has become another failed language. (Curiously, many of the designers of Java were aging lispers.) Lack of usable macros means that the language wasn't expressive enough for real programmers to get work done.
I am just curious. What exactly do you mean by "failed"?
> Less obvious, but more important, is the issue of macros. Sometimes it is said that Lisp is characterized by 5 characteristic, possession about 4 of which qualifies a language to be considered a Lisp. I'll leave the other four for extra credit, but one is the syntactic representation of code parse trees in the same language as code. That means that a human (or a macro, or a macro^2) trying to code a macro can easily pattern match (aka "destructure") the input form (which is a sexpr tree). Many years ago marketing pressures to use hoi polloi C syntax prevented the very promising Lisp dialect called Dylan from having macros. That became a failed language. The same mistaek was committed by the designers of Java, which has become another failed language. (Curiously, many of the designers of Java were aging lispers.) Lack of usable macros means that the language wasn't expressive enough for real programmers to get work done.
When you consider Java "failed" then lack of popularity
cannot characterize failure.
smh
Jan 27, 2013, 9:30:45 PM1/27/13
to
> When you consider Java "failed" then lack of popularity cannot characterize failure.
On Sunday, January 27, 2013 3:38:35 AM UTC-8, Norbert_Paul wrote:
> I am just curious. What exactly do you mean by "failed"?
> When you consider Java "failed" then lack of popularity
> cannot characterize failure.
I described Java as a "failed language" with the intention of yanking a few Java-fan tails, in which I have apparently succeeded. Now, Java is a pretty good language with lots of admirable qualities. (Many of which are inherited from Lisp -- Java is almost a Lisp, but I digress.) I really do respect the designers. But when Java was originally thrust upon the computing world is had at least these two objectives: It would be "write once and run anywhere"; and it would be safe to run downloaded rogue code, since sandboxes and access permissions where strictly managed.
> I am just curious. What exactly do you mean by "failed"?
> When you consider Java "failed" then lack of popularity
> cannot characterize failure.
I don't have enough industry knowledge to know whether the first of these claims has been achieved. I could accept that any specific failures are mere implementation glitches that could and should be corrected. But the second of these claims is manifestly a failure. Note the recent advice from DHS to disable Java in browsers, owing to a vulnerability that Oracle (previously known as Sun Microsystems) knew about for many months but failed to fix. Lots of other references on the web, but you can start here:
http://www.csmonitor.com/Business/2013/0112/Disable-Java-Here-s-how-after-US-agency-warns-of-software-vulnerability.
Nearly every technically proficient person in my company has disabled Java in their browsers, and curiously, almost nothing in normal browsing depends upon Java. On both of these counts, Java can be consideed a "failed language" having failed to achieve its stated design goals Those two reasons, plus the lack of macros... :-)
I'll admit to being a little severe and provocative in my opinions above -- I do respect the goals Java tried to achieve, and the admiable progress achieved -- but this is a good way to make proponents of that other failed language Lisp feel a lot better, and a good way to start a nice flame war.
Norbert_Paul
Jan 28, 2013, 3:55:20 AM1/28/13
to
\begin{definition}[Failure of a Laguage]
Let $L$ be a programming language and $X$ be the design expectations
of $L$. Then we call $L$ \emph{failed} (relative to $X$), iff $L$ does
not meet all of $X$. We then denote failure of $L$ relative to $X$ by
$L \ddot\smile X$.
\end{definition}
\begin{lemma}
From $L \ddot\smile X$ immediately follows that the tails of all members
of the set $\fans(L)$ get yanked successfully.
\end{lemma}
Did I get this correctly?
$\ddot\smile$
WJ
Dec 4, 2014, 1:41:18 AM12/4/14
to
gosh> (map (^(a b) (* a b (+ a b))) (iota 9) (reverse (iota 9)))
(0 56 96 120 128 120 96 56 0)
0 new messages