Invisible escreveu:
>>> What, defining three pages of code is longer than the 1-liner I posted?
>>>
>>> The ($) operator is defined in the Haskell language standard. :-P
>>
>> The o operator is defined in my personal standard and I never look 
>> back. ;)
> 
> OK, but ($) is still a 1-liner:
> 
>   f $ x = f x
> 
> And, unlike your notation, it doesn't require any brackets at all! ;-)

Why would my o operator not be a one-liner?  Unless you think the 
implementation of $ doesn't count.  It's just as abstracted away as the 
implementation of o.

I don't have a problem with brackets or parenthesis.  Besides, Haskell 
needs it too to solve ambiguities in all but the most simpler expressions.

And multiple $ for each call is as bad as multiple parenthesis, I guess.

> BTW, what would you say the most irritating library design flaw in 
> Scheme is?

None.  It's perfect. ;)

Ok, to be fair, I didn't like the latest standard very much... And given 
Scheme is very minimalist, I'm used to writing my own libs, so any 
design flaws are really mine. ;)

> In Haskell, my personal one is this:
> 
>   filter odd [1, 2, 3, 4]
> 
> That takes a list and filters out the odd numbers, right?
> 
> WRONG!
> 
> It filters out the *even* numbers.
> 
> Like, WTF?
> 
> Obviously what they *should* have done is name it "select". Then you 
> would write
> 
>   select odd [1, 2, 3, 4]

Hmm, that's just different terminology for the same things.  Yes, I too 
would expect filter odd to return the odds, but it certainly can be seen 
working the other way around.  I believe, though, that 2 functions doing 
pretty much the same thing is wrong and bad design.  select is really 
only used in SQL.  filter is a pretty common functional language idiom...

Post a reply to this message

Invisible escreveu:
>   data Settings = Settings
>     {
>       time_step :: Time,
>       min_subdivide :: Time,
>       tolerance :: Space,
>       recursive :: Bool
>     }
> 
>   foo $ Settings {recursive = True, tolerance = 0.01, min_subdivide = 
> 0.001, time_step = 2.5}
> 
> Heh, that's the trouble with named arguments - it gets so verbose. ;-)

Hah!  And now you got brackets and colons (and type declarations)!! 
mwahahahaaha

Post a reply to this message

Invisible wrote:
> Don't forget Smalltalk. (Although Smalltalk still requires you to write 
> them *in the right order*.)

*And* it doesn't tell you in advance when you get it wrong. :-)

Try Ada. :-)

> Yeah, actually _any_ function that requires 8 distinct arguments is 
> probably a bad idea. 

For OO, you should probably be setting them as configuration-style data on 
the object you're invoking. This is Bertrand Meyer's take on it, and it 
makes sense to me: if you have a method in an OO language that has optional 
arguments, those arguments ought to be properties on the object with setters 
and getters. I think this is probably true, because 95% of the time I wind 
up with optional arguments, it's because I already wrote and used the 
function in a bunch of places, and now I want to pass one more argument 
without tracking down all the places the original got called. Either making 
it a method with a settable parameter in the instance, or actually taking 
the time to track down all the calls (which can be messy in a very dynamic 
language) would fix that.

For functional, I can easily imagine a main loop sort of thing having to 
carry around a bunch of arguments that don't make sense to put together.

For example, I have a computer word game where the main game-engine keeps a 
list of possible guesses, a list of the computer's past guesses, a list of 
new words it learned this game, a list of guesses made by the player and 
their associated score, the human's previous guess, the computer's previous 
guess, the computer's secret work (which the human is trying to guess), the 
original list of words, the connection to the UI, and the random number 
seed. It's hard to believe there's any data structure that sensibly 
encapsulates all that without simply being a kludge to work around the lack 
of loops in the language. (With loops, you'd just make most of them local 
variables and not actually have to pass them through the recursive calls.) 
Mind, I'm not used to functional programming, so maybe I'm doing something 
wrong...

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Invisible escreveu:
> nemesis wrote:
> 
>> http://en.wikipedia.org/wiki/Lisp_(programming_language)#Language_innovations 
>>
>>
>> Not that wikipedia is authorithative knowledge... :P
>>
>> Until then, all you had was assembly branching.
> 
> ...there's an XML syntax for Lisp??! o_O
> 
> *runs away*

Holy Crap!!

actually, it's just a bridge between CL and XML.  Hey, XML itself is an 
s-expression language, like Lisp. ;)

Post a reply to this message

Invisible wrote:
>   filter odd [1, 2, 3, 4]
> It filters out the *even* numbers.

Yes. And the odd numbers stay behind in the filter. If you filter out coffee 
grounds, what do you have when you're done? Grounds, or coffee?

The problem with a real filter is it separates, rather than selects. When 
you filter coffee, are you filtering the grounds or the drinkable stuff? 
Neither: you're separating the two.

I'm kind of surprised "filter" doesn't return both, given it would seem 
(semantically) fairly easy not to calculate whichever half doesn't get used.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

>>   filter odd [1, 2, 3, 4]
>> It filters out the *even* numbers.
> 
> Yes. And the odd numbers stay behind in the filter. If you filter out 
> coffee grounds, what do you have when you're done? Grounds, or coffee?
> 
> The problem with a real filter is it separates, rather than selects. 
> When you filter coffee, are you filtering the grounds or the drinkable 
> stuff? Neither: you're separating the two.

I still prefer Smalltalk's "select" and "reject". Makes much more sense 
to me. :-P

> I'm kind of surprised "filter" doesn't return both, given it would seem 
> (semantically) fairly easy not to calculate whichever half doesn't get 
> used.

Nope; that's "partition". (Which at least has a sensible name.)

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

Post a reply to this message

> Why would my o operator not be a one-liner?

Because it's defined as four (very wide) lines? :-P

> I don't have a problem with brackets or parenthesis.  Besides, Haskell 
> needs it too to solve ambiguities in all but the most simpler expressions.

Yeah, I know. This argument is getting kinda silly. ;-)

> And multiple $ for each call is as bad as multiple parenthesis, I guess.

Not really. With brackets, you have to match opening and closing 
characters. With ($), there is only one thing to "match". The trouble 
comes if you try to mix it with brackets as well... Basically, if you 
find yourself doing this, you should probably split your expression into 
smaller parts. Same as any language, really... except Lisp. In Lisp, you 
cannot avoid endless brackets, because notionally the *entire source 
code* as a single expression. :-P

>> BTW, what would you say the most irritating library design flaw in 
>> Scheme is?
> 
> None.  It's perfect. ;)

Heh, right. One question: is it statically-typed?

> Ok, to be fair, I didn't like the latest standard very much... And given 
> Scheme is very minimalist, I'm used to writing my own libs, so any 
> design flaws are really mine. ;)

Yeah, I prefer a language with as few things as possible "baked-in".

Sadly, Haskell's list syntax is one such thing. :-(

> Hmm, that's just different terminology for the same things.

Ah, but *never* underestimate how important terminology can be! ;-)

> I believe, though, that 2 functions doing 
> pretty much the same thing is wrong and bad design.

Haskell is *loaded* with functions that do the same or similar things. 
It's about how you want to think about your problem.

For example, there's a variable defined that's called "otherwise". It's 
value is "True". But compare these:

   foo x
     | x <  0 = ...
     | x == 0 = ...
     | True   = ...

   foo x
     | x <  0    = ...
     | x == 0    = ...
     | otherwise = ...

Which do you think is clearer? ;-)

> select is really only used in SQL.

And Smalltalk.

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

Post a reply to this message

>> ...there's an XML syntax for Lisp??! o_O
>>
>> *runs away*
> 
> Holy Crap!!
> 
> actually, it's just a bridge between CL and XML.  Hey, XML itself is an 
> s-expression language, like Lisp. ;)

More worryingly... There is also Lisp syntax for Haskell. o_O

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

Post a reply to this message

Orchid XP v8 escreveu:
>>> ...there's an XML syntax for Lisp??! o_O
>>>
>>> *runs away*
>>
>> Holy Crap!!
>>
>> actually, it's just a bridge between CL and XML.  Hey, XML itself is 
>> an s-expression language, like Lisp. ;)
> 
> More worryingly... There is also Lisp syntax for Haskell. o_O

There is Liskell. ;)

http://liskell.org/

Post a reply to this message

Orchid XP v8 escreveu:
>> Why would my o operator not be a one-liner?
> 
> Because it's defined as four (very wide) lines? :-P

By how many lines is $ defined by?

Abstract it away, man!  We're here today because we stand in the 
shoulders of giants, don't forget that...

> In Lisp, you 
> cannot avoid endless brackets, because notionally the *entire source 
> code* as a single expression. :-P

Yes, code is data in Lisp.  Ain't that sweet? :)

> Heh, right. One question: is it statically-typed?

No.  Like I said, perfect. :)

> Haskell is *loaded* with functions that do the same or similar things. 
> It's about how you want to think about your problem.

I prefer to design my own DSLs and have a minimalist general-purpose 
language with few constructs that don't get in the way nor confuse me 
with conflicting semantics.

Post a reply to this message