IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New 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]
Collapse Edited by ChrisR May 27, 2005, 09:50:17 PM EDT
Re: Another SQL Puzzle
SELECT 
   column_A, 
   (CASE (column_A = 0) THEN 0 ELSE 1 END) as bar 
FROM fooTable
New Hmmm. Standard?
________________
oop.ismad.com
New 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
Expand Edited by tuberculosis Aug. 21, 2007, 05:44:10 AM EDT
New 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
New 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)
New 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!
New 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
New 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)
New Please be more specific
________________
oop.ismad.com
New Horse corpse - meet Mr. Stick
New IOW, guilty until proven innocent. IranWeThey
Just point to the passage that allegedly exposed me as being declaratively ignorant.
________________
oop.ismad.com
New Sorry, I've got real SQL work to do.
Save Fintlewoodlewix
New 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
Expand Edited by tablizer June 21, 2005, 02:18:03 AM EDT
New 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.
New 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
New 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]
New 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
New 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]
New You are writing a language IN xBase?
Of course you'll never finish it!
New I am sort of pushing off parsing issues to something else
________________
oop.ismad.com
New 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
Expand Edited by tablizer June 20, 2005, 09:16:28 PM EDT
New 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
New 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
New 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
New 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
New CASE is the ANSI/ISO-standard
Don't mean that all DB's implement it though.
     Simple SQL look-up turns out hairy - (tablizer) - (51)
         I awalys hated SQL based batch updates - (broomberg) - (12)
             Let's bring back FoxPro! - (tablizer) - (11)
                 Silly person you - (broomberg) - (10)
                     Preach! -NT - (drewk)
                     63.472% Disagree - (tablizer)
                     Real world example - (broomberg) - (7)
                         I am not sure what your point is - (tablizer) - (6)
                             It's been done already - (broomberg) - (5)
                                 Or PL/SQL, or TransactSQL, or... -NT - (admin) - (4)
                                     Nah - (broomberg) - (2)
                                         I didn't say they were the best. - (admin) - (1)
                                             I know. I do. - (broomberg)
                                     I find PL/SQL and Transact/SQL too verbose -NT - (tablizer)
         COALESCE - (drewk)
         Re: Simple SQL look-up turns out hairy - (JayMehaffey)
         Simpler SQL - (ChrisR) - (2)
             My 1999 book implies UPDATE....FROM is not standard -NT - (tablizer) - (1)
                 Probably so... - (ChrisR)
         And you're surprised because what? -NT - (pwhysall)
         Another SQL Puzzle - (tablizer) - (31)
             Re: Another SQL Puzzle - (ChrisR) - (25)
                 Hmmm. Standard? -NT - (tablizer) - (24)
                     No such thing in SQL world - dialects everywhere -NT - (tuberculosis) - (22)
                         Good point. Standard != Common_Implementation - (tablizer) - (21)
                             Lemme guess... - (ben_tilly) - (20)
                                 The best way to fix non-standard implementations.... - (ChrisR)
                                 I had a look. - (static) - (13)
                                     Fish in a barrel -NT - (ben_tilly)
                                     Please be more specific -NT - (tablizer) - (11)
                                         Horse corpse - meet Mr. Stick -NT - (broomberg) - (1)
                                             IOW, guilty until proven innocent. IranWeThey - (tablizer)
                                         Sorry, I've got real SQL work to do. -NT - (static) - (8)
                                             SQL sucks (as a relational language) - (tablizer) - (7)
                                                 Perhaps you need to get out of the design and... - (ChrisR) - (6)
                                                     Some convergence perhaps - (tablizer) - (5)
                                                         sounds like you would be happy doing MAS90 -NT - (boxley) - (2)
                                                             Wow. That's harsh. ;0) -NT - (mmoffitt) - (1)
                                                                 its straight forward, lucrative and he enjoys the language -NT - (boxley)
                                                         You are writing a language IN xBase? - (broomberg) - (1)
                                                             I am sort of pushing off parsing issues to something else -NT - (tablizer)
                                 WRONGO! - (tablizer) - (4)
                                     Re: WRONGO! - (JayMehaffey) - (3)
                                         Prefix != "procedural" - (tablizer) - (2)
                                             I wasn't talking aobut it's notation - (JayMehaffey) - (1)
                                                 Variables can be semantic "references", not necess. storage - (tablizer)
                     CASE is the ANSI/ISO-standard - (ChrisR)
             Easy if you have decode - (SpiceWare)
             Re: Another SQL Puzzle - (takicutie) - (3)
                 hmm - decode won't work afterall - (SpiceWare) - (2)
                     Nope, no negative in my case - (tablizer) - (1)
                         It has been standardized. - (ChrisR)

This is Helena.
108 ms