the constructor for type T is    T( <thisorthese> )                 [ constructor(s)  T()  T(x::A)  T(y::B) T(x::A, y::B) T(x::A, y::A) , T(xs..) if the typology allow ]
                             ---
  
    the constructor  of type T is one of us

    tobj = T(x)

    the constructor  of tobj, an object of type T, is  the constructor for type T
                              --
    tobjs = T(xs)

              --- dinner arrived ---


On Tuesday, July 31, 2012 5:01:38 PM UTC-4, Stefan Karpinski wrote:

On Tue, Jul 31, 2012 at 4:57 PM, John Myles White <johnmyleswhite-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I'm completely sure I don't appreciate the subtleties of this the way you and John Cowan do, but I'm not so troubled by this. T(x) can be seen as giving you "the best approximation" of the input to an object of type T. For an array, that's an array of Int's rather than a single Int, which would be a terrible approximation to the original inputs. When the best approximation is exact, you get exact answers.

 -- John

That's kind of a nice way to look at it. Although it doesn't quite jive with the "T(x...) constructs objects of type T" view which is where this conversation got started.

--
 
 
 

Hi,

I just tried to make the most recent repository version, but it fails:

[mvogelsberger <at> heroint1 julia]$ make
Initialized empty Git repository in /n/home12/mvogelsberger/julia/deps/libuv/.git/
error: The requested URL returned error: 403 while accessing http://github.com/JuliaLang/libuv.git/info/refs

fatal: HTTP request failed
Clone of 'http://github.com/JuliaLang/libuv.git' into submodule path 'deps/libuv' failed

Thanks,
Mark

--
 
 
 

You may need to mess around with the protocol for the libuv module in .git/config. I just change the default in .gitmodules to be git:// which should work for everyone who isn't behind a draconian firewall. If you are behind a draconian firewall, mess around with .git/config and/or complain to your sysadmin.

--
 
 
 

Thanks for the quick reply! Got it working.

Mark


Am Dienstag, 31. Juli 2012 22:51:13 UTC-4 schrieb Stefan Karpinski:

You may need to mess around with the protocol for the libuv module in .git/config. I just change the default in .gitmodules to be git:// which should work for everyone who isn't behind a draconian firewall. If you are behind a draconian firewall, mess around with .git/config and/or complain to your sysadmin.

On Tue, Jul 31, 2012 at 10:28 PM, Mark Vogelsberger <mark.vogelsberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi,

I just tried to make the most recent repository version, but it fails:

[mvogelsberger <at> heroint1 julia]$ make
Initialized empty Git repository in /n/home12/mvogelsberger/julia/deps/libuv/.git/
error: The requested URL returned error: 403 while accessing http://github.com/JuliaLang/libuv.git/info/refs

fatal: HTTP request failed
Clone of 'http://github.com/JuliaLang/libuv.git' into submodule path 'deps/libuv' failed

Thanks,
Mark

--
 
 
 

--
 
 
 

The short discussion at the bottom was also very interesting. I'm not sure I understood it exactly, but one idea is perhaps to organize a sorted array into binary-heap like segments, each of which fits in a cache line, page or whatever unit makes sense?
Yet, intuitively it seems odd to use binary search instead of hash tables if the purpose is only to look up single keys. I'm not only thinking about the assymtotic running time, but the overhead of the compare as well. Maybe his application needed ranges of continually sorted keys? But if so, why consider hash tables?

--
 
 
 

(for your viewing pleasure)

If you choose to use tab character pairs for multi-line comments, use tab pairs for nested multi-line comments.
That decision parsimony offers user harmony.  You should not care how relatively indented is the nested pair.


using treble octothorpe pairs


###
   one, two, three
   three twenty one
###


###
      # one, two, three
      three twenty one
   ###
     one, two, three
     three twenty one
   ###
###


using octothorpe vertical_bar pairings


#|
   one, two, three
   three twenty one
|#


#|
      # one, two, three
      three twenty one
   #|
     one, two, three
     three twenty one
   |#
|#


using octothorpe exclamation pairings


#!
   one, two, three
   three twenty one
!#


#!
      # one, two, three
      three twenty one
   #!:
     one, two, three
     three twenty one
   !#
!#


using octothorpe colon pairings


#:
   one, two, three
   three twenty one
:#


#:
      # one, two, three
      three twenty one
   #:
     one, two, three
     three twenty one
   :#
:#

--
 
 
 

Emily,

--
 
 
 

 ... let's try that again ...

A properly specified and appropriately designed big-t Type is as constructor of the well realized little-t type.  There are one or more constructors for every realized type.  The type may internalize the manner of its own instantiation; or object generation may be an external matter -- or both. 

Julia gives to types privileged standing an offers them a most capable nascent nature.  What does AkoType( ---- )  objectify? Must it be an object of dashing type or an expression of AkoType?

    akoness = AkoType( --- ) ;    Instantiate AkoType to obtain akoness objectified.

This is as it should be; there is nothing awry.








On Tuesday, July 31, 2012 5:01:38 PM UTC-4, Stefan Karpinski wrote:

On Tue, Jul 31, 2012 at 4:57 PM, John Myles White <johnmyleswhite-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

I'm completely sure I don't appreciate the subtleties of this the way you and John Cowan do, but I'm not so troubled by this. T(x) can be seen as giving you "the best approximation" of the input to an object of type T. For an array, that's an array of Int's rather than a single Int, which would be a terrible approximation to the original inputs. When the best approximation is exact, you get exact answers.

 -- John

That's kind of a nice way to look at it. Although it doesn't quite jive with the "T(x...) constructs objects of type T" view which is where this conversation got started.

--
 
 
 

I like the fact that one can tell the compiler exactly what one wants done. The compiler writer can then choose to generate code as he sees fit. If you supply a sequenence of general bit manipulations (say, to count bits), the compiler will not be able to recognize the complex code's intention and use a pop count instruction whenever that is more efficient. I also think primitive functions are more readable than complex bit twidling sequences.

For the same reason I would like to have a plethora of such intrinsic instructions, even when no hardware equivalents exists, and even if they are currently not more efficient. I would like to have many of these in a separate module though. The idea is not to map to current hardware, but to make a statement about commonly seen primitive operations: "the compiler should know what this means and take advantage of it".

--
 
 
 

I love this pairing idea.  The only downside is that transitioning back to pretty much any other language is going to be difficult, as I'll expect multiline comments to respect these rules!

--