Comments for Xoltar http://www.xoltar.org A blog by Bryn Keller about simplicity and clarity in software and in life Sun, 11 Nov 2012 21:07:07 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Comment on Transactional Objects by F# Weekly #45, 2012 | Sergey Tihon's Blog http://www.xoltar.org/?p=87&cpage=1#comment-738 F# Weekly #45, 2012 | Sergey Tihon's Blog Sun, 11 Nov 2012 21:07:07 +0000 http://www.xoltar.org/?p=87#comment-738 [...] Bryn Keller wrote about “Transactional Objects“. [...] [...] Bryn Keller wrote about “Transactional Objects“. [...]

]]> Comment on Transactional Objects by xoltar http://www.xoltar.org/?p=87&cpage=1#comment-722 xoltar Thu, 08 Nov 2012 22:36:52 +0000 http://www.xoltar.org/?p=87#comment-722 That's a good point. I'll think about ways to make those other options available, perhaps for a followup post. Thanks! That’s a good point. I’ll think about ways to make those other options available, perhaps for a followup post. Thanks!

]]> Comment on Transactional Objects by Frisian http://www.xoltar.org/?p=87&cpage=1#comment-720 Frisian Tue, 06 Nov 2012 16:00:57 +0000 http://www.xoltar.org/?p=87#comment-720 Given your description of "Isolation" the implementation works with an isolation level of "Read-Committed". Depending on the database there are also "Read-Uncommitted", "Repeatable-Read" and "Serializable". Especially for use as a cache the STM should work with the same isolation level as the database. If not, the difference in isolation might lead to bugs, that are very hard to identify. Given your description of “Isolation” the implementation works with an isolation level of “Read-Committed”. Depending on the database there are also “Read-Uncommitted”, “Repeatable-Read” and “Serializable”. Especially for use as a cache the STM should work with the same isolation level as the database. If not, the difference in isolation might lead to bugs, that are very hard to identify.

]]> Comment on Transactional Objects by Transactional Objects – Xoltar | Functional programming | Scoop.it http://www.xoltar.org/?p=87&cpage=1#comment-718 Transactional Objects – Xoltar | Functional programming | Scoop.it Mon, 05 Nov 2012 22:47:25 +0000 http://www.xoltar.org/?p=87#comment-718 [...]   [...] [...]   [...]

]]> Comment on My F# Wish List by Aaron http://www.xoltar.org/?p=84&cpage=1#comment-716 Aaron Sat, 25 Aug 2012 15:50:19 +0000 http://www.xoltar.org/?p=84#comment-716 > BETTER SYNTAX FOR ANONYMOUS FUNCTIONS You should be thankful. Back in my language (C++11), we have to write out our types, both ways, in the snow! // this is a lambda expression [=](SomeArgumentType x) // types not optional { // neither are the brackets, or the return keyword return x; // thankfully, return type is inferred - sometimes :-/ } //phew, finally done! > BETTER SYNTAX FOR ANONYMOUS FUNCTIONS

You should be thankful. Back in my language (C++11), we have to write out our types, both ways, in the snow!

// this is a lambda expression
[=](SomeArgumentType x) // types not optional
{ // neither are the brackets, or the return keyword
return x; // thankfully, return type is inferred – sometimes :-/
} //phew, finally done!

]]> Comment on My F# Wish List by Deen http://www.xoltar.org/?p=84&cpage=1#comment-715 Deen Fri, 24 Aug 2012 01:25:16 +0000 http://www.xoltar.org/?p=84#comment-715 For 3., the fact that generics are reified makes type classes not worth it in terms of cost benefit. 4. is a good idea but full ML modules are I believe hampered by the .NET object system but I am not 100% square on that. Arguably, for most cases where type classes or modules would be great; constraints, abstract classes, interfaces,SRTPs and or object expressions should suffice. They could do with making their statically resolved type parameters story cleaner however. I agree with all of the rest, especially 6,5, 2 in that order. Computation Expressions, Type providers and quotations are already 40% of the way to macros but there is some kind of an ideological barrier halting full macros. @Radek - unless I have misunderstood you, check Nemerle for a language that has intellisense yet great syntax flexibility. For 3., the fact that generics are reified makes type classes not worth it in terms of cost benefit.

4. is a good idea but full ML modules are I believe hampered by the .NET object system but I am not 100% square on that.

Arguably, for most cases where type classes or modules would be great; constraints, abstract classes, interfaces,SRTPs and or object expressions should suffice.

They could do with making their statically resolved type parameters story cleaner however.

I agree with all of the rest, especially 6,5, 2 in that order. Computation Expressions, Type providers and quotations are already 40% of the way to macros but there is some kind of an ideological barrier halting full macros.

@Radek – unless I have misunderstood you, check Nemerle for a language that has intellisense yet great syntax flexibility.

]]> Comment on My F# Wish List by My F# Wish List – Xoltar | Functional programming | Scoop.it http://www.xoltar.org/?p=84&cpage=1#comment-714 My F# Wish List – Xoltar | Functional programming | Scoop.it Thu, 23 Aug 2012 22:50:42 +0000 http://www.xoltar.org/?p=84#comment-714 [...]   [...] [...]   [...]

]]> Comment on My F# Wish List by Radek Miček http://www.xoltar.org/?p=84&cpage=1#comment-713 Radek Miček Thu, 23 Aug 2012 17:55:47 +0000 http://www.xoltar.org/?p=84#comment-713 Camlp4 would make IntelliSense very hard or impossible. But it would be nice to have some mechanism for syntax extensions which is IntelliSense friendly. Camlp4 would make IntelliSense very hard or impossible. But it would be nice to have some mechanism for syntax extensions which is IntelliSense friendly.

]]> Comment on Snap on Windows by Jens Petersen http://www.xoltar.org/?p=81&cpage=1#comment-712 Jens Petersen Mon, 04 Jun 2012 13:41:29 +0000 http://www.xoltar.org/?p=81#comment-712 Have you tried with HP 2011.4? That is good enough for snap on Linux. But if you're installing afresh, then sure nice get the latest stable ghc+HP pair. Have you tried with HP 2011.4?
That is good enough for snap on Linux.
But if you’re installing afresh, then sure
nice get the latest stable ghc+HP pair.

]]> Comment on When Type Constraints Meet Reflection In F# by Ganesh Sittampalam http://www.xoltar.org/?p=72&cpage=1#comment-709 Ganesh Sittampalam Fri, 18 May 2012 17:26:34 +0000 http://www.xoltar.org/?p=72#comment-709 I think it would be more accurate to say that using reflection makes it very easy to write code that is guaranteed to fail at runtime. Static constraints can't get anywhere close to expressing all the things you can do with reflection. I think it would be more accurate to say that using reflection makes it very easy to write code that is guaranteed to fail at runtime. Static constraints can’t get anywhere close to expressing all the things you can do with reflection.

]]>