about summary refs log tree commit diff stats
path: root/055parse_tree.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-1/+1
| | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between.
* 2573 - check product type of 'new'Kartik K. Agaram2016-01-191-3/+6
| | | | | | | | | | | I realize that my current doesn't allow nesting a:b:c linear type syntax inside a dilated property. So you can't currently say: (recipe address:number) Need to fix that at some point. Non-trivial since linear syntax is oblivious to dilated syntax. I should probably make the dilated syntax more fundamental and introduce it at an earlier layer.
* 2614 - still fixing bugs with missing '['Kartik K. Agaram2015-12-021-3/+2
| | | | | | When skipping past some text (usually whitespace, but also commas and comments) I need to always be aware of whether it's ok to switch to the next line or not.
* 2454Kartik K. Agaram2015-11-171-2/+2
| | | | | | Another gotcha uncovered in the process of sorting out the previous commit: I keep using eof() but forgetting that there are two other states an istream can get into. Just never use eof().
* 2385 - tests passing until layer 58Kartik K. Agaram2015-11-071-2/+7
|
* 2362Kartik K. Agaram2015-11-041-0/+1
| | | | | | Now we try to be smarter about checking for presence in the Type array. Still can't get generic duplex-list to work.
* 2352Kartik K. Agaram2015-11-041-1/+1
|
* 2351 - support arbitrary type trees in 'new'Kartik K. Agaram2015-11-041-0/+12
| | | | In the process we also convert types to sizes before we start running.
* 2307Kartik K. Agaram2015-10-281-0/+5
|
* 2293Kartik K. Agaram2015-10-271-11/+22
|
* 2291 - parsing property treesKartik K. Agaram2015-10-271-0/+47
273'>273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443