Invisible wrote:

> All of this makes me wonder... What would happen if somebody designed a 
> language which was exactly like Haskell, but had syntax like Pascal or 
> something? What if it didn't use terms like "monad" and "functor" and 
> "existential quantification", but used something more concrete-sounding?
> 
> Of course, the really bizare (and wonderful!) thing about Haskell isn't 
> its syntax, it's the ways in which you can use it. But I wonder... If 
> you dressed Haskell up in sheep's clothing, how long would it take 
> normal programmers to realise that what you're getting them to do is 
> actually crazy? >:-)

Just for giggles, I'm designing this language. So far I've implemented 
half the standard libraries with it. The results are... interesting. The 
code becomes 85% more verbose, but I wonder if it makes any difference 
to the level of comprehendability.

Post a reply to this message

Darren New wrote:

> Sounds like they've reinvented typestate, but I'd have to go dig up my 
> other technical books from two decades ago to see if their formulae match.

It sounds interesting and even possibly useful, but... it's 
incomprehensible. I can't make much sense out of it. Clearly whoever 
wrote this document knows what they mean. Unfortunately they didn't do a 
very good job of explaining it! :-P

Post a reply to this message

Invisible wrote:
> (Anybody have any clue how the 
> relational calculus is different from the relational algebra??)

Yes.

> SQL is 
> basically the relational algebra with COBOL-style syntax. 

Actually, it's relational calculus with COBOL-style syntax. ;-)

> All of this makes me wonder... What would happen if somebody designed a 
> language which was exactly like Haskell, but had syntax like Pascal or 
> something? What if it didn't use terms like "monad" and "functor" and 
> "existential quantification", but used something more concrete-sounding?

Go for it. Then write a parser to translate it into Haskell.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Just for giggles, I'm designing this language. So far I've implemented
> half the standard libraries with it. The results are... interesting. The
> code becomes 85% more verbose, but I wonder if it makes any difference
> to the level of comprehendability.

It absolutely depends on the keywords you use.

If you choose them to match the strict technical terms, then you're lost.

If you manage to choose them in a way that common people can relate to them,
then you may have a fair chance - even if that means picking words that would
be technically imprecise or even outright wrong.

Post a reply to this message

>> (Anybody have any clue how the relational calculus is different from 
>> the relational algebra??)
> 
> Yes.

Care to explain?

>> SQL is basically the relational algebra with COBOL-style syntax. 
> 
> Actually, it's relational calculus with COBOL-style syntax. ;-)

You know, until I read COBOL, I had no idea SQL looked like COBOL. (OMG, 
I think we have reached a tautology here!) But having seen COBOL, SQL 
really does seem overly wordy and silly... heh. :-D

>> All of this makes me wonder... What would happen if somebody designed 
>> a language which was exactly like Haskell, but had syntax like Pascal 
>> or something? What if it didn't use terms like "monad" and "functor" 
>> and "existential quantification", but used something more 
>> concrete-sounding?
> 
> Go for it. Then write a parser to translate it into Haskell.

Heh. Assuming I don't give it a type system which exceeds Haskell's 
expressive power. >:-D

But an interpretter should definitely be possible. Especially since it's 
easier to parse... ;-) I might even build a debuggar.

Post a reply to this message

>> Just for giggles, I'm designing this language. So far I've implemented
>> half the standard libraries with it. The results are... interesting. The
>> code becomes 85% more verbose, but I wonder if it makes any difference
>> to the level of comprehendability.
> 
> It absolutely depends on the keywords you use.
> 
> If you choose them to match the strict technical terms, then you're lost.
> 
> If you manage to choose them in a way that common people can relate to them,
> then you may have a fair chance - even if that means picking words that would
> be technically imprecise or even outright wrong.

Yeah, indeed.

I've come up with a language I'm calling Hax. I haven't finished 
figuring out what it looks like or how it works yet. It's basically 
Pascal with a few tweaks. And by "tweaks" I mean that the similarity 
between Hax and Pascal is like Java vs C++. Superficially, it looks the 
same. But if you investigate for more than 5 seconds, you'll discover 
that they're actually TOTALLY UNRELATED! >_<

In particular, many of the things that are implicit in Haskell are 
explicit in Hax. (E.g., allocating memory is always explicit, no 
implicit constructor functions, no currying...) And I'm trying to make 
the syntax as non-weird as possible. (No whitespace layout, no obscure 
symbols, no little ASCII-art arrows and zigzags.)

Additionally, some of the weirder features of Haskell are missing. (No 
more curried functions, no lambda functions, no pattern matching...) It 
makes the language less expressive, but no less powerful. And it makes 
it far more similar to familiar languages. CASE expressions now look 
more like Pascal or C, but with some extra super-powers. Literally, if 
you go "hey, this is basically Pascal, but it lets you do these EXTRA 
THINGS..." it comes across is kinda neat.

...or I'm delusional, of course. I have noticed that I code certain 
examples, look at them and go "hmm, there's no way a regular programmer 
would do it THAT way..." We'll see.

Oh, and "monads" are now called "procedures". ;-) This does not 
accurately reflect what they are and what they do, but it's far more 
intuitive to explain.

Post a reply to this message

Invisible wrote:
>>> (Anybody have any clue how the relational calculus is different from 
>>> the relational algebra??)
>>
>> Yes.
> 
> Care to explain?

It's kind of like the difference between functional and procedural.

In the calculus, you say "give me a table with the name, salary, and hire 
date from table X and table Y where X.name=Y.name and salary < 500"

In the algebra, you say "join table X and Y, and from that select the ones 
where the names are the same, and from that select the ones where the salary 
is < 500, and from that project over name, salary, and hire."

Think of SQL compared to something like

(((X join Y) select {salary < 500})
     select {X.name = Y.name}) project [name,salary,hire]

Only select, project, and join are defined in the algebra. There's no 
"exists" and such.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Additionally, some of the weirder features of Haskell are missing. (No
> more curried functions, no lambda functions, no pattern matching...)

What - a functional language without lambda functions? C'mon, I always thought
that was the icing on the cake...

I'd love to see such a functional language. Maybe it would help me grok the
concept, too - it somehow feels that functional programming concepts may really
be useful, and that I just didn't manage to really grasp the concepts.

And I mean grasp, not just comprehend from a theoretical point of view.

Post a reply to this message

clipka wrote:

> What - a functional language without lambda functions? C'mon, I always thought
> that was the icing on the cake...

It's nice to have, but you can live without it. Debatably, not having it 
makes things more explicit. In the language I'm designing, you basically 
always have to give a function a name before you can call it.

FWIW, I've always thought of curried functions as a syntactic short-cut 
as well. It turns out I was wrong; without curried functions, there are 
certain programs you actually can't write.

I'm ambivilent about these design choices. I'm still playing with my 
options...

(As already stated, no curried functions prevents the definition of 
certain operations. Additionally, not having lambda functions and 
curried functions means that creating functions is more hard work, and 
this somewhat tips the balance of power. It makes you more likely to 
define functions directly rather than as special cases of high-order 
functions, because it's almost more work to call a high-order function 
than to type in the definition directly. This is possibly not a good 
idea...)

> I'd love to see such a functional language. Maybe it would help me grok the
> concept, too - it somehow feels that functional programming concepts may really
> be useful, and that I just didn't manage to really grasp the concepts.
> 
> And I mean grasp, not just comprehend from a theoretical point of view.

Well, we'll see. It may be that having everything explicitly spelled out 
makes it clearer what's actually going on.

Alternatively, maybe all the syntactic chatter will be so OTT that it 
just obscures the meaning.

Or maybe the fundamental problem is that functional programming is just 
weird, and no amount of dressing it up will solve that. We'll see... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>>> (Anybody have any clue how the relational calculus is different from 
>>>> the relational algebra??)
>>>
>>> Yes.
>>
>> Care to explain?
> 
> It's kind of like the difference between functional and procedural.
> 
> In the calculus, you say "give me a table with the name, salary, and 
> hire date from table X and table Y where X.name=Y.name and salary < 500"
> 
> In the algebra, you say "join table X and Y, and from that select the 
> ones where the names are the same, and from that select the ones where 
> the salary is < 500, and from that project over name, salary, and hire."
> 
> Think of SQL compared to something like
> 
> (((X join Y) select {salary < 500})
>     select {X.name = Y.name}) project [name,salary,hire]
> 
> Only select, project, and join are defined in the algebra. There's no 
> "exists" and such.

So are the two formalisms of equivilent expressive power?

Post a reply to this message