![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> (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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>>> (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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> I've come up with a language I'm calling Hax.
...so does this qualify me as a haxor? :-D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |