Re: "Self-Segregating Syntax"?
From: | Simon Clarkstone <simon.clarkstone@...> |
Date: | Saturday, April 22, 2006, 18:07 |
On 4/20/06, Eldin Raigmore <eldin_raigmore@...> wrote:
> On Thu, 20 Apr 2006 16:14:28 +0100, Simon Clarkstone
> <simon.clarkstone@...> wrote:
> >Well, I have been pondering
> >a bracket-type scheme (see LISP), and
> >a SADOL-type scheme (3a, I believe).
> >My experience with
> >algebra,
> >the Haskell $ operator
> >and
> >curried functions,
> >knowledge of
> >forks in J
> >(
http://www.jsoftware.com/books/help/dictionary/intro05.htm),
> >and the meaning of
> >[] in some dialects of LISP,
> >leads me to believe that a slightly ad-hoc system would be best, with
> >short, irregular ways to specify the common cases, and a more complete way
> >that can specify anything.
>
> Thanks.
>
> I have some questions.
I shouldn't have written taht email so late at night.
>
> 1. What does "a bracket-type scheme (see LISP)" mean? I thought I knew
> what brackets are, and I've done _some_ LISP (actually MACSYMA rather than
> LISP proper); but I'm not positive what you mean.
I simply mean that you specify the tree structure with nested
brackets. In LISP, the notation (A B C D) is a tree with the head
node labled A and subtrees of B, C, and D. In LISP, function calls
are written as a tree with the function at its head and all the
arguments as the direct children. For example, you could check to see
if the number X is a solution to the equation ax²+bx+c=0 with the
expression (= 0 (+ (* A X X) (* B X) C)), which returns true if it X a
solution and false if not. The most important point of LISP is that
programs and data are both trees, so macros can manipulate programs
easily and powerfully, with the full power of LISP (unlike, say, the C
pre-processor).
> 2. What does "a SADOL-type scheme" mean? I've never heard of SADOL
> before. Looking it up in Google doesn't give me any programming languages
> among the first 10 hits; is it a programming language?
Yes, but a slightly silly one. Every token is a single character, and
most take a fixed number of arguments. The few that take variable
numbers of arguments need a number as their first argument to say how
many others there are. The effect is rather like Plan B, but not
regular. SADOL tends to look like line noise, which I suppose was the
point.
>
> 3. At least I know what "algebra" means; so I guess this really isn't a
> question, is it?
Yes.
>
> 4. What is "the Haskell $ operator"? (And who was Haskell?)
> (partial answer: Haskell is a programming language named after logician
> Haskell B. Curry. The $ operator is some operator in this language, but
> I'm not sure how you meant it to apply to this thread.)
(Note here that Haskell expressions often evaluate to functions, and a
function is "applied" to its arguments.)
$ is simply function application. Although the $ seems useless
initially, it is an operator with very low precedence (it is "done
after everything else") unlike function application, which has high
precedence ("done first"). So, a set of expressions seperated by $
signs will be each be evaluated, then the results applied together,
starting from the right. E.g. "a b $ c d e $ f g h" evaluates "a b",
"c d e", and "f g h", then applies the second to the third, and the
first to the result of that.
Normally, to apply the function f to the argument x, you write "f x".
You could also write "f $ x", where $ acts as an operator taking f and
x in and applying the one to the other, but the $ is not necessary
here. If you want to apply the function g to the result of applying f
to x, you might write "g (f x)", but the normal way to write it is "g
$ f x". In either case, first "g" is evaluated (it just comes out to
g) and "f x" (applies f to x), then the one is applied to the other.
If you wrote "g f x", you would probably get a type error, as that
applies g to f, then the result of that to x. $ can't be used to
arrange very complicated expressions, but it is fine, and clearer than
brackets, for the most common cases.
>
> 5. What are "curried functions"? (Does this have anything to do with Hilary
> F.B. Curry (if I got the name right, which seems doubtful)? Or Haskell
> Brooks Curry, whoever he was?)
> (partial answer; a "curried function" is (one of a set of examples of)
> function(s) which return(s) a function as a value.
> For instance if there is a function f(x,y), and G is "curried f", then for
> each x the value of G(x) will be the function g such that for each y,
> g(y)=f(x,y).
> In general "curried f" takes only the first argument of f as its argument,
> and returns as a value a function taking the remaining arguments of f.
> This looks like it fits into Categorial Grammar quite well; and also into
> the C programming languages type-building scheme. So it seems it might be
> attractive to me.
> But how, exactly, did you mean it to be applied to this thread?)
A curried function is one that takes an argument and returns a
function that takes another argument, which returns a function that
takes a third argument, and so on until the final result is returned.
This is a very powerful technique, and a Haskell program will often
use it several times on a line. In Haskell, functions are normally
curried. (I would provide an example of evaluation, but since the
intermediate values re functions, it would be messy and not useful for
understanding.) Precedence means that expressions like "foo 42
[1,2,3] 'a'" are parsed as "(((foo 42) [1,2,3]) 'a')".
>
> BTW I like Indian cooking, especially South Indian cooking. But if I take
> printouts of the functions I've written and curry them, they're still not
> as appetizing as curried beef or curried chicken.
:-)
>
> 6. "forks in J"
>
http://www.jsoftware.com/books/help/dictionary/intro05.htm
> I have no previous exposure to the J programming language. I read the htm
> document referred to by the above URL; but it did not explain to me what
> you expected it to; I suppose I need to start earlier in the website.
> The "forks" look like I'd probably be interested in them if I understood
> them.
> What did you mean to apply from that notion to the subject of "self-
> segregating syntax"?
Forks are another example of a notation that isn't regular, but covers
most common cases simply. For example, the expression:
+/ % # 1 2 3 4 5
consists of the fork +/ % # and the list 1 2 3 4 5
this means to find the sum of the list ("+/"), and also find the
lenght of the list ("#"), then divide the one by the other ("%"). A
less neat way to write it would be:
(+/ 1 2 3 4 5) % (# 1 2 3 4 5)
+/ % # finds the mean of the following list.
>
> 7. What does "[]" mean in the "dialects of LISP" to which you refer? How
> is that different from its meaning in other dialects of LISP? Perhaps I
> don't have enough _direct_ knowledge of LISP _proper_ for your intent to be
> obvious to me.
In some older dialects of LISP, [] were like super-brackets. ] would
acts as one or more backets, enough to match all the way back to the
beginning of the expression, or the matching [. This is another
irregular trick that covers most of the common cases, as LISP
expressions and sometimes sub-expressions tend to end in ")))))))",
due to heavy nesting. [] were meant to make this easier on the eye.