Theiling Online    Sitemap    Conlang Mailing List HQ   

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.