Re: Another SQL Puzzle

Post #208,883 by ChrisR 5/27/05 9:38:21 PM 5/27/05 9:50:17 PM Reply	Re: Another SQL Puzzle SELECT\ncolumn_A,\n(CASE column_A WHEN 0 THEN 0 ELSE 1 END) as bar\nFROM fooTable or alternately: SELECT\ncolumn_A,\n(CASE WHEN (column_A = 0) THEN 0 ELSE 1 END) as bar\nFROM fooTable [edit note: forgot the when] Edited by ChrisR May 27, 2005, 09:50:17 PM EDT Expand All History
Post #209,124 by tablizer 5/31/05 1:18:06 AM Reply	Hmmm. Standard? ________________ oop.ismad.com
Post #209,154 by tuberculosis 5/31/05 10:35:29 AM 8/21/07 5:44:10 AM Reply	No such thing in SQL world - dialects everywhere "Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein "This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush Edited by tuberculosis Aug. 21, 2007, 05:44:10 AM EDT Expand All History
Post #209,711 by tablizer 6/2/05 8:41:49 PM Reply	Good point. Standard != Common_Implementation (rant-brag) Now if the world went with my (draft) query language, missing features could be DBA-written because the language is 20x simpler than SQL. Everything, except possibly Boolean expressions, are function-like. Adding a new "function" is not the same as adding new syntax. It is equiv to adding a new library function, not changing the lang itself. (/rant-brag) ________________ oop.ismad.com
Post #209,717 by ben_tilly 6/2/05 9:24:29 PM Reply	Lemme guess... Your new query language is procedural and Turing complete, hence complex queries cannot be decently optimized, and therefore you lose the entire point of SQL. Furthermore you don't understand why any of this is a bad thing. Any guesses as to whether I am right? Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #209,728 by ChrisR 6/2/05 10:27:30 PM Reply	The best way to fix non-standard implementations.... ...is to go with a language that has no formal notion of operational, denotational or axiomatic semantics, and has no current implementation to fetter our optimism. Fiat will sort out the rest!
Post #209,739 by static 6/2/05 11:25:00 PM Reply	I had a look. You're correct. His writing shows he doesn't understand why SQL is non-procedural and not Turing-complete. His criticisms of SQL stem from exactly that lack. Wade. Save Fintlewoodlewix
Post #209,745 by ben_tilly 6/3/05 12:27:31 AM Reply	Fish in a barrel I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #211,826 by tablizer 6/20/05 8:55:05 PM Reply	Please be more specific ________________ oop.ismad.com
Post #211,827 by broomberg 6/20/05 9:09:47 PM Reply	Horse corpse - meet Mr. Stick
Post #211,828 by tablizer 6/20/05 9:20:14 PM Reply	IOW, guilty until proven innocent. IranWeThey Just point to the passage that allegedly exposed me as being declaratively ignorant. ________________ oop.ismad.com
Post #211,837 by static 6/20/05 9:44:01 PM Reply	Sorry, I've got real SQL work to do. Save Fintlewoodlewix
Post #211,876 by tablizer 6/21/05 2:16:46 AM 6/21/05 2:18:03 AM Reply	SQL sucks (as a relational language) I remember about 6 years ago I was in a huge debate with the Iwethey croud where I claimed cursor-oriented (semi-procedural) database manipulation was "better" because it closer fit the way (most) humans think. Others complained about such approach not being machine-optimizable because it loses its "mathability". My POV was that being human-friendly was more important than auto-optimization. (Many OO'ers even say they want to "wrap the persistence mechanism[1] and ugly SQL strings" to avoid having to deal with SQL.) After thinking long and hard, I decided that the "anti-imperative" people were generally right. However, what sold me was that I realized SQL sucks as a relational language. It is not relational algebra itself that is necessarily human-unfriendly, it is SQL's view of it. Thus, I set out to create what I feel would be a more human-friendly (and meta-friendly) relational language that allows one to better decompose big problems into many smaller ones and reference the parts by names instead of the run-on nesting of SQL. SQL is fine for small, simple queries, but gets ugly real fast as things get trickier. [1] RDBMS are far more than just about "persistence". ________________ oop.ismad.com Edited by tablizer June 21, 2005, 02:18:03 AM EDT Expand All History
Post #211,904 by ChrisR 6/21/05 10:39:45 AM Reply	Perhaps you need to get out of the design and... ...into the implementation phase. Either that, or convince Date & Darwin that your pet language is the way to go.
Post #211,954 by tablizer 6/21/05 3:06:20 PM Reply	Some convergence perhaps Re: Either that, or convince Date & Darwin that your pet language is the way to go. Date and I chose [infix] because we thought it was better for teaching purposes, but we have had cause to regret it and would probably switch to prefix notation if we could start again from scratch. -- Hugh Darwen Perhaps you need to get out of the design and...into the implementation phase I have started working on an XBase demo implementation of my proposed language, but keep dragging my feet when it comes to finishing it. ________________ oop.ismad.com
Post #211,955 by boxley 6/21/05 3:20:32 PM Reply	sounds like you would be happy doing MAS90 All tribal myths are true, for a given value of "true" Terry Pratchett [link\|http://boxleys.blogspot.com/\|http://boxleys.blogspot.com/] Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 49 years. meep questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #211,963 by mmoffitt 6/21/05 4:35:39 PM Reply	Wow. That's harsh. ;0) bcnu, Mikem It would seem, therefore, that the three human impulses embodied in religion are fear, conceit, and hatred. The purpose of religion, one might say, is to give an air of respectibility to these passions. -- Bertrand Russell
Post #211,977 by boxley 6/21/05 6:03:18 PM Reply	its straight forward, lucrative and he enjoys the language All tribal myths are true, for a given value of "true" Terry Pratchett [link\|http://boxleys.blogspot.com/\|http://boxleys.blogspot.com/] Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 49 years. meep questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #211,985 by broomberg 6/21/05 6:53:22 PM Reply	You are writing a language IN xBase? Of course you'll never finish it!
Post #211,990 by tablizer 6/21/05 8:04:39 PM Reply	I am sort of pushing off parsing issues to something else ________________ oop.ismad.com
Post #211,825 by tablizer 6/20/05 8:54:38 PM 6/20/05 9:16:28 PM Reply	WRONGO! Your new query language is procedural and Turing complete No. It is not procedural. You could call it functional though because it follows the "no side-effects" rule (at least for queries). It is pretty much just relational algebra in prefix notation. I don't know whether it is Turing Complete or not. I haven't given that much thought[1]. I don't know if any recursive behavior it presents. Take a look at the draft: [link\|http://www.c2.com/cgi/wiki?TqlRoadmap\|http://www.c2.com/cgi/wiki?TqlRoadmap] See the bottom of this link for a related discussion on "declarative": [link\|http://www.c2.com/cgi/wiki?TqlChainedJoin\|http://www.c2.com/cg...ki?TqlChainedJoin] [1] Does a query language have to be non-TC to be considered "relational"? ________________ oop.ismad.com Edited by tablizer June 20, 2005, 09:16:28 PM EDT Expand All History
Post #211,852 by JayMehaffey 6/20/05 10:19:39 PM Reply	Re: WRONGO! No. It is not procedural. You could call it functional though because it follows the "no side-effects" rule (at least for queries). It is pretty much just relational algebra in prefix notation. To be a functional language it has to be possible for a function call to return a function in one form or another. This is really the defining feature of functional languages. Something like this has to be possible. Fnew = FCreator(a,b,c) Result = Fnew(x) The Business System Twelve you mention has a functional like syntax, but is a procedural language. I don't know whether it is Turing Complete or not. I haven't given that much thought[1]. I don't know if any recursive behavior it presents. The material in the draft you present now is not Turing complete. You make no mention of looping or conditional structures at all, so I can't tell if your intentions are in that direction or not. Jay
Post #211,875 by tablizer 6/21/05 2:04:44 AM Reply	Prefix != "procedural" The Business System Twelve you mention has a functional like syntax, but is a procedural language. I don't think so. You seem to mistake anything with prefix notation as procedural. Boolean algebra can be done with prefix syntax, but that in itself does not make it procedural. To be a functional language it has to be possible for a function call to return a function in one form or another. I meant that it follows the "no side-effects" functional rule, not that it necessarily takes on all features of a "functional" language. I apologize for not being clear. ________________ oop.ismad.com
Post #212,206 by JayMehaffey 6/22/05 11:36:38 PM Reply	I wasn't talking aobut it's notation I don't have much to go on for either you language or Buisness System Twelve, but when I said they have functional like syntax I was talking about the way the code was laid out. X = func(param1, param2) Y = func2(x, param3) Z = func(func2(y, param4), param4) The code layout style, with every line being a function and the ability to use functions freely as parameters is typical of functional languages. But it isn't exclusive to them. On the other hand, the use of variables to pass values between lines of code is indicative of procedural code, as the organization of code into blocks that can be stored and called from other blocks. In fact, in a purely functional language there are no variables at all. The above code would have to be written. func( func2( func2( func(param1, param2), param3), param4), param4) Few langauges go to that extreme though. I meant that it follows the "no side-effects" functional rule, not that it necessarily takes on all features of a "functional" language. I apologize for not being clear. Few, if any, languages are perfectly side effect free. If it was truely side effect free then there would be no update or insert commands. For a language to be referentially transparent, that is to have no side effects at all, any call to a function with the same parameters must cause the function to return the same value. This means that selecting a specific field in a specific row in the database must always return the same value. Thus nothing can be allowed to change the tables. Pure functional languages can work despite this because they have no persistant store of data or interactive inputs. All information must be contained in the parameters passed to the function. Once again, few languages go that extreme. Which isn't to say that your language might no be fairly good in the end, though you still have a long way to go before you even have a complete description of it. It just won't be a functional language, unless you radically change the concept it will be a procedural language. Jay
Post #212,340 by tablizer 6/23/05 7:35:24 PM Reply	Variables can be semantic "references", not necess. storage the use of variables to pass values between lines of code is indicative of procedural code, as the organization of code into blocks that can be stored and called from other blocks....In fact, in a purely functional language there are no variables at all. The above code would have to be written. func( func2( func2( func(param1, param2), param3), param4), param4) This: func1(func2(func3(p3),p2),p1) can be represented as: a = func3(p3) b = func2(a, p2) func1(b, p1) It is just a matter of using names to reference parts instead of using nesting. The query compiler/interpreter can turn one into the other as needed. References are done as a matter of human convenience. Plus, references allow you to reference the same item twice, something that is difficult with nesting (SQL-like). The thing is, one can execute the above as procedural code, and that is one of the selling points of my proposed language: it can be easily implimented, or at least simulated, as native function calls. Now just like SQL INSERT, UPDATE, and DELETE, there are "data transformation" operations. Such indeed do violate pure functional, like you said. But outside of these, it is non-side-effect. ________________ oop.ismad.com
Post #209,174 by ChrisR 5/31/05 11:40:51 AM Reply	CASE is the ANSI/ISO-standard Don't mean that all DB's implement it though.

Welcome to IWETHEY!