Why?

Post #3,426 by ChrisR 8/1/01 11:29:48 AM Reply	Why? IOW, very LISP-like, but move the operation name outside the parenths. Everything in Lisp is a List or an operation on a list. This flexibility means that the distinction between functions and data is very gray, providing a maximally extensive language. From the standpoint of what you are proposing, I don't see the advantage yet. All I see is a rearrangement of syntactical structure. What does the rearrangement buy me in terms of flexibility or extendibility?
Post #3,439 by tablizer 8/1/01 12:39:34 PM Reply	not the full story >> From the standpoint of what you are proposing, I don't see the advantage yet. All I see is a rearrangement of syntactical structure [from LISP]. << I prefer the name on the outside. It is more natural IMO. Besides, there are other features of the language that are not in LISP (such as named-parameters and dot-based dictionary arrays) or are in LISP but not needed because they are done a different way. ________________ oop.ismad.com
Post #3,477 by ChrisR 8/1/01 3:54:11 PM Reply	Not a contest with Lisp It's best to remember that Lisp is over 40 years old and is still a language that can do things that surpass any modern language. The syntax may not be to your liking, but there are reasons for that syntax that make the language capable of being used for practically any programming paradigm ever invented. As I said, Lisp uses the idea of Lists and Operations on Lists, as well as the idea of Lists of Operations on Lists. It has an internal consistency that pays dividends in terms of flexibility. Again, the question is not a matter of tastes - it's a question of why? Why are you proposing the layout that you are proposing? What does it buy me in terms of flexibility/extendibility? I'm not saying that it might not be nice. I am just asking you to explain the reason you consider it to be important.
Post #3,641 by Fearless Freep 8/2/01 3:48:52 PM Reply	Guessing but... I'm not saying that it might not be nice. I am just asking you to explain the reason you consider it to be important I suspect he thinks it will be easier to write a language parser that follows one basic syntactical idiom. If you can phrase x < 2 as cmp (x, "<", 2) than everything can be parsed as function (arguments) in a rather iterative fashion Jay O'Connor "Going places unmapped to do things unplanned to people unsuspecting"
Post #3,649 by ChrisR 8/2/01 6:09:41 PM Reply	I doubt it... I suspect he thinks it will be easier to write a language parser that follows one basic syntactical idiom. I doubt that for two reasons. First, Bryce has been vocal in his opposition to any language feature that is done for the purpose of making parsing easier. Second, I have my doubts about whether Bryce ever intends to write a parser, so I wouldn't think he's too concerned with parsing issues. I guess while we're on the subject, I might as well ask how the syntax lays out when the number of parameters is not 2. What does the syntax do when there is only a single parameter? What does the syntax do when there are three or more parameters? Haskell gets away with it by stipulating that all functions take only a single parameter. Additional parameters are Curried in functions that also take a single argument. Python, OTOH, always takes a single parameter, but the parameter may be a tuple which allows multiple parameter to be group together as a single parameter.
Post #3,689 by tablizer 8/3/01 1:40:15 AM Reply	not true >> First, Bryce has been vocal in his opposition to any language feature that is done for the purpose of making parsing easier. << Like I said before, this is only a proof of concept, and NOT a final version by any long-shot. >> Second, I have my doubts about whether Bryce ever intends to write a parser, so I wouldn't think he's too concerned with parsing issues. << That is what you guys said about a runnable SCGUI browser, and I made one. Anybody is welcome to try it. ( [link\|http://www.geocities.com/tablizer/scgui.htm\|http://www.geocitie...er/scgui.htm] ) >> I guess while we're on the subject, I might as well ask how the syntax lays out when the number of parameters is not 2. << I don't see why that would be a problem. x() x(p1) x(p1 p2 p3) (I wont go into named parameters here) ________________ oop.ismad.com
Post #3,692 by CRConrad 8/3/01 2:32:03 AM Reply	Yes, he's been vocal - but then, he wasn't writing a parser!
Post #3,739 by tablizer 8/3/01 12:54:34 PM Reply	A "walk a mile in another's compiler" argument? I still say that being programmer-friendly is more important than being compiler-friendly. However, a hobby test project does not have that luxury, and may have to bend toward keeping the compiler/interpreter simple at the expense of some syntactical niceties. IOW, you are comparing the standards for apples to the standards for orangees. If the early draft for PHB had dollar signs, that would not bother me because I would not use it at that stage. But BY NOW those fricken dollars should be long gone (except for embedding variables in strings, where they make sense). ________________ oop.ismad.com
Post #3,771 by tablizer 8/3/01 3:42:31 PM Reply	(addendum) BTW, I plan to incrementally extend the syntax to make it friendlier. The "base" may be purely function-based, but extended from there. One approach is to simply gradually add more complex syntax to the parser. Another is to have a pre-compiler convert the "friendly" version into the function-only version. I have not decided that yet which path to follow. ________________ oop.ismad.com

Welcome to IWETHEY!