Re: named sub-expressions, n-ary functions, things and stuff
Smylers schreef: my $whatever = do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux }; ($bar better not be 3/17) Just a rewrite: my $whatever = do { my $quux = (my $baz = $bar * 17) - 3; $baz / $quux }; And maybe even something like: my $whatever = do { $.quux = ($.baz = $bar * 17) - 3; $.baz / $.quux }; (where quux and baz are topicals of the embracing do) -- Affijn, Ruud Gewoon is een tijger.
Re: named sub-expressions, n-ary functions, things and stuff
On 11/13/06, Darren Duncan [EMAIL PROTECTED] wrote: - There are no Undef or NaN etc values or variables. A RDBMS language with no null would seem to be problematic.. although i guess you could just use 1-tuples where the empty tuple is treated as null. -- Mark J. Reed [EMAIL PROTECTED]
Re: named sub-expressions, n-ary functions, things and stuff
And you may be forced to deal with NaN and Inf values if you are storing raw binary float values as they are built into the bit patterns. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Mark J. Reed [EMAIL PROTECTED] On 11/13/06, Darren Duncan [EMAIL PROTECTED] wrote: - There are no Undef or NaN etc values or variables. A RDBMS language with no null would seem to be problematic.. although i guess you could just use 1-tuples where the empty tuple is treated as null. -- Mark J. Reed [EMAIL PROTECTED]
Re: named sub-expressions, n-ary functions, things and stuff
At 11:00 AM -0500 11/13/06, Mark J. Reed wrote: On 11/13/06, Darren Duncan [EMAIL PROTECTED] wrote: - There are no Undef or NaN etc values or variables. A RDBMS language with no null would seem to be problematic.. although i guess you could just use 1-tuples where the empty tuple is treated as null. In SQL, the null is used for multiple distinct meanings, including 'unknown' and 'not applicable', and having to deal with it makes an RDBMS more complicated to implement and use by an order of magnitude. In practice, there are multiple better ways that users can indicate unknown or not applicable etc, and that can be done using the other features. At 5:35 PM + 11/13/06, [EMAIL PROTECTED] wrote: And you may be forced to deal with NaN and Inf values if you are storing raw binary float values as they are built into the bit patterns. All data types in my RDBMS are boxed types that hide their implementation from the user, so details about bit patterns used by numbers are abstracted away; as particular implementations define it, numbers may not even be floats at all; they could be rationals or strings or whatever the implementer wants to use, but the user doesn't have to care. The only place raw bit patterns appear is in the Blob type, but those are undifferentiated so the bits don't mean anything but to the user. If users have a NaN or Inf they want to store, they can't do it as a database native finite integer or number; but like with nulls, there are other ways to record what users want to know. In any event, I'm interested in knowing what people think about having named sub-expressions supported in Perl 6 and/or giving it stronger pure functional syntax or paradigm support; pure functional means there are no variables or assignment, as far as users are concerned. -- Darren Duncan
Re: named sub-expressions, n-ary functions, things and stuff
Darren Duncan writes: 1. I'm not sure if it is possible yet, but like Haskell et al ..., it should be possible to write a Perl 6 routine or program in a pure functional notation or paradigm, such that the entire routine body is a single expression, but that has named reusable sub-expressions. I realize it isn't pure functional, but in Perl a Cdo block permits arbitrary code to be treated as a single expression. Or to put it another way round, you can use temporary variables inside the expression that don't 'leak out' of it. For example, in pseudo-code: routine foo ($bar) { return with $bar * 17 - $baz, $baz - 3 - $quux, $baz / $quux; } This is instead of either of: routine foo ($bar) { return ($bar * 17) / ($bar * 17 - 3); } That's obviously bad cos of the repetition. routine foo ($bar) { my $baz = $bar * 17; my $quux = $baz - 3; return $baz / $quux; } But what does a functional form have over that? Or over the Cdo version: my $whatever = do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux }; Sure there are variables. But in terms of how your brain thinks about it is it any different from the functional version -- labels being associated with intermediate parts of the calculation? Smylers
Re: named sub-expressions, n-ary functions, things and stuff
At 11:24 PM + 11/13/06, Smylers wrote: Darren Duncan writes: 1. I'm not sure if it is possible yet, but like Haskell et al ..., it should be possible to write a Perl 6 routine or program in a pure functional notation or paradigm, such that the entire routine body is a single expression, but that has named reusable sub-expressions. I realize it isn't pure functional, but in Perl a Cdo block permits arbitrary code to be treated as a single expression. Or to put it another way round, you can use temporary variables inside the expression that don't 'leak out' of it. Hmm. I may have to think some more, but it appears that a Cdo block may be sufficient for what I wanted, which was to embed reusable named parts inside of an arbitrary larger expression. Thank you. -- Darren Duncan