- Hugs-Bugs - Haskell.org

Datatype Constructors: selector/matcher vs builder 'function'
by Anthony Clayden 11 Oct '21

11 Oct '21

>From this discussion 'Contexts on datatype declarations' http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/has… It looks like (at least at the time) GHC had separate functions for matching vs building using a constructor. In Hugs, the type for a datatype's constructor(s) is inferred in static.c routine selectCtxt( ) called from depConstrs( ). The type for field (label) selectors is inferred in type.c routine typeSel( ). And it's easy enough to hack that to drop the preds on the selectors, as SPJ advocates in that thread. What I can't find is where Hugs infers the type for a data constructor appearing in matching position. Any hints? Thanks in advance AntC

1 1

Options | Runtime | Use Show instance for results -- turned off is surprisingly unreliable
by Anthony Clayden 21 Sep '21

21 Sep '21

I usually have 'Use Show instance' switched off (aka use 'built-in printer'), so I can see (at least in crude form) imported or 'system' datatypes that don't have show instances/also it's a bit more revealing if I get exceptions. I have a datatype: > data Tree a = Empty > | Leaf a > | Node (Tree a) a (Tree a) > deriving (Eq, Show, Read) For results of expressions that were `Node`s, the built-in printer just ignored the first field. (`show`/print of those values works fine.) > FoldableTree> myTree <> fdmap toUpper myTree > Node 'c' Empty > FoldableTree> print $ myTree <> fdmap toUpper myTree > Node (Node Empty 'A' (Node Empty 'C' (Leaf 'a'))) 'c' Empty Most disconcerting until I realised what was going on. (Of course I don't expect the built-in printer to produce pretty output). AntC

1 0

smelly code in input.c
by Anthony Clayden 15 Jun '21

15 Jun '21

(I can't say for sure I have a bug, because I don't grok the code well enough to figure out how to make something go wrong, but ...) In /src/input.c line 1714 https://github.com/FranklinChen/hugs98-plus-Sep2006/blob/master/src/input.c… , > if (c0=='.' && isIn(c0,(SMALL|LARGE|SYMBOL))) { It looks wrong to be testing `c0` twice, that test will always come out False. (Or if '.' counts as a SYMBOL, then always True.) I guess the second test should be lookahead `isIn(c1, ...)`. That follows the code pattern nearby above line 1688, and especially 1698. I think it'll mean the compiler won't handle multi-qualified names like `Mod1.Sub2.Subsub3.Foo`. Whereas `Prelude.True` (just a single qualifier) is ok. Can anyone confirm my suspicion and/or suggest a definitive test? (Reason for asking: I'm trying to persuade Hugs to differentiate tight-binding dot as an operator vs space-surrounded dot as function composition. In particular so I can write `record.label` as field access. I'd also like to write `record.#label` as a TRex field access.) AntC

2 2

Hugs Mailing lists?
by Anthony Clayden 23 Sep '20

23 Sep '20

Hi hugs-bugs, is anybody listening here? I've posted to hugs-users a few days ago; that seems to have disappeared, although the list happily showed my posts earlier this year. I've posted to the admin. No response. So trying here. AntC

1 0

Compiling WinHugs (on Windows) in 2006, in 2020
by Anthony Clayden 07 May '20

07 May '20

[Yes I don't expect anyone will read this. I'm leaving it for the record.] No surprise that compiling WinHugs wasn't plain sailing. What's more remarkable is that it did eventually compile (with Microsoft Visual C/C++ under Visual Studio); and that most of the difficulties in getting a working system were with the Unix side, compiling Libraries. (If you want a working system quickly and aren't interested in changing the libraries/packages, I suggest stealing the packages from a WinHugs object distro.) Most of the Unix difficulties/needed changes have been worked through by Franklin Chen, to whom much thanks. See his repo https://github.com/FranklinChen/hugs98-plus-Sep2006 He compiled on Mac, so this is to record difficulties specific to Windows/WinHugs. Firstly, though, there's stuff that must have been just plain wrong in 2006. That's why I'm filing as a bug. The instructions in /docs/building/win32.txt for 'Driving Microsoft Visual C++ from the Command Line (out-of-date)' are not just out of date but downright wrong. Perhaps this was still possible immediately after moving to MSVC, but by Sep 2006 the Makefile was unusable: it refers to all sorts of components that no longer exist/at a guess disappeared after early 2005. However there's one bit that's needed but not mentioned in the MSVC instructions: the three .h files in /src/winhugs and (different files same names) in /src/msc: must be copied in to the parent /src/ directory, and the ones in /src/ (created by ./configure) must first be moved aside. Indeed if you're modifying (Win)Hugs shared artefacts (like parser.y) and recompiling both WinHugs and command-line hugs/runhugs/ffihugs; moving those .h files about is a pain. The `make` does do one useful thing: compile echodate.c and run it to create echodate.h. That's #include'd in /src/version.c to version-stamp your .exe's -- except on Windows the compile demands the #include then ignores it. I'll come back to that. For Windows, the instructions i Win32.txt say " Open the project files located in msc (for the plain interpreter) and winhugs (for the GUI interface). ". That'll lead you wrong. Open the .sln file: Visual Studio will then tell you you have an out-of-date project structure; and will then take a long time upgrading the whole thing to current level. (Comes up to VS 2019 ok -- eventually.) Whereas opening the 'project file' -- i.e. the .vcproj will also tell you you have an out-of-date project structure; then take a much shorter time allegedly upgrading but actually stamping all over the place leaving an unusable mess. (Restore the whole directory from repo and start again; there's no hope of repairing it.) Attempting to build from VS will fail to find echodate.h (see above). Don't stuff about trying to build that, just comment out the #include in /src/version.c -- in fact while you're at it, edit that to take a version of May 2020 rather than Sep 2006. There's a few other bits of .c code that won't compile; including in filecode.cpp an out-of-scope use of a for-loop variable that's not compliant with the 1999 C standard. There are a lot -- I mean a really big lot -- of Microsoft warnings about deprecated functions. I started to investigate these, but got overwhelmed; and eventually concluded this is Microsoft being paranoid about functions that are standard C but Ms don't like -- because they never really believed in a public-standards-based language anyway. You can put #pragmas if you want to suppress the warnings; but don't change the code to comply, because then the build on Unix will fall in a heap wanting non-existent functions. And ... I now have WinHugs built from source by Visual Studio. Indeed I'm modifying `parser.y` and recompiling (needs a Unix bison step) happily. Then all credit to the original Win/Hugs development team in producing robust software. I have to say a 14-year-old system is still more friendly and Windowsy to use than anything from that Glasgow lot. AntC

1 0

Trex record update strange rejection
by Anthony Clayden 08 Nov '18

08 Nov '18

I'm trying to write a polymorphic/generic Trex record update method/class, so I can go > ... setTrex #y 7 r ... That is: use #y to index into record `r`; return `r` with its `y` field set to 7. Then it's using #y as a term-level proxy embedding the label, not as an accessor function. (If `r` does not contain a `y` field, that's a type error.) This is potentially a type-changing update. (But I think that's not relevant to the strangeness.) So this is mimicking GHC's `SetField` class or Lenses. I'll use Lens-like nomenclature. > import Hugs.Trex > > class SetTrex s t a b | s b -> t, s -> a where > setTrex :: (Rec s -> a) -> b -> Rec s -> Rec t > > instance r'\y => SetTrex (y :: a | r') (y :: b | r') a b where > setTrex _hashy y (y = _y | rho') = (y = y | rho') Tediously, this will need an instance for each possible label name. Tests > setTrex #y 7 (y = 5) -- returns (y = 7) -- OK > setTrex #y 7 (z = 'z', y = 5) -- returns (y = y, z = 'z') -- OK > setTrex #y 7 (x = 'x', y = 5) ERROR - Constraints are not consistent with functional dependency *** Constraint : SetTrex (x :: Char, y :: a) (y :: b, x :: Char, y :: b, x :: Char) a b *** And constraint : SetTrex (y :: a, x :: Char) (y :: b, x :: a) a b *** For class : SetTrex a b c d *** Break dependency : d a -> b (If I give an explicit signature for the result, the error goes away.) Notice * the complaint is about **constraints** not consistent so Hugs is generating constraints from the input expression and comparing to the constraint arising from the method's type * the reversal in order of appearance of labels in the records. * but chiefly, the weird doubling-up of the record fields in the first Constraint. If I try to update `y` in a record with 3 labels `x`, `y`, `z`, I get the same error, with even more puzzling details. ( The type vars used in the 'For class .../dependency ...' are distinct from the type vars in the constraints. That's usual Hugs perplexity.) If I declare a direct function to achieve the same thing, with signature > ss :: r'\y => (Rec (y :: a | r') -> a) -> b -> Rec (y :: a | r') -> Rec (y :: b | r') > ss _hashy y (y = _y | rho') = (y = y | rho') all works fine. (But of course there's no FunDeps to worry about being consistent with.) AntC

1 0

strange code in lexer
by Anthony Clayden 06 Oct '18

06 Oct '18

Reading input.c (as you do - I was modifying to allow TRex label names to start upper-case), there's some strange code in lexing qualified names -- routine yylex(): if (isIn(c0,LARGE)) { /* Look for qualified name */ Text it = readIdent(); /* No keyword begins with LARGE ...*/ if (c0=='.' && isIn(c1,(SMALL|LARGE|SYMBOL))) { Text it2 = NIL; loop: skip(); /* Skip qualifying dot */ if (isIn(c0,SYMBOL)) { /* Qualified operator */ it2 = readOperator(); if (opType==CONOP) { top() = yylval = mkQConOp(it,it2); return QCONOP; } else { top() = yylval = mkQVarOp(it,it2); return QVAROP; } } else { /* Qualified identifier */ it2 = readIdent(); if (identType==CONID) { top() = yylval = mkQCon(it,it2); if (c0=='.' && isIn(c0,(SMALL|LARGE|SYMBOL))) { it = mkNestedQual(yylval); goto loop; } return QCONID; } else { top() = yylval = mkQVar(it,it2); return QVARID; After the first readIdent( ), look for trailing '.' then letter or symbol. ie c0 == '.' && isIn(c1, ...) If a letter; readIdent( ) then look again for trailing '.' then letter or symbol. But that code has c0 == '.' && isIn(c0, ...) That must always return False, surely(?) Testing c0 twice. The second c0 should be c1(?) I've tried breaking it by using a module name 4-dots-deep. But that seemed to work. (Perhaps the yacc detects something and glues it back together? I'm finding that impenetrable.) It if it ain't broke, I'm very loathe to fix it. BTW gotta love that goto to a label called `loop` ;-) AntC

1 0

Broken link on download page
by Anthony Clayden 21 Jul '18

21 Jul '18

The Hugs download page here: https://www.haskell.org/hugs/pages/downloading.htm Has broken links for the latest (Sept 2006) downloads of Hugs for Windows. Should be: * WinHugs-Sep2006.exe https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe * MinHugs-Sep2006.exe https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe (Those links currently point to Neil Mitchell's repositories, which have ceased to be.) Links to downloads for other platforms look OK. (I haven't tried them all.) Hugs and WinHugs still run fine, even on a 64-bit Windows machine, by the way. And Trex just works like it says on the tin. AntC

2 3

Lista de emails programa para enviar e mail mail marketing
by Ed Soares 23 Nov '13

23 Nov '13

Lista de emails programa para enviar e mail mail marketing listas de emails que contém lista de emails, trabalhe com mala direta lista de email: http://www.maladiretaemails.com E conhecido que como fazer mala direta, é ótimo para qualquer pessoa. emails de empresas listagem de empresas compreendendo lista de emails, lista emails trabalhe com mala direta, será o propósito de nosso website. Quando você precisar de enviar email, trabalhe com mala direta e, além disso enderecos de email: http://www.maladiretaemails.com é excelente envio de emails adicionalmente lista de mail, emails de empresas lista de mail. é fantástico listas de email além de o que e mailing. trabalho com mala direta mala direta em casa, listas email. nos dias atuais envio de email que inclui Enviar email, lista de email é geralmente um muito legal. é realmente o objetivo de nosso Site: trabalhe com mala direta, Enviar email, bem como envio de emails. Temos envio de email envio de emails, trabalho com mala direta.

1 0

Lista de aprova��o Arapiraca
by Edson 29 May '13

29 May '13

Lista de aprovação Arapiraca: Ponte Branca: ALINE ALVES DE SOUZA, KETLLY CAPISTRANO DO NASCIMENTO, FELIPE DE ALMEIDA BARBOSA, NATALIA CARNICELLI CARVALHO OLIVEIRA, JOÃO CARLOS MOREIRA DE CARVALHO, CÍNTIA FRANCISCA DE OLIVEIRA, MARCOS PAULO DE ARAUJO RIBEIRO, ISABEL CRISTINA DE SOUZA DE LIMA. ROZÂNGELA PINHEIRO LEITE, ELAINE FERREIRA LEITE, MARTONIO RODRIGUES ANGELIM FONTENELE, JOSÉ ORLANDO DA SILVA OLIVEIRA, VANUSA KEZIA SANTOS MESQUITA. Imperatriz. Arapiraca, ANA MARA DE SOUSA PEREIRA, LUANA FERNANDA FERNANDES ANDRADE, FRANCISCO ROGER GARCIA DE ALMEIDA, POLLYANNA DE O, JOÃO CARLOS MOREIRA DE CARVALHO, DANIELLA FERNANDES DA SILVA, MARIA JOSÉ DA SILVA FERREIRA, JÉSSICA VENTURA FREIRE. SOLANGE PAULINO CORREIA, BRUNA KETHEY DA SILVA PEIXOTO, LUIS HENRIQUE FREITAS GOMES, HELIO SOARES DE ARAUJO, RENER QUEIROZ VIEIRA. Bugre. Muquém de São Francisco e ANA PAULA RODRIGUES DA SILVA, LUCAS ARAUJO GOMES FROTA, GABRIEL VICTOR BARROS FORTE DA SILVA, QUITÉRIA DA SILVA GÓIS, JOÃO CARLOS MOREIRA DE CARVALHO, DAYANA MARIA DE SOUSA TAVARES, MARIA JULIENE CORDEIRO, JOÃO PAULO DA SILVA. TALITA FERNANDES GONCALVES, BRUNO RAMOS FERNANDES, LUIZ HENRIQUE ALVES DAMASCENO, IAGO DA SILVA NOBRE, RITA ANGELA DA SILVA. Iporá.

1 0