Re: advantage of dynamic typing
In the official site of shen language http://www.shenlanguage.org/ the talk about porting shen (which is common lisp based in its default implementation) to others langs like javascript, llvm,scheme and... clojure! (the page http://www.shenlanguage.org/kernel.htm where i did read about clojure as a possible target is 404 now :-/ )! i am guessing if someone is working on it... Shen is a lisp statically typed and claims: Shen has one of the most powerful type systems within functional programming. Shen runs under a reduced instruction Lisp and is intended for a wide variety of platforms. Hence our goal and our motto; '*write once, run anywhere*'. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Javier, Nathan +1 I think type systems such as Haskells (and presumably Scala's FP stuff, don't know anything about that) are really the way to go if you want static typing. I think the extra safety that it provides you with is really beneficial and for most things Haskells type system feels pretty light weight, you basically only have to type the function signature (if that) and you get algebraic polymorphisms with all the safety and generality. That said, I read somewhere (can't find the link now, sorry) that compile-time type checking in Lisps is difficult because they allow code generation at run time? That would still leave the possibility to apply it to everything which is evaluated at compile time which I assume is 99.5% of all clojure code. cheers Paul On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson n...@sfu.ca wrote: Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome day. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Hi Nathan! I am very intrigued by your approach. I would love to contribute, my problem is that I don't know the first thing about type inference systems (as in how they work on the inside). Do you have a good reference here? I'll take a look at what you've done, maybe bother you with some questions Thanks for the work! cheers Paul On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson n...@sfu.ca wrote: Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome day. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
I am following the general strategy described in Sam Tobin-Hochstadt's work. He is the person behind typed-racket. His Phd dissertation[1] has an overview of the area of gradual/soft/refinement typing in dynamic languages. It's a good place to start, with a pretty gentle introduction to the motivations and issues involved (though I'd imagine you'd need a rough understanding of sequent calculus notation to follow his description of the semantics of his type system). [1] http://www.ccs.neu.edu/home/samth/ On Sep 27, 12:43 am, Paul Koerbitz paul.koerb...@gmail.com wrote: Hi Nathan! I am very intrigued by your approach. I would love to contribute, my problem is that I don't know the first thing about type inference systems (as in how they work on the inside). Do you have a good reference here? I'll take a look at what you've done, maybe bother you with some questions Thanks for the work! cheers Paul On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson n...@sfu.ca wrote: Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome day. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Hi Nathan, thanks for the pointer, this is great! I got his dissertation, this does seem like a great starting point given that he is the guy behind typed racket. The wikipedia page on sequent calculus also looks promising, let's see how far I'll make it ;) Thanks for the pointer Paul On Sep 27, 10:03 am, Nathan Sorenson n...@sfu.ca wrote: I am following the general strategy described in Sam Tobin-Hochstadt's work. He is the person behind typed-racket. His Phd dissertation[1] has an overview of the area of gradual/soft/refinement typing in dynamic languages. It's a good place to start, with a pretty gentle introduction to the motivations and issues involved (though I'd imagine you'd need a rough understanding of sequent calculus notation to follow his description of the semantics of his type system). [1]http://www.ccs.neu.edu/home/samth/ On Sep 27, 12:43 am, Paul Koerbitz paul.koerb...@gmail.com wrote: Hi Nathan! I am very intrigued by your approach. I would love to contribute, my problem is that I don't know the first thing about type inference systems (as in how they work on the inside). Do you have a good reference here? I'll take a look at what you've done, maybe bother you with some questions Thanks for the work! cheers Paul On Fri, Sep 23, 2011 at 04:47, Nathan Sorenson n...@sfu.ca wrote: Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typing http://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logic https://github.com/clojure/core.logicsome day. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On Sep 27, 2011, at 3:40 AM, Paul Koerbitz wrote: That said, I read somewhere (can't find the link now, sorry) that compile-time type checking in Lisps is difficult because they allow code generation at run time? That would still leave the possibility to apply it to everything which is evaluated at compile time which I assume is 99.5% of all clojure code. FWIW I tend to generate a lot of code at runtime. But maybe my stuff is in the other 0.5%. I do remember Rich Hickey stressing the dynamic nature of the language in one of the videos that introduced me to Clojure, and this was a major attraction to me and perhaps to others... -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Yes I am very hopeful progress is made on that front! I've been having great success with 'Constraint Handling Rules' (CHR), which serves as my basis for solving type constraints. https://github.com/nsorenson/Clojure-CHR contains my very preliminary crack at implementing this system. The trick with dynamic languages such as Clojure is that the functions are extremely lax in what they accept--without a fairly advanced inference system, you will simply infer every variable to be type Object. I've been using CHR disjunctive branches to offer what's called occurrence typing--a system where you may assign different types to variables depending on the structure of the code. For instance, if you have a (map? x) as a predicate on an if clause, you know in the 'then' branch that x can be typed to Map. Nothing to show yet, and I'm not sure how well it will work on large programs, but my first few little experiments are looking promising. On Sep 22, 3:28 am, Javier Neira Sanchez atreyu@gmail.com wrote: i am surprised nobody mentioned gradual/optional typinghttp://lambda-the-ultimate.org/node/1707, typed racket http://docs.racket-lang.org/ts-guide/ and the possible type checker to be built by *some clever hacker* on core.logichttps://github.com/clojure/core.logicsome day. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On 09/21/2011 01:51 AM, Laurent PETIT wrote: I would see no problem of e.g. having a way to explicitly declare, in the public interface of the function (as opposed to derived implicitly from the current implementation detail of the function) the necessary constraints on the function arguments. And the guarantees on the function's result. Those could then allow more checks at compile time, without sacrificing genericity of the code. Something like Racket's contracts, perhaps? http://pre.racket-lang.org/docs/html/guide/contracts.html -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 20.09.2011 22:55, schrieb Islon Scherer:
Scala is a OO language with FP support, clojure is a functional
language with OO support, they are very different. It's normal for
someone with a OO background to think that every method receives a
object of some kind and it's good to know it's type in advance, and
if you want polymorphism you create a subclass or implement an
interface but in clojure functions are polymorphic not classes.
Let's take the function first as an example, if you give a String
to first you'll get the first char, if you give a vector or list
you'll get the first element, if you give a java array you'll get
the element at index 0.
yes, but you magically need to know
a) for which types does it work? if you give a byte to the function,
will you get an error, or its first bit? or its first char after its
been converted to a string?
b) if i want my data structure to support this, how do i have to do that?
both questions are answered by a signature. the java one would be via
an interface, and scala offers structural types which are much more
elegant in this case:
def first[A](fromThis: {def first: A}) = fromThis.first
if that hurts, you can extract the type definition:
type SupportsFirst[A] = {
def first:A
}
def first[A](fromThis: SupportsFirst) = fromThis.first
the compiler will tell you if whatever you want to put in there
doesn't have a method first having a matching signature
In scala each collection class has a overriden first method so you
can have a static and pre-defined return type, in clojure the first
function is itself polymorphic so it doesn't make sense to say that
the return type of first is Object because it depends on the
parameter. You can code clojure's first function in scala but the
parameter and return type would be Object, and you would have to
typecast it anyway.
no, see above. i can tell scala (and even java!) to return whatever is
coming in
(Maybe with scala's extremely fancy type system you can create a
generic first function a la clojure but the type signature would
make my eyes hurt :) With doc, source (the functions) and the repl,
a static typing system would'n be that useful
-- You received this message because you are subscribed to the
Google Groups Clojure group. To post to this group, send email to
clojure@googlegroups.com Note that posts from new members are
moderated - please be patient with your first post. To unsubscribe
from this group, send email to
clojure+unsubscr...@googlegroups.com For more options, visit this
group at http://groups.google.com/group/clojure?hl=en
i have to object. a function signature in scala that takes something
(A) which contains something else (B) and returns such a something
else (B), for example first, would look like this:
def first[A, M[B]](fromThis:M[B]):A
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOeYudAAoJENRtux+h35aGB6MQAJqhJKRwW1ZJ2GVfU8jEqtJe
WMuckgmI2aXB2dn862ebQ5XOmbqy45twVICSql85ARJsVoRCJtUaIdu/nsQYQiXa
2cNCPGFgD1VN2woAd0P4glsBdtsfKTirz/HcLNbHlE34sTMHrn8h96TXuupb9XVM
s1Yg0Gdr/sUsvZmvwn/gi+pLQDuvkU0LW0dx+TJv64gm42nWanKypvGSGSzXpQNm
/4ilBEI3peMj9BIV5zZGJqiJoHaJ/cZuCtZEF19ic3o0RhtqPReOr5ud5+uzIQoN
A6/gmoAJ+GQX58XWCPCJsr7INjv9B4Zp/oAzTJ1Br5fZcMfHDRQ7ZurXXuRlxX8M
CkvbvHegVR8IAl9/EF3YlT//CDvHpgLGCTFgngzmmSUQ3MJEQA3g7S7VpE/zZq7Z
tBowTHNf3jOrYNUzrvhnvSMX3aGKvgKvEK0MRkD6zgueVfTGLPwXiUVscYM8/dhP
x0vvo3g5nSSdo5RxjHVnxJbudWDBznRbDSM3yJcDHouSit4MRPzBVLufegJn7sWF
MBK+z4Wd+YDtqL0ieDpS87VVtaTyUVUEdzcnbd6LaFgwyXPyCNYp9B7g4+CBxLMZ
IiRs+CG3LhGWh64LnkZ6Cy9zhkWvION9gb336GafkaGJgke+y+kz0pMCLLjVoki0
nlvrXMuWvS7hiwzOXW8J
=tVBH
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
2011/9/21 Thorsten Wilms t...@freenet.de On 09/21/2011 01:51 AM, Laurent PETIT wrote: I would see no problem of e.g. having a way to explicitly declare, in the public interface of the function (as opposed to derived implicitly from the current implementation detail of the function) the necessary constraints on the function arguments. And the guarantees on the function's result. Those could then allow more checks at compile time, without sacrificing genericity of the code. Something like Racket's contracts, perhaps? http://pre.racket-lang.org/**docs/html/guide/contracts.htmlhttp://pre.racket-lang.org/docs/html/guide/contracts.html Contracts are indeed a generalization of constraints on type properties -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On Wed, Sep 21, 2011 at 3:00 AM, Dennis Haupt d.haup...@googlemail.com wrote: yes, but you magically need to know a) for which types does it work? if you give a byte to the function, will you get an error, or its first bit? or its first char after its been converted to a string? b) if i want my data structure to support this, how do i have to do that? I'm curious: in what world is API documentation considered to be magical? :) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.09.2011 19:58, schrieb Ken Wesson: On Wed, Sep 21, 2011 at 3:00 AM, Dennis Haupt d.haup...@googlemail.com wrote: yes, but you magically need to know a) for which types does it work? if you give a byte to the function, will you get an error, or its first bit? or its first char after its been converted to a string? b) if i want my data structure to support this, how do i have to do that? I'm curious: in what world is API documentation considered to be magical? :) - -- good point. in my experience, public apis often are well documented (no problem with clojure standard lib) while in-team-code is rarely documented at all -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOejZrAAoJENRtux+h35aGZ8gP/0sKZAOSjMLYZgD0pFy9vs5v 54wUcP9/D+YEreM8hW67P1j0lNcRqFzEjPDvGX+dykdrZKOrfQ1xpFboiARusLSn XbtoO4vlkwxwwMv9kcB6DyWtTsP7vEc9M9jJkHRNEERynk6DKBrtAX0RHXz4Qfyj uHHovEG+a68vcbrY1C9GqRck/Qqhdn0JjoKwFXkZGEUaPVf6rLRfav/JY8wl5Mj2 AKYhj/0LTUCknqkMFYkflAdLLVFjYLWX+zAeac18E2/RtRFFT5kedhYzHe3CpPY4 x6BaT5hCS/fZkyYR2kzbar1F18RL4vixmg8HbjGceLLOobW2r5EVyNRxQMv8DIpi XkjZiW0jqC6XFpoK2KVCaMzJwM46SWNoY6xYglV9/prdQ0Jmf5Isa/FVL+T24Mrq uaI6AzlKMHk4NzfQNEvJYr22q/H9oT8waEPKDMtWgQsFkSwRFotCfkqu1L5T78MT BlPek1RIZLTPjxt4kXNwdTC0Q52hiLKNNJakIEakHxSdlwmeT+1i3b+v+luFfdw6 6mGb0H8x0pUJKnU/QHFzPA/hPhg0LMOhdwTdvUm+O/7cbFhAakvhLMdUZlEmj70Y 9DugBMLto6bHyMk4kXUyHzP4ProiFmTwNE5P5UFhtl60svAmkxYuQXFl6JeisxX/ zTIgie+GRZPuGSTtcKPy =pfvF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
These types of discussions seem to get very broad in their scope and not much is ever settled. That being said, it seems one place where dynamic typing is a huge advantage is for records--Clojure records are prevalent and extremely easy to use, and are an excellent substrate for where we would normally use objects. Now, it's possible to have records in statically typed languages, but there are many different ways to do it, and not all buy you the same properties you enjoy in a dynamic language (duck-typing a record if it contains the correct fields, adding additional fields the library designer didn't originally allow, etc.) Haskell has been trying for years to get a grip on it's record story. This isn't because it's impossible to have nice records in a static type system, it's simply because with a static type system you have to make a careful up-front choice about what your type system will allow. In a dynamic language you have none of these worries, and you are free to impose whatever invariants you like on your records. Great power/great responsibility, etc. On Sep 21, 12:09 pm, Dennis Haupt d.haup...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.09.2011 19:58, schrieb Ken Wesson: On Wed, Sep 21, 2011 at 3:00 AM, Dennis Haupt d.haup...@googlemail.com wrote: yes, but you magically need to know a) for which types does it work? if you give a byte to the function, will you get an error, or its first bit? or its first char after its been converted to a string? b) if i want my data structure to support this, how do i have to do that? I'm curious: in what world is API documentation considered to be magical? :) - -- good point. in my experience, public apis often are well documented (no problem with clojure standard lib) while in-team-code is rarely documented at all -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOejZrAAoJENRtux+h35aGZ8gP/0sKZAOSjMLYZgD0pFy9vs5v 54wUcP9/D+YEreM8hW67P1j0lNcRqFzEjPDvGX+dykdrZKOrfQ1xpFboiARusLSn XbtoO4vlkwxwwMv9kcB6DyWtTsP7vEc9M9jJkHRNEERynk6DKBrtAX0RHXz4Qfyj uHHovEG+a68vcbrY1C9GqRck/Qqhdn0JjoKwFXkZGEUaPVf6rLRfav/JY8wl5Mj2 AKYhj/0LTUCknqkMFYkflAdLLVFjYLWX+zAeac18E2/RtRFFT5kedhYzHe3CpPY4 x6BaT5hCS/fZkyYR2kzbar1F18RL4vixmg8HbjGceLLOobW2r5EVyNRxQMv8DIpi XkjZiW0jqC6XFpoK2KVCaMzJwM46SWNoY6xYglV9/prdQ0Jmf5Isa/FVL+T24Mrq uaI6AzlKMHk4NzfQNEvJYr22q/H9oT8waEPKDMtWgQsFkSwRFotCfkqu1L5T78MT BlPek1RIZLTPjxt4kXNwdTC0Q52hiLKNNJakIEakHxSdlwmeT+1i3b+v+luFfdw6 6mGb0H8x0pUJKnU/QHFzPA/hPhg0LMOhdwTdvUm+O/7cbFhAakvhLMdUZlEmj70Y 9DugBMLto6bHyMk4kXUyHzP4ProiFmTwNE5P5UFhtl60svAmkxYuQXFl6JeisxX/ zTIgie+GRZPuGSTtcKPy =pfvF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.09.2011 05:43, schrieb Sean Corfield: On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). i tend to completely ignore all non-trivial type signatures and treat them as what constraints are in a database. rules that prevent me from doing things that are obviously wrong. for scala's collection framework, that is enough. i can use it perfectly well, i know exactly what it does - i just don't know *how* in detail they work. but the trivial stuff like this parameter must support method x or always returns an instance of type x really helps. - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOePUTAAoJENRtux+h35aGGHAP/j0gCcyJIBntewvQCTgaS1Xz lOj4WnrJAfMWKK/Z2r0IBgKBCI8lwqRCYvzqDMa0tVi/Lnfk8tMVMjU2x0KSX1sZ BRSoWaueQzHmnbqtCr83vfeIhz9XngmeY8b8vJ+8WjYylK2OyUlfq6I2LhR/fy1M Un8SIiMT3RtUypDdWgHBALMNXnWbw+ToHHLOKX+XpXv4FjP8G8q6g/H2vouIAt0i tCEPom2aVpGguf2f3V49jcIzU03hwKM2qfnyF4B4rejuS17kGbpBSlaavdSfQus0 sv/s14EpoIOKcIp5SQqRRE96GfmHlopshNuoB4oS3qt57oeSudI20pl/8K/zdI6y 7CajeZUA/Sl56syjTjbdq0bwOcUwWrXJVDJefJ4tgSYJu2hQnTST6NS0Op1+Mm71 nTFG4+SgEMzXoT20NGoE16wKtJn//XLkKHzQ0h/1FvSJ6pTRL/+o8hj/lDA5Y/FD qLBGaJl6z8jXB8Nltv4nTCS24ZUAn8eDOhv184OvtkTxXXu7MZnu/XPoVueRrbzP /AWLjqPwko3MdEp8/ApqtKSdZ23rW4cm5Yxo/zytCoGoDSDu7/8m5XiWKUU2Oa2R MY8EUPcRz+qawE4CaFIevzLb/EfMgJnbtvBZ9LD6VQApFweIMO1/Rc6J1rRavwps MJWJC58v8gH0AKzs0lv5 =Rlqq -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Scala is a OO language with FP support, clojure is a functional language with OO support, they are very different. It's normal for someone with a OO background to think that every method receives a object of some kind and it's good to know it's type in advance, and if you want polymorphism you create a subclass or implement an interface but in clojure functions are polymorphic not classes. Let's take the function first as an example, if you give a String to first you'll get the first char, if you give a vector or list you'll get the first element, if you give a java array you'll get the element at index 0. In scala each collection class has a overriden first method so you can have a static and pre-defined return type, in clojure the first function is itself polymorphic so it doesn't make sense to say that the return type of first is Object because it depends on the parameter. You can code clojure's first function in scala but the parameter and return type would be Object, and you would have to typecast it anyway. (Maybe with scala's extremely fancy type system you can create a generic first function a la clojure but the type signature would make my eyes hurt :) With doc, source (the functions) and the repl, a static typing system would'n be that useful -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On Tue, Sep 20, 2011 at 1:55 PM, Islon Scherer islonsche...@gmail.com wrote: type would be Object, and you would have to typecast it anyway. (Maybe with scala's extremely fancy type system you can create a generic first function a la clojure but the type signature would make my eyes hurt :) oh boy. if you think you have to typecast it, then you are using scala very wrong! now, i'm not a big fan of all the ascii overhead in scala, so like you say yes the eyes being to hurt -- i'm not saying that it is easy for people to get into the scala mindset and to understand how to really use it. BUT please nobody think that scala is trying to force you to do runtime typecasing. noo way! sincerely. :-) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
+1 On Sep 20, 4:43 am, Sean Corfield seancorfi...@gmail.com wrote: On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Hello, The problem I see with using types is that imposing type X and type Y for the input arguments of method f is generally imposing too much constraint. Generally, the function just needs a subset of the types characteristics, and that's where genericity disappears. I would see no problem of e.g. having a way to explicitly declare, in the public interface of the function (as opposed to derived implicitly from the current implementation detail of the function) the necessary constraints on the function arguments. And the guarantees on the function's result. Those could then allow more checks at compile time, without sacrificing genericity of the code. Using interfaces in java is a way towards that goal, though since java does not allow to retrofit existing classes into new interfaces, this generally falls short of being generic enough. Using protocols in clojure, and with the property of protocols that they are implied to be more orthogonal than to form a hierarchy, seems interesting in this area. Finally, there will still be functions which are doing the specific jobs for specific types/records/whatever = so there's certainly still merits to be able to constrain some function arguments to specific types. HTH, -- Laurent 2011/9/20 Sean Corfield seancorfi...@gmail.com On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Another detail to remember for Clojure / other FP languagens, is that we don't have objects!, most of time we are using basic structures, and none of them has methods, in case, most of time we are expecting lists or hashes, in hashes, we most of time expect some keys to be present, and that's all... I really don't like to mix up clojure code with Java, when I really need Java, I always write some wrappers, so when I use it feels more Clojure. --- Wilker Lúcio http://about.me/wilkerlucio/bio Kajabi Consultant +55 81 82556600 On Tue, Sep 20, 2011 at 8:51 PM, Laurent PETIT laurent.pe...@gmail.comwrote: Hello, The problem I see with using types is that imposing type X and type Y for the input arguments of method f is generally imposing too much constraint. Generally, the function just needs a subset of the types characteristics, and that's where genericity disappears. I would see no problem of e.g. having a way to explicitly declare, in the public interface of the function (as opposed to derived implicitly from the current implementation detail of the function) the necessary constraints on the function arguments. And the guarantees on the function's result. Those could then allow more checks at compile time, without sacrificing genericity of the code. Using interfaces in java is a way towards that goal, though since java does not allow to retrofit existing classes into new interfaces, this generally falls short of being generic enough. Using protocols in clojure, and with the property of protocols that they are implied to be more orthogonal than to form a hierarchy, seems interesting in this area. Finally, there will still be functions which are doing the specific jobs for specific types/records/whatever = so there's certainly still merits to be able to constrain some function arguments to specific types. HTH, -- Laurent 2011/9/20 Sean Corfield seancorfi...@gmail.com On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
Dynamic typing just relax you at coding and compiling moment. The type interferacing is done at runtime. The pro is less formal coding especially on algorithms and cons that data structures must be documented outside the code unless language supports type specifing. Just read about haskell it will give you the wisdom (google learn haskell for great good), for example haskell is static typed but it also gives you power of algorithm eloquence like you would write in dynamic language, just at some point in code you must specify what types you are actually using in your solution. On 19 Wrz, 23:19, Dennis Haupt d.haup...@googlemail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi community, clojure is dynamically typed, so i thought here i might find some good reasons for that. what can you do if you sacrifice compile time type safety? an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. another advantage are macros or macro-like constructs at compile time, for example: resultset.columnname here, columnname could be translated to resultset.getObject(columnname). you could even go a step further and use the column names as local variables. again, conciseness to the max. what else is there? is it worth sacrificing type safety? and is there no way to combine both? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOd7HzAAoJENRtux+h35aGPfwP/iwwAdhTDfCmTzmMnp6QYnjf PEz+DDr7RxnCpTI/ptL73lSeFs2ctQGllzWgf6I2tZU+yB06ReGu/piIIZW/Z+sx 3TtIK+w9r3Jzz8lI0AljM5kfo+Zo/1OBgVaGkxon1NPbhZBnH0FpfeU43H7FnuhA 7bOu3HceOf8ju8fNNQmS+LLoueQJBEaRNn/tWkk5a/y1Ipg5hbETe/YL1+VnpAMg xyIRkfDFwtIlnZ8+0IMpdusI7PBOj+v9VINtSkAUkZptz9wvSFj4JghXU6Mw8dUp ATZSWGgdXZUrihNQ90K7OlIBG3xFrGiddSO5Gphe+PQFOwxaAf9x3z1opXVYJqt/ 7u64JHdqTQkBe4TUSEh5024CdgpLIRvXh54fthl84yjfGeodvibdEwCwg6NSF80o vl5XzeAuB/xaDkvlAE6aq2peh8+foJAxiiWoc+pKZOxYMm1lwKWTbYnnp0Slr8ym 6CB2dAX+vF/FIV3ctJvJJYcELX/ydTp0p3RoARtHD8QNebRjTlZ2VqLQqRdF1a4b Nc6tZUAmx1+zYLE+YavBIbgXwssw07MMtJfsyL4tIoX6+q7oQtsdPcVV+4/HvmcX 6d3bzdCHYod6lLcbZvBhm70DUUrxTMdF73VCvNMUwpPq9OvhRd650puMQwC+/zoK Pob2xj0YER0b1UHNKVFS =jV+l -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
advantage of dynamic typing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi community, clojure is dynamically typed, so i thought here i might find some good reasons for that. what can you do if you sacrifice compile time type safety? an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. another advantage are macros or macro-like constructs at compile time, for example: resultset.columnname here, columnname could be translated to resultset.getObject(columnname). you could even go a step further and use the column names as local variables. again, conciseness to the max. what else is there? is it worth sacrificing type safety? and is there no way to combine both? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOd7HzAAoJENRtux+h35aGPfwP/iwwAdhTDfCmTzmMnp6QYnjf PEz+DDr7RxnCpTI/ptL73lSeFs2ctQGllzWgf6I2tZU+yB06ReGu/piIIZW/Z+sx 3TtIK+w9r3Jzz8lI0AljM5kfo+Zo/1OBgVaGkxon1NPbhZBnH0FpfeU43H7FnuhA 7bOu3HceOf8ju8fNNQmS+LLoueQJBEaRNn/tWkk5a/y1Ipg5hbETe/YL1+VnpAMg xyIRkfDFwtIlnZ8+0IMpdusI7PBOj+v9VINtSkAUkZptz9wvSFj4JghXU6Mw8dUp ATZSWGgdXZUrihNQ90K7OlIBG3xFrGiddSO5Gphe+PQFOwxaAf9x3z1opXVYJqt/ 7u64JHdqTQkBe4TUSEh5024CdgpLIRvXh54fthl84yjfGeodvibdEwCwg6NSF80o vl5XzeAuB/xaDkvlAE6aq2peh8+foJAxiiWoc+pKZOxYMm1lwKWTbYnnp0Slr8ym 6CB2dAX+vF/FIV3ctJvJJYcELX/ydTp0p3RoARtHD8QNebRjTlZ2VqLQqRdF1a4b Nc6tZUAmx1+zYLE+YavBIbgXwssw07MMtJfsyL4tIoX6+q7oQtsdPcVV+4/HvmcX 6d3bzdCHYod6lLcbZvBhm70DUUrxTMdF73VCvNMUwpPq9OvhRd650puMQwC+/zoK Pob2xj0YER0b1UHNKVFS =jV+l -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On Mon, Sep 19, 2011 at 2:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: what else is there? is it worth sacrificing type safety? and is there no way to combine both? check out Dialyzer for Erlang. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: advantage of dynamic typing
On Mon, Sep 19, 2011 at 4:19 PM, Dennis Haupt d.haup...@googlemail.com wrote: an advantage i see is very, very concise code since you have no type annotations at all. the downside is that exactly this code might be unreadable - because you just have no idea what it uses and what it does without tests or documentation. I find Clojure code more readable because it is generic. Instead of some algorithm specialized by type, Clojure often deals with simpler generic algorithms that are applicable to a broader class of data structures which can also mean more reuse. Writing truly generic code in the presence of a strong type system is often harder word and tends to produce much more dense, more annotated code that I find harder to understand. Take a look at the documentation for the Scala collection library, for example (I'm not dissing Scala - I like Scala, but I don't think anyone will disagree that the auto-generated documentation based on the library type signatures is very hard to read, at least for the average developer). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
