Re[2]: [Haskell-cafe] records proposals list

2005-11-21 Thread Bulat Ziganshin
Hello Keean,

Monday, November 21, 2005, 6:56:06 PM, you wrote:

KS> So you can do this now... with reasonable syntax, for example to
KS> create an extensible record

KS> ("some thing" .*. (27 :: Int) .*. True .*. HNil)

KS> is a statically typed anonymous record.
   
it is not record, but heterogenous list, in my feel. record must be
indexed by field name, not by type name or position


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re[2]: [Haskell-cafe] records proposals list

2005-11-21 Thread Bulat Ziganshin
Hello Wolfgang,

Monday, November 21, 2005, 1:30:10 PM, you wrote:

>> > data Coord { x, y :: Double }
>> > data Point = Point {coord :: Coord, c :: Color }
>>
>> because this allows a large number of procedures written to work with
>> Coord, to automatically work with Point. iy just a matter of
>> usability. currently, my program is full of double-dereferncing, like
>> this:
>>
>> [...]

WJ> You should never use bad design to increase usability, I'd say.

to be exact now i have the following definitions:

data FileInfo = FileInfo
  { fiFilteredName :: !PackedFilePath
  , fiDiskName :: !PackedFilePath
  , fiStoredName   :: !PackedFilePath
  , fiSize :: !FileSize  
  , fiTime :: !FileTime  
  , fiIsDir:: !Bool  
  }

-- |File to compress: either file on disk or compressed file in existing archive
data FileToCompress = DiskFile {
  cfFileInfo :: FileInfo
  }
| CompressedFile {
  cfFileInfo :: FileInfo
, cfArcBlock :: ArchiveBlock-- Archive datablock 
which contains file data
, cfPos  :: FileSize-- Starting byte of 
file data in datablock
, cfCRC  :: CRC -- File's CRC
  }

i prefer to replace second definition with the
  
-- |File to compress: either file on disk or compressed file in existing archive
data CompressedFile : FileInfo =
  CompressedFile {
  cfArcBlock :: ArchiveBlock-- Archive datablock 
which contains file data
, cfPos  :: FileSize-- Starting byte of 
file data in datablock
, cfCRC  :: CRC -- File's CRC
  }

and then use procedures, written to work with FileInfo, to directly
work with CompressedFile also. now my program is full of constructs
like:

  uiStartProcessing (map cfFileInfo (arcDirectory arcinfo))
  let fileinfo  = cfFileInfo compressed_file

and double-dereferencing about i wrote in previous letter. such change
will allow me to omit all these superfluous code. imho, new design will
be more natural and allow me to think about my algorithms instead of
implementation complications

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re[2]: [Haskell-cafe] records proposals list

2005-11-20 Thread Bulat Ziganshin
Hello Wolfgang,

Sunday, November 20, 2005, 6:21:05 PM, you wrote:

>> data Coord = { x,y :: Double }
>> data Point : Coord = { c :: Color }

WJ> A point is not a special coordinate pair.  Instead it has a coordinate paar 
as 
WJ> one of its properties.  So the above-mentioned problem would be better 
WJ> handled this way:

WJ> data Coord { x, y :: Double }
WJ> data Point = Point {coord :: Coord, c :: Color }

because this allows a large number of procedures written to work with
Coord, to automatically work with Point. iy just a matter of
usability. currently, my program is full of double-dereferncing, like
this:

  if (fiTime (cfFileInfo arcfile) >= fiTime (cfFileInfo diskfile))
  maximum (last_time' : map (fiTime.cfFileInfo) dir)
  let size =  fiSize  (cfFileInfo cfile')
  bytes = sum$ map (fiSize.cfFileInfo) directory
  let keyFunc  =  fiStoredName . cfFileInfo


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Re[2]: [Haskell-cafe] records proposals list

2005-11-20 Thread Benjamin Franksen
On Saturday 19 November 2005 17:35, Bulat Ziganshin wrote:
> Hello David,
>
> Saturday, November 19, 2005, 4:57:09 PM, you wrote:
>
> DR> I'd benefit from just a list of problems that the record
> proposals want to DR> solve.
>
> DR> 1. The field namespace issue.
> DR> 2. Multi-constructor getters, ideally as a function.
> DR> 3. "Safe" getters for multi-constructor data types.
> DR> 4. Getters for multiple data types with a common field.
> DR> 5. Setters as functions.
> DR> 6. Anonymous records.
> DR> 7. Unordered records.
>
> DR> Argh.  When I think about records too long I get dizzy.
>
> really you are wrote solutions for all these problems (except 6), and
> it's just an additional syntax sugar (like the fields itself). for
> beginning, we must split this list to two parts: belonging to static
> (like H98) and dynamic (anonymous) records. items in your list
> (except 6) belongs to static ones. dynamic records is whole different
> beast and it's really hard to master, so the first question will be:
>
> "are we wanna to have in Haskell only static records, only dynamic
> records or both?"
>
> as i see, GHC team want to implement such proposal, which will
> resolve both issues. and wainting (waiting+wanting:) for such
> solution, they are don't implement suggestions which address only
> static records problems
>
> but the dynamic records is too complex thing: it may be syntactically
> incompatible with H98, it may require changes to GHC internals and so
> on, so they are delayed until better times
>
>
> besides this all, i want to add one more item to your list:
>
> 7. OOP-like fields inheritance:
>
> data Coord = { x,y :: Double }
> data Point : Coord = { c :: Color }
>
> of course this is just another sort of syntax sugar once we start
> using classes to define getter/setter functions

Please take a look at the recent paper by Daan Leijen 
(http://www.cs.uu.nl/~daan/pubs.html#scopedlabels). I think this would 
solve the mentioned problems and has the additional advantage of 
supporting anonymous records. The author claims his proposal to be 
integrable with most known type systems.

Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re[2]: [Haskell-cafe] records proposals list

2005-11-19 Thread Bulat Ziganshin
Hello David,

Saturday, November 19, 2005, 4:57:09 PM, you wrote:

DR> I'd benefit from just a list of problems that the record proposals want to
DR> solve.

DR> 1. The field namespace issue.
DR> 2. Multi-constructor getters, ideally as a function.
DR> 3. "Safe" getters for multi-constructor data types.
DR> 4. Getters for multiple data types with a common field.
DR> 5. Setters as functions.
DR> 6. Anonymous records.
DR> 7. Unordered records.

DR> Argh.  When I think about records too long I get dizzy.

really you are wrote solutions for all these problems (except 6), and
it's just an additional syntax sugar (like the fields itself). for
beginning, we must split this list to two parts: belonging to static
(like H98) and dynamic (anonymous) records. items in your list (except
6) belongs to static ones. dynamic records is whole different beast
and it's really hard to master, so the first question will be:

"are we wanna to have in Haskell only static records, only dynamic
records or both?"

as i see, GHC team want to implement such proposal, which will resolve
both issues. and wainting (waiting+wanting:) for such solution, they
are don't implement suggestions which address only static records
problems

but the dynamic records is too complex thing: it may be syntactically
incompatible with H98, it may require changes to GHC internals and so
on, so they are delayed until better times


besides this all, i want to add one more item to your list:

7. OOP-like fields inheritance:

data Coord = { x,y :: Double }
data Point : Coord = { c :: Color }

of course this is just another sort of syntax sugar once we start
using classes to define getter/setter functions


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe