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: 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
     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)

Yeah, baby!
171 ms