|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> On 02/11/2010 02:00 AM, nemesis wrote:
> > Invisible<voi### [at] dev null> wrote:
> >> Is it possible to create variables with local rather than global scope?
> >
> > you're kidding me, right?
>
> Well, I've never seen anybody do it before, that's all.
no, you've never seen before, period. Even previous examples I posted. If
you'd had any curiosity on the subject, I'm sure plenty of examples abound in
places like projecteuler or language shootout.
> If you want a point, you say Point 3 7. Which, as you say, rather gives
> away the fact that it's a Point value. But how about saying "True"?
> That's of type Bool, but you didn't write that in your expression.
> Similarly, when you write
>
> Branch (Leaf 3) (Leaf 7)
>
> you didn't say anywhere that this is of type Tree Int, did you? The
> compiler infers this automatically.
it infers from unique names relating to a type like those sprinkled everywhere
in the code. Think about it... :)
> And don't even get me started on
> expressions which are polymorphic, and could have /several/ possible types.
expressions are polymorphic by default in dynamically-typed languages. :)
(define (foo bar) (boz (boz bar)))
(define (boz bar) (+ bar bar))
an implementation could infer foo ultimately works on numbers because boz calls
+. But + could be redefined as
(define +
(let ((o+ +))
(lambda args
(cond
((null? args) 0)
((number? (car args)) (apply o+ args))
((string? (car args)) (apply string-append args))))))
and thus foo works on numbers, strings and what more gets into the redefinition
of +.
or at least it could in scheme a few iterations ago. Today implementations say
+ can't be redefined... :p
> > I'm talking ill of Hindley-Milner type system, but you should be aware that the
> > same lameness can happen in Lisps too: here and now you will see things like
> > fl* fx+ or fl<... that is, functions to operate on specific numeric types.
> > Again, they exchange a single type declaration for type-specific operators
> > everywhere. Makes me wonder if the Algol folks got it right...
>
> Not so in Haskell. If you want to add two numbers, you use (+). It's
> polymorphic like that.
yes, + in Lisp is polymorphic over numbers, be it float or integer. fl+ or fx+
are performance-geared optimizations.
I still think simple declaration of a variable as of a given type would be
better than sprinkling code with operators/names that force expressions into a
given type.
> I'm actually surprised that a dynamically-typed language would do
> something like that. I thought the whole point of dynamic typing was
> that you can completely ignore types.
you can, except when you want performance.
> All I know is that every time I've used a dynamically-typed language,
> I've spent 90% of my time fixing type errors - errors which *could* have
> and *should* have been caught automatically by the machine, but I have
> ended up catching them myself, by hand. Yuck!
only you could do that in a language "without types" :p
I don't have a trouble providing arguments of the right types to functions, but
I must confess I've been flamed already by typos in the code only detected at
runtime. :p
Thankfully, the real nice thing about development with a REPL is that you can do
fine-grained iterative development: write little expressions, test them, put
them into a function, repeat. You write and test at the same time. shame that
haskell's REPL is very limited and doesn't allow for full type definitions and
such.
> > I suspect its homoiconic nature has lots to do with it. Plus, if you've never
> > edited Lisp code with hierarchical parenthetical editing you don't know what a
> > bless it is compared to any other language in existence.
>
> More like "without automatic bracket match, it's impossible to produce
> code which is even syntactically correct". It wouldn't be so bad, but it
> seems all Lisp programmers habitually indent their code incorrectly.
Lisp n00bs usually indent their code incorrectly, specially those who actually
care about the parentheses and treat them like brackets in C languages, even
going as far as matching open and close in the same indented column. Lisp
experts have long developed a code style that makes brackets virtually invisible
by hiding them to the rightmost end.
BTW, the expressions above I typed here, but copied them to a scheme buffer to
test them. You can do marvels by merely typing () in sequence and going in
between them next.
> I can see how having a language where everything is a list is
> technically quite a nice idea. It's simple and elegant. Unfortunately,
> the language as a whole seems to be messy and inconsistent. Too much
> backwards compatibility, too much muddled thinking. Still, I guess it
> was the first attempt...
There is quite a lot of backwards compatibility in CL, that's for sure: it was
designed by a comittee to comply with several older lisp dialects, so they
basically just made a big union of features. Not so much with scheme.
I'm specially annoyed at the car/cdr family of operators so dear to old Lispers.
Those were the names of two macro-assembler instructions in the first machine
Lisp was implemented in. They are truly lame legacy misnomers for head/tail...
I discussed a bit about them here to some strong reactions from old farts:
http://groups.google.com.br/group/comp.lang.lisp/browse_thread/thread/16135e3a09d5f6f3#
> > It's because you still don't know it well.
>
> Sure, functions are first-class. But it lacks purity.
like I said, aside from Haskell, no other language goes that far to ensure a
pure, side-effect-free mystical environment. Including others from functional
programming land, like scheme or ML.
this is side-effect free:
(let fact ((n 25) (r 1)) (if (< n 2) r (fact (- n 1) (* n r))))
even though implementations so far don't go as far as detecting its purity to
allow for fine-grained paralellism.
(BTW, once again written in the browser)
> It also doesn't
> appear to place any emphasis at all on coding in a vaguely functional
> style - not in the language design nor the standard libraries.
if you're talking about Common Lisp you're right: it's a very imperative
version of Lisp. Scheme was in part developed in the 70's as a functional
rework of the original Lisp principles.
> No, a design that enforces purity has profound consequences for any
> implementation of that design. (Not to mention the entire way that the
> language is used.)
true. But whenever I want all pure and white design I know where I can find
haskell... ;)
> And Clean doesn't count because...?
because it is even more obscure than haskell itself?
> To me, "new syntax" means that I can write something that doesn't look
> like the host language. From what little I've seen, a Lisp DSL just
> looks like Lisp.
true. We actually consider that a benefit. ;)
> And a Haskell expression consists of some combination of exactly 6 (go
> count them) structures.
nobody codes haskell without such sugar just as nobody codes scheme like
((lambda (fact) (fact fact 5))
(lambda (fact n) (if (< n 2) 1 (* n (fact fact (- n 1))))))
(once again written here)
> The rest is just sugar. That's peanuts compared
> to (say) the number of possible statements in Java. (For-loops,
> while-loops, if-then-else, return, switch/break...)
that's for sure is a gain of all functional programming languages: creating
larger things from the composition of a few core functions.
> > (iterate (pf * 2) 0)
>
> Yes, that's just as succinct as (*2). Oh, wait...
it is as succint as you can get without having to alter the parser to allow for
special syntax and corner cases here and there. Simpler design. :)
Post a reply to this message
|
![](/i/fill.gif) |